FXML and high dpi screens

[Danno Ferrin]

On Tue, May 21, 2013 at 9:09 AM, Richard Bair <richard.bair at oracle.com>wrote:

>
> On May 20, 2013, at 10:29 PM, Tom Eugelink <tbee at tbee.org> wrote:
>
> > Aren't we mixing up things?
> >
> > Responsive webdesign is primarily focused at how to show the same
> information on less screen space, using the same elements in the same
> resolution. The questions here are: what to hide or add, what to place
> where.
> >
> > High DPI screens foremost involves keeping things the same visual size
> for the user, the actual layout does not change as with responsive
> webdesign, but the attempt is to have it look the same on all DPIs. The
> questions here are: how do I keep things readable for the user, how do I
> keep things sharp (because scaling causes blurry borders, especially when
> scaling up).
>
> Well put.
>
> > Most approaches at least use a non resolution dependent unit; being it
> dips or old fashioned inch or cm. If you state that you want the font do be
> 0.4cm, the device (knowing its dpi) can easily calculate the number of
> pixels. The blurryness and visual misses a.o. come from rounding; 0.4cm may
> not be exactly 2x the pixels from 0.8cm. The biggest pains are the
> graphical elements, because they have to scaled and often get all kinds of
> minor artifacts that make the whole seem off. Vectors initially seem like a
> good approach to catch this, but as Kirill has shown (
> http://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html),
> this only works for a limited range of resolution.
> >
> > So maybe the best approach is a combination of vector and what Android
> does:
> > - use a device independent unit and scale accordingly
> > - optionally split DPI into ranges and provide graphical elements for
> each range, preferably vector but you can't forbid bitmap, preferably
> scaling down.
>
> Note that scene graph units are already device independent pixels. We use
> the definition of pixel as defined in the CSS spec:
> http://www.w3.org/TR/CSS2/syndata.html#length-units. This is why we can
> get away with pixel-doubling everything on retina -- the scene graph says
> that a node is still 150 width, but that is actually 300 device pixels on a
> retina display.
>
> Because we auto-scale based on the DPI (although currently *only* for
> retina) the only thing the application actually has to worry about is that
> the right images get loaded. At present we use the mac @2x file name trick
> for images. We could do the same and have @1.5x or @3x or whatever if we
> had other sizes to support.
>
> As long as you have a way to turn off our own built-in scaling mechanism
> (there is a command line flag for it, though I'm not sure it is meant as
> public API yet) you can always put a scale on the root node of the scene
> and load your own images and you should be good to go.
>

Ok, in JFX 2x how do I get the pixel scale?  This commit
http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/51a85b7f59c2 has it for
Images, but where can I tease it out for the whole display? Private APIs
for 2.2 are OK, but will this be a "wait for 8" feature?