FXML and high dpi screens

[Richard Bair]

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.

Richard