Fwd: FXML and high dpi screens

[Daniel Zwolenski]

Some additional comments on this from my go-to guy for mobile development, who does a lot in cross platform mobile dev. 

Begin forwarded message:

> From: Chris Glover
> Date: 21 May 2013 8:46:32 AM AEST
> To: Daniel Zwolenski <zonski at gmail.com>
> Subject: Re: FXML and high dpi screens
> 
> Looks like they're on the right track. I guess I have a few things to add
> Android has various units that you can use, of particular use are dip (device independent pixels) and sp (scaled pixels - which is like device independent pixels, but scaled to match the users font size settings)..ems I find aren't actually that useful if you have a good layout manager as they are really only useful to set the width of text fields
> Android allows packaging of different assets for broad categories of resolution and screen density, it works OK
> CSS allows media queries on screen size and resolution, I think this is a more flexible approach than Android's, and as they're using CSS anyway it seems like a good fit
> One thing that CSS doesn't do well, is sizing an element to fit the background image, typically you will have to set the background image and set the width/height of the styled element to match, which is a pain. Would be nice to avoid that problem (Android does it well)
> Any kind of asset/application scaling to deal with different resolutions/densities is bull****, as mentioned, it gives unsatisfactory and inconsistent results. Unfortunately, there doesn't seem to be a better solution than a combination of good layout management, using concepts like device-independent-pixels, and supplying assets pre-scaled to multiple resolutions or in vector format. 
> ?
> 
> 
> On 21 May 2013 06:54, Daniel Zwolenski <zonski at gmail.com> wrote:
> Not sure if you'd be interested in weighing in on this. 
> 
> 
> Begin forwarded message:
> 
>> From: Richard Bair <richard.bair at oracle.com>
>> Date: 21 May 2013 1:53:08 AM AEST
>> To: Jack Moxley <jack at moxley.co.uk>
>> Cc: "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
>> Subject: Re: FXML and high dpi screens
>> 
>> Hi Jack,
>> 
>> Our experience is that the Apple solution is much cleaner, however you're experience is very interesting and (since you are actually shipping apps on it instead of living in the land of theory) relevant. Do you have a proposal?
>> 
>> One thing to consider is that any scale factor that doesn't end up pixel aligned will result in fuzzy UI. Our "snap to pixel" layout snaps to whole numbers for positions -- but based on the scale factor this may or may not end up pixel aligned (otherwise when animating a UI control it would snap from pixel to pixel instead of smoothly animating through them).
>> 
>> Can you give some examples of the type of control you need, and why?
>> 
>> Thanks!
>> Richard
>> 
>> On May 18, 2013, at 12:20 AM, Jack Moxley <jack at moxley.co.uk> wrote:
>> 
>>> You have to be careful, apples support for pixel densities and screen sizes is very lack luster, it came late in the day and they only ever needed to support a small number of densities and screen sizes.
>>> 
>>> Googles approach on android, or preferably the standard html5 approach using media queries is going to cause less issues in the long run. The requirement to have the the layout change because of orientation, screen size or density is prevalent in every mobile application I have ever had to write or port. 
>>> 
>>> As such having it done for me, does not appeal, unless I have a way of overriding it.
>>> 
>>> Sent from my iPhone
>>> 
>>> On 18 May 2013, at 00:01, Jim Graham <james.graham at oracle.com> wrote:
>>> 
>>>> The way we deal with platform "stretching" for retina displays is to tell the platform that we are HiDPI aware and do the "pixel stretching" ourselves, but this is using only the MacOS APIs for DPI communication.
>>>> 
>>>> We have an outstanding Jira issue to do the same thing for Windows 8, but we haven't investigated what that involves yet, primarily because there hadn't been a major hardware shipment of Win8 HiDPI screens at the time we implemented Retina support.  It sounds like the new Surface hardware might be opening that box on the Windows side now.
>>>> 
>>>> If we'd implemented retina support entirely by suggesting a different EM to the CSS code then only code that used CSS for sizing would look good.  The solution we used for Retina scales all content appropriately including, implicitly, the CSS EM sizing...
>>>> 
>>>>          ...jim
>>>> 
>>>> On 5/16/13 11:51 AM, Danno Ferrin wrote:
>>>>> Executive summary: Is there any way in FXML to specify the sizes of the
>>>>> components in units other than pixels?  Either now or in the future?
>>>>> 
>>>>> So I am running a Java Swing Application on a Surface tablet with multiple
>>>>> embedded FXPanels (mostly to deal with cross toolkit dialog modality... an
>>>>> issue for another thread).  In order to not get the horrible blurred view
>>>>> (since surface does 150% font scaling) I turn off the dpi fixing for the
>>>>> java app, so the swing app is pixel to pixel for the most part, with some
>>>>> dramatic sizing issues with the XP theming (an issue I don't expect ever to
>>>>> be fixed).
>>>>> 
>>>>> So I have an FXML panel that is supposed to be 560x400, and I literally get
>>>>> 560px by 400px.  But the widgets are all sized in EM, which respects the
>>>>> native DPI scale.  I don't want to turn that off, because in this case I
>>>>> like it.  But the widgets scale up, so it sizes like a 373.333x266.666
>>>>> panel.  What I do want to be able to do is specify the FXML sizes in EM, so
>>>>> I would call it 35em x 25em.  Is there a way in FXML to specify these?  Or
>>>>> will I have to do multiple FXMLs mechanically scaling the sizes up.  Or is
>>>>> there some escape sequence or auxiliary data I can add to say "scale pixel
>>>>> sizes by 150%"?
>>>>> 
>>> 
>> 
>