TAGS
Scene scene = new Scene(tabs, 25 * rem, 33.33 * rem);
2013-09-08: As Cay Horstmann suggests below, it’s probably smarter to define rem in terms of pixels rather than points. This requires some additional rounding to obtain integral sizes on Windows, however. The alternative pixel-based definition looks like this:
final double rem = Math.rint(new Text("").getLayoutBounds().getHeight()); What about CSS? JavaFX exposes only a fraction of its sizing & positioning properties in CSS, and pixel or point sizes (px/pt) are never scaled anyway. Em sizes do appear to scale to the current default font size, but Oracle makes no guarantees to this effect. I recall em sometimes producing a hard-coded 12pt rather than the current default font size – possibly the behavior depends on when the style is loaded or applied. The safest route is to either specify no sizes in CSS, or else to calculate the necessary styles at runtime using Node.setStyle with the current root em. Alternatively, you could prepare multiple stylesheets at different scales and select one at runtime, Android-style.
What about FXML? No help there either, as any coordinates are simply passed through to the corresponding Java methods, meaning they are interpreted as unscaled pixels. Moreover, FXML does not support computational coordinate scaling or em equivalents. You could create multiple FXML files at different scales and select one at runtime – or avoid specifying any layout measures in FXML.
2013-08-17: As John Smith points out below, you can use computed expressions for FXML coordinates! See in the OpenJDK discussion thread . So you should be able to scale FXML layouts by root em without too much hassle.
Although JavaFX is certainly better suited to scalable GUIs than Swing, thanks to its scaled default font and intelligently self-sizing controls, it’s still rather lagging behind the state of the scaling art. Microsoft’s Windows Presentation Foundation (WPF) scales all coordinates, whether in code or XAML, and the new maps different pixel densities to a standardized virtual screen size. and both offer dual APIs so that developers can use either scaled coordinates for portable layout or unscaled coordinates for precise drawing, at their discretion. Apple had to provide high DPI support in Swing, but JavaFX 2.2 still offers nothing comparable.
Planned for Spring 2014, JavaFX 8 and its will finally support Apple’s “retina” displays. Android support is currently being prototyped at Oracle but there’s no release date that I’m aware of. Back in December 2012, that JavaFX will “in the future” replicate Apple’s dual API so that developers can opt into or out of coordinate scaling as necessary. I certainly hope that this feature will be available for all platforms, including Windows, and sooner rather than later. To put it bluntly, a single unscaled coordinate system is not good enough for a GUI framework in 2013.
2013-09-11: Looks like Christmas came early for Apple users. The current Java SE 7u40 claims to already support Apple Retina displays in both Swing/AWT and JavaFX.
.
