Windows support for HiDPI displays, call for feedback and testing
james.graham at oracle.com
Thu Jun 11 05:30:36 UTC 2015
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:
> 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:
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
More information about the openjfx-dev