Keyboard Shortcuts

File
u :up to issue
m :publish + mail comments
M :edit review message
j / k :jump to file after / before current file
J / K :jump to next file with a comment after / before current file
Side-by-side diff
i :toggle intra-line diffs
e :expand all comments
c :collapse all comments
s :toggle showing all comments
n / p :next / previous diff chunk or comment
N / P :next / previous comment
<Up> / <Down> :next / previous line
<Enter> :respond to / edit current comment
d :mark current comment as done
Issue
u :up to list of issues
m :publish + mail comments
j / k :jump to patch after / before current patch
o / <Enter> :open current patch in side-by-side view
i :open current patch in unified diff view
Issue List
j / k :jump to issue after / before current issue
o / <Enter> :open current issue
# : close issue
Comment/message editing
<Ctrl> + s or <Ctrl> + Enter :save comment
<Esc> :cancel edit
Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(373)
Issues Repositories Search
Open Issues | Closed Issues | All Issues | Sign in with your Google Account to create issues and add comments

Issue 6849099: Double the size of the tick when devdrawretina is set

Can't Edit
Can't Publish+Mail
Start Review
Created:
13 years, 1 month ago by robkroeger
Modified:
13 years, 1 month ago
Reviewers:
rsc
CC:
codebot
Visibility:
Public.

Patch Set 1 #

Created: 13 years, 1 month ago
Download [raw] [tar.bz2]
Unified diffs Side-by-side diffs Delta from patch set Stats (+17 lines, -5 lines) Patch
M include/frame.h View 1 chunk +1 line, -0 lines 0 comments Download
M src/libframe/frdraw.c View 1 chunk +1 line, -1 line 0 comments Download
M src/libframe/frinit.c View 4 chunks +15 lines, -4 lines 0 comments Download
Total messages: 4
|
robkroeger
13 years, 1 month ago (2012年11月25日 22:56:30 UTC) #1
Sign in to reply to this message.
robkroeger
This change makes the tick twice as thick in retina mode. Please take a look. ...
13 years, 1 month ago (2012年11月25日 23:03:49 UTC) #2
This change makes the tick twice as thick in retina mode. Please take a look.
There is a problem here: the tick stays double-thickness when a window is moved
from retina to non-retina display while devdrawretina is set. I think that there
would need to be some kind of dynamic notification from devdraw of the current
deviceScaleFactor to fix this.
Sign in to reply to this message.
rsc
Indeed. I attached a clumsy patch to https://bitbucket.org/rsc/plan9port/issue/107/devdraw-macbook-retina-support that does most of the necessary expansion ...
13 years, 1 month ago (2012年11月26日 03:37:50 UTC) #3
Indeed. I attached a clumsy patch to
https://bitbucket.org/rsc/plan9port/issue/107/devdraw-macbook-retina-support
that does most of the necessary expansion for retina, but it does it
always (it doesn't even consult devdrawretina). I'd like whatever we
end up doing in the tree to be more adaptive, ideally leading to
getting rid of the devdrawretina setting entirely.
As a first start toward a real solution, I just committed
 http://codereview.appspot.com/6856091 adds display->dpi
 http://codereview.appspot.com/6858071 adds DefaultDPI
 http://codereview.appspot.com/6855092 adds scalesize (see graphics(3))
The new field display->dpi field is refreshed on each window resize.
Right now it is always set to DefaultDPI (100), but if the Cocoa code
in devdraw sets the global displaydpi variable when creating the new
image, that value will filter through to display->dpi in the graphical
program.
My suggested plan, then, is:
1. Set displaydpi correctly in devdraw, probably during initimg.
2. Make the libframe tick code scale the tick size using scalesize. I
think you probably want to use FRTICKW*scalesize(display, 1) instead
of scalesize(display, FRTICKW) so that the tick width splits nicely
into thirds as it always has. For the current retina displays where
actual dpi is around 220, that will end up being a 6-pixel tick.
3. Adjust the fixed-size elements like lines in acme according to
display->dpi too. Probably start with scalesize, but we can tweak
things according to whether it looks good. (See bitbucket patch for
places that need changing. I also missed the line between tag and
body, wherever that is.) It may be that we should make DefaultDPI 133
instead of 100. That will still produce scalesize(d, 1) = 2 on 225 dpi
retina, but it will produce scalesize(d, 2) = 3, scalesize(d, 4) = 7,
and scalesize(d, 12) = 20. When I was playing around those seemed a
bit nicer than strict doubling.
4. Eventually it might be nice to make references to fontsrv fonts
auto-scale, so that if you ask for /mnt/font/LucidaGrande/14a/font (a
reasonable approximation to the default acme font), you get 31pt on
retina. That will require both reloading fonts on resize and also
making apps understand that a font's metrics can change as a result of
a resize. This is also an argument for DefaultDPI = 135, as that would
produce 24pt, which is what I've actually found to work well with acme
on this machine.
So as far as this CL is concerned, I suggest changing it to use
scalesize, so that it forms step 2 of this plan.
Thanks.
Russ
Sign in to reply to this message.
rsc
I had a little more time so I prototyped a bit more of this. If ...
13 years, 1 month ago (2012年11月26日 05:25:09 UTC) #4
I had a little more time so I prototyped a bit more of this. If you
sync and rebuild, you'll get a sequence of CLs that:
1) sets display->dpi to 220 on retina, 110 on non-retina. That's not
perfect, and I'd welcome a CL that produces true values, but it is
pretty close
(http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density#Apple;
http://codereview.appspot.com/6782115).
2) interprets Cmd-R keystroke to toggle "opposite of current dpi"
mode. So if you're on a retina display, Cmd-R makes it seem like you
just moved the window to a non-retina display, and vice versa. The
effect of Cmd-R is to change the value of display->dpi and trigger a
resize event. (http://codereview.appspot.com/6846104)
3) adjust libframe's tick images automatically when display->dpi
changes (http://codereview.appspot.com/6850102)
4) calculate samterm's and 9term's scroll bar and border widths using
scalesize (http://codereview.appspot.com/6847105,
http://codereview.appspot.com/6844083)
The effect of the sequence is that you can start 9term or sam and sit
there hitting Cmd-R and watch the tick and scroll bar grow and shrink.
Ultimately all the UI elements should adjust like that. The demo shows
that it is possible, but it will require work in every program with
fixed-size elements, and converting acme will be a bit more work than
converting sam. And this doesn't tackle fonts at all.
Unfortunately, this obsoletes the CL you sent, which I apologize for.
I would gladly welcome CLs that adapt other tools or that fix the DPI
calculation.
Thanks.
Russ
P.S. I also changed DefaultDPI to 133, because it seemed nicer. I
expect that to take a few iterations.
Sign in to reply to this message.
|
Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b

AltStyle によって変換されたページ (->オリジナル) /