|
|
|
Created:
13 years, 1 month ago by robkroeger Modified:
13 years, 1 month ago Reviewers:
rsc CC:
codebot Visibility:
Public. |
Patch Set 1 #
Total messages: 4
|
robkroeger
|
13 years, 1 month ago (2012年11月25日 22:56:30 UTC) #1 | ||||||||||||||||||||||||||||
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.
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
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.