Double the size of the tick when devdrawretina is set

[robkroeger, 2012-11-25 23:03:49]

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.

[rsc, 2012-11-26 03:37:50]

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

[rsc, 2012-11-26 05:25:09]

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.