On 2012年10月05日 21:21:47, rsc wrote:
> I don't have anything to try this on. 
Any mac with a big screen can be coerced into "retina" mode with the quartz
debug tool (http://osxdaily.com/2012/01/12/enable-hidpi-mode-in-mac-os-x-lion/)
> Do you mean that this makes the app run at
> the actual hw pixel resolution (so it will appear smaller) or something else?
> Perhaps we need to let users choose?
Yes. It makes devdraw use physical pixels so fonts and other drawing look tiny
without other measures. (Like doubling the size of -font when running acme.)
Cursors continue to be scaled by the operating system so have the right size
regardless.
This change has no effect when run on a non-retina devices and successfully
handles dragging windows from retina to non-retina display.
I see your point about letting users choose. I'm not sure how to do this -- or
more accurately -- I'm not sure which way this choosing should be enabled that
is not either a massive CL (which I would be happy to try to write albeit in
stages) or somehow icky. Do you have a suggestion? Perhaps an environment
variable? I could add this.
One possible "high road" way would be to do this patch and then add more:
* Make the device scale factor be an attribute of an Image object. A fragment of
code that is retina-unaware would have its output pixel doubled. A fragment of
code that is retina-aware would inform a draw-target Image of this awareness. So
existing code would keep looking like it does now.
* Make libframe retina-aware so it would draw fonts with glyph images and
metrics in physical pixel sizes. I went through this process on Chrome and the
text layout code has to either be pixel doubled (and look fuzzy) or operate in
pixel-layout precision (and look gorgeous) or else the glyphs
line-break/position wrongly.