High-DPI awareness has been the subject of the presentation that i held with Mike Swingler at this year’s JavaOne. This topic has not been getting nearly as much attention as it deserves to, but things might change in the near future.
Ryan Haveson is the program manager lead for the Desktop Graphics team of Windows 7 (the next version of Windows OS). In the article published a few days ago on Windows 7 blog he delves into such areas as scaling modes, programmatic support, current configurations and future plans. One of the main considerations for Windows as the current leader in the desktop presence is backwards compatibility. Ryan’s team must find the right balance between addressing the modern high-resolution hardware and not breaking user experience for older applications:
Our thinking for Windows 7 was that if we enable high DPI out of the box on capable displays, we will enable users to have a full-fidelity experience and also significantly reduce eye strain for on-screen reading. There is even infrastructure available to us to detect a display’s native DPI so we can do a better job of configuring default settings out of the box. However, doing this will also open up the door to expose some issues with applications which may not be fully compatible with high DPI configurations.
As it stands now, applications using GDI have to explicitly scale the visuals:
One of the issues is that for GDI applications to be DPI aware, the developer must write code to scale the window frame, text size, graphical buttons, and layout to match the scaling factor specified by the DPI setting. Applications which do not do this may have some issues. Most of these issues are minor, such as mismatched font sizes, or minor layout artifacts, but some applications have major issues when run at high DPI settings.
While Vista (as well as XP) provide automatic scaling, this results in blurry visuals that do not utilize the full potential of high-resolution monitors:
In the case of automatic scaling, applications which are not DPI aware are automatically scaled by the window manager. The text size matches the user preference, but it also introduces a blurry effect for that application’s window as a result.
It is not clear from this posting what are the exact plans for the next Windows release. The conclusion section is very uncommitting and vague, but it is very encouraging to see that Microsoft is joining Apple and KDE / Gnome in providing tools to scale the UIs to match the current desktop hardware. In fact, the upcoming release 8 of Internet Explorer boasts full support for High DPI mode (though the quote on “entire awareness” of Vista is exaggerated as can be seen from the screenshots in our JavaOne presentation):
Like Windows Vista, the Internet Explorer 8 UI is entirely Hi-DPI Aware. You will also notice that all UI elements and UI fonts are scaled accordingly and that icons are larger and have higher fidelity. Notice the difference in the Internet Explorer chrome when Windows DPI Scaling is set to 96 DPI and 120 DPI, respectively:
Internet Explorer Chrome at 96 DPI.
Internet Explorer Chrome at 120 DPI.
It is quite illuminating to read the comments on this entry. Some readers call for the monitor manufacterers to effectively stop the progress and agree on a fixed pixel size:
The physical size in inches should be proportional to resolution in pixels. If [manufacterers] increase the resolution without making the screen larger, it’s obvious that we have problems for reading! I don’t think Microsoft should modify Windows because monitor makers are doing silly things. There should be an international standard for pixel size and font readability.
And going even further to follow Apple’s route:
MAC App developers don’t have to worry about DPI or non-square pixels because Apple has full control over the specification of the MAC monitors. Why Windows can’t do the same and completely remove the scaling burden from app developers? Microsoft should use its influence on PC manufacturers and ask them to build monitors to Windows certified specification.
One reader points to a bit of a chicken-and-egg problem:
Programmers don’t bother with DPI aware apps, because all mainstream monitors have their physical DPI @ 96. And monitor makers don’t bother with making bigger DPI monitors, because apps aren’t there yet. The only solution I see, is to bite the bullet and at default make Windows adjust to the native resolution/DPI.
And a sane voice points to a solution that does not involve user intervention at all, hiding the pixel-point-inch impedance behind the scenes:
Windows 7 should automatically set your monitor at its native resolution. It should then determine the best dpi for your display and automatically scale the entire OS to it, afterwards if you want to set it at a different dpi then you can.
While the hardware technology of high-resolution monitors does not progress at nearly the same rate as other parts of the consumer-oriented market (CPU, GPU, RAM, hard disk, etc), it is evolving nonetheless. The major operating systems and windowing toolkits differ in their level of support. Hopefully, Microsoft’s awareness of the importance of this subject will not be significantly hampered by the shackles of backwards compatibility.
I am extremely pleased today to announce the availability of official releases for a number of my Swing projects. Synchronizing the release schedules for these projects allows the applications to take stable and well-tested libraries that allow creating modern user interfaces.
Flamingo component suite release 3.1 (code-named Eilinora) is available. The goal of the project is to provide a small and cohesive set of powerful UI components with functionality similar to or superseding that of Vista Explorer and Office 2007, and this release closes many gaps towards realizing this goal. The release notes have the detailed description of the new functionality. Noteable features include:
- Improvements to SVG transcoder, allowing creating resizable icons. This is used in the new ribbon demoes to make significant performance improvements to the startup phase.
- Contextual task groups on the ribbon component.
- Dynamic content of in-ribbon galleries.
- Decorating the ribbon under Substance plugin, putting the taskbar and contextual task group headers on the title pane.
- Resizable icons based on .ICO format.
- Command buttons supporting disabled mode, changing text and changing font.
- Auto-repeat mode on command buttons.
- Column-fill mode on command button panels.
Substance look-and-feel release 5.0 is available. Substance has undergone significant internal and external changes to address major performance issues and to ensure the long-term code health of the project. Here is the list of big changes in Substance 5.0:
- Moving to Java 6 as the minimum runtime requirement.
- Addressing the performance issues. While the first announced drop was 20% faster than release 4.3, the release candidate is 3.5 times faster on static scenarios and 2.7 times faster on dynamic scenarios as measured by the LightBeam testbed.
- New client property to allow using per-window skins.
- Enhanced theming layer.
- Removed 16 VM flags and left only 2.
- Removed 15 client properties, consolidated 3 others into 2 and added 1 new.
- Removed 54 API methods on the main class, pushing some functionality into the theming layer.
- Consolidated theme pack, watermark pack and button shaper pack into the Extras pack that also provides additional skins.
The following sub-projects are also available as official releases:
Version 4.3 of Substance (the last version that can run on Java 5) is in long-term support mode. At the present moment this version has thirteen bug fixes backported to it from the main development trunk.
Click on the button below to launch a signed WebStart demo that shows the available Substance features:
Click on the button below to launch a WebStart demo that shows the Flamingo ribbon component under Substance look-and-feel:
Click on the button below to launch a signed WebStart demo that shows the SwingX components under Substance:
In addition to Substance and Flamingo that can be used directly by applications, the following projects haven also been officially released:
- Laf-Plugin release 1.0 (code-named Vile Weed) is available. The goal of this project is to provide a generic plugin framework for look-and-feels and define the interface of a common kind of plugins – the component plugins.
- Laf-Widget release 4.0 (code-named Iris) is available. The goal of this project is to provide support for and base set of additional behaviour and widgets in look-and-feels.
- Rainbow release 1.1 (code-named Nightstone) is available. The goal of this project is to illustrate various animation, transition and translucency techniques.
It has been a long journey. Flamingo 3.1 development has started in February, and i would like to thank Gunnar A. Reinseth, Pedro Duque Vieira, Kenneth Flynn in particular for their invaluable feedback during the development cycle. Substance 5.0 development has started in April, and i would like to thank all the early adopters for testing the development drops and providing their feedback in the project forums and mailing lists.
The work on both Flamingo and Substance is not finished. The plans for the next Flamingo release are available at the end of this entry, and plans for the next Substance releases will be published on this blog. If you are interested in using Substance to its fullest potential, you’re welcome to read the “From Photoshop to code” series.
Here are some Swing links that you might have missed during the last week:
This entry is going to summarize the process of taking the UI definitions from your designer and converting them to a live implementation. Illustrated by taking design of Cookbook UI (from the My Dream App contest) and turning it into a Swing application using Substance look-and-feel, the main five phases of this process are:
The customization layer of Substance (especially the painters) aims to create a customizable and powerful separation between painting layer and the rest of the application code (business logic such as persistence, authentication, communication and more). In this separation, Substance allows working on the application visuals as a separate work flow (although the process of mapping the application areas to Swing and Substance may require closer cooperation with implementing the actual UI container structure).
The ideal end result of this process is a self-contained implementation of the application skin that can be:
- tweaked as the design changes
- reused in other applications under the same portfolio
- even swapped out for a completely different appearance (such as using a native look-and-feel)
It took me about 20 hours to create the final visuals as shown below (click to see the full-sized version):
As the developer of Substance i have an advantage of knowing how the library is built and what APIs are available. My hope is that this series will make it easier for Swing developers to understand the customization layer of Substance and use it to its fullest potential.
An important question that needs to be addressed is: why do you need to do it with Substance? Why would you want to tie yourself to a third-party library when you can override paintComponent and use Java2D to create all the visuals? While you can most certainly do so (and in fact, the light bar holder is implemented this way), Substance gives you quite a few advantages:
- Cleaner separation of the painting logic from your main application. A close cooperation with your design team that is made aware of the current Substance limitations may result in zero custom painting code in your components even for such a complicated design as Cookbook UI.
- Performance improvements in version 5.0 (available tomorrow) bring Substance on par with the core look-and-feels. If your painting code is making heavy use of Java2D and images, you will need to provide a sophisticated caching layer to make sure that the UI remains responsive.
- Substance skin can be reused across multiple portfolio applications. Embedding custom painting code in your UI components may result in a code that is harder to refactor into reusable building blocks.
- Substance provides animation effects (rollover, selection, others) on the core and supported third-party components out of the box. These effects add a modern touch expected from visually rich applications.
- Substance supports third-party component suites, such as SwingX, Flamingo and (partially) JIDE. In addition, it provides a well-defined plugin mechanism to support additional third-party components.
- Substance makes your applications safer by checking EDT violations during the UI construction.
The code behind the process is available in the Substance Samples project that aims to provide a collection of blueprints for creating visually rich UIs in Swing.
