Windows support for HiDPI displays, call for feedback and testing

[Jim Graham]

Hi Michael,

On 6/10/15 12:39 AM, Dr. Michael Paus wrote:
> If I understand you correctly you are saying that all this
> HiDPI-handling is done under the covers and should
> be fully transparent to the programmer, whereas I think that this is not
> possible for non-trivial cases.
> (Is this foo.<suffix> versus foo at 2x.<suffix> handling documented anywhere?)

Unfortunately I think we are a little lax there in terms of our API 
documentation.  I did find this blog by Richard that described this 
feature back when we released the retina Mac support:

http://fxexperience.com/2012/11/retina-display-macbook-pro/

> Just a few questions:
>
> How do you determine which images to download from a server or database
> if you don't know the render scale?

Right now we only load one version of the image and we base it on the 
highest render scale on any screen.  If it is more than 1.5x then we try 
to load @2x versions of any image.  If no such image name exists then we 
load the regular image.  So, if you say:

	new Image("foo.png");

and you have any screens that are 150% or greater we will first look for 
"foo at 2x.png" and only load "foo.png" if we don't find that file.

Eventually we need to make this more formalized and extensible, and we 
also should be loading all variants of the image and using them 
dynamically as the output is scaled (whether it comes from a 
getRenderScale() or simply comes from zooming in).  This is all a "work 
in progress" and there is no public API to control any of this other 
than to know that we'll use an @2x image if we find one.

> How do you handle cases where your images are read from a stream where
> you do not have a @2x name extension?
> (Same for other non-named image sources.)

We only do this processing when we are loading from some sort of URL 
where we can find a suffix and string-edit it to have the @2x sub-suffix.

> How do you draw thin (single pixel wide) lines if you don't know the
> render scale?

On the other hand, why do you want to render a single pixel wide line? 
If your app is running on my Windows 8 laptop that has a 300DPI screen I 
won't be very happy using your app if you are determined to only render 
a single pixel.  You should size your lines relative to the rest of the 
content and not try to size anything "by the pixel".

On the other hand, there is some desire to have UI elements line up on 
crisp pixel boundaries so we do need to address "how do I draw a line 
that lines up on whole pixels" eventually and we haven't done that yet.

> How do you display an image at exactly 100% scale (like the option in
> Photoshop for example) if you don't know the render scale?

We will eventually get there.

Be aware, though, that even a native Mac app can't do what you ask 
because Mac OS virtualizes the pixels on you.  I still need to dig and 
see if we can find a way to see past their virtualization, but native 
Mac apps are expected to do one of 2 things:

- be unaware of HiDPI scaling and render at 1x
- be aware of HiDPI scaling and render at exactly 2x on retina displays

After you've done that, if the user has set their screen to "best for 
retina" in the control panel then your "aware" app will have its output 
go to the screen 1:1.  If the user sets their screen to any other 
resolution, though, you will now be pixel scaled even though you 
voluntarily rendered at 2x already.

> How do you take a snapshot of a node at full resolution? For example a
> 500x500 canvas will be internally backed by a 1000x1000
> image which looks crisp on your Retina screen. When you now take a
> snapshot of this canvas it will be a blurry 500x500 image.
> (At least that was the result when I last tried it.)

We'll need to advertise our internal scaling - that is coming in 9.

> There are workarounds for all these issues but only if you know the
> render scale.

I realize, and I have this on my radar.  Our first efforts have been to 
avoid the cases of "my app is horribly disfigured by system pixel 
stretching due to being DPI unaware" and "my app might be crisp, but it 
is unusably small on Windows".  We're pretty much there now - apps 
should be of an appropriate size on all displays with only minimal pixel 
stretching artifacts (and at that, we only downsize by pixel stretching, 
never upsize, so this becomes a form of super sampling) - but we haven't 
yet provided the APIs for apps to go beyond the tradeoffs of our 
automatic support...

			...jim