On Tue, May 21, 2013 at 9:09 AM, Richard Bair <richard.b...@oracle.com>wrote:
> > On May 20, 2013, at 10:29 PM, Tom Eugelink <t...@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?
