FXML and high dpi screens

[Daniel Zwolenski]

Is it worth also looking at web land for strategies here? HTML seems to cater for all screen sizes and resolutions from little androids to massive iMacs. 

The Bootstrap strategy is to provide alternate CSS rules for different media types and resolutions. 

http://www.onextrapixel.com/2012/11/12/how-to-use-twitter-bootstrap-to-create-a-responsive-website-design/

Just something to throw in the mix. 



On 21/05/2013, at 6:54 AM, John Moxley <jack at moxley.co.uk> wrote:

> To be fair its been about a year since I have shipped any apps, I am currently working on treasury systems in a bank, so not quite as relevant. :-)
> 
> When porting for very small devices, the main rule of thumb was to allow the screen to adapt to larger screens programatically. Lets hypothetically say I was designing an application that displayed a graph of, for arguments sake, sales figures. On a small device I would want a single graph to be displayed, with maybe a button to show the legend in a pop up. As the screen got larger I would want that legend to appear on the graph itself, as it got larger I might want to add options or even more graphs. I certainly wouldn't want the line on the graph to be pixel stretched. I also wouldn't want a massive graph with a button for the legend. 
> 
> With high resolution screens, apples solution was to basically add 2X to the name of all its images designed for the retina display, this works if all you are doing is doubling your res, but in the android world pixel density is more in flux, and the costs associated with generating so many images is going to be high. Being able to dynamically determine when and where you apply such tactics is invaluable.
> 
> Can I suggest reading up on best practices at http://mobiforge.com/ It arose from the .mobi domain back in the day when we were dealing with a mix of wap and html4, it might give an insight into the practice of mobile UI designers.
> 
> I think my main point is it has to be adaptable. Android does have too much ui configuration for my liking, but it is powerful. Javafx has got a bigger problem them iOS or Android in that its got to support even more resolutions and devices.
> 
> I don't have a proposal, but I will think on it.
> 
> On 20 May 2013, at 16:53, Richard Bair <richard.bair at oracle.com> wrote:
> 
>> 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%"?
>>>>> 
>>> 
>> 
>> 
>