Java on the desktop - trail behind or lead forward?
Subpixel rendering has been around since 1988. Microsoft stepped on the scene circa 1998, applying for the patent on ClearType in 1999 and getting it in 2001. This technology has been integrated in Windows XP when LCD displays (both desktop and laptop) have been far outnumbered by CRT displays. However, when the time came, XP was ready. What about Java? The first implementation was available only in June 2005, with the official release a few months ago (good 8 years after it has been introduced by Microsoft).
What's the next big thing in desktop typography and general layout? High resolution displays, which also goes by the acronym DPI (dots per inch). Believe it or not, but the display makers don't stand still. While the 96 DPI holds the market majority now (like CRT monitors did in late 90s), the 120 DPI is just around the mass market corner. Is Swing ready? Unfortunately, the answer is "mostly no".
At Desktop Matters, Chet has held a mini-survey on possible additions to Swing in the next Java version. There were about 50 people in the room, and about 40 topics to vote on (one could vote on each one of them). If i remember correctly, the support for high-DPI displays raised about 10 hands, and when OS X was removed from the question, there were only 2 hands left (myself included). Even more interesting was Chet's phrasing of the question - it went something like "In a hundred years, when everybody has 9000 DPI monitors, how important is it for Java to support this?" Well, it won't be in a hundred years, it's already here and will only get bigger, and without immediate action Java once again will be left behind (providing it in another eight years circa Java SE 10).
Karsten has pioneered the support for high-DPI desktop settings in the Looks look and feel last year. He provides a layer that queries the desktop settings and tries to match the font family and the font size so that a Swing application running under this LAF doesn't make the user squint (if the texts are too small) or grunt (if the texts use inconsistent font). This is not all - as he mentions on the project dev mailing list, you have to scale everything else, including borders, separators, insets, margins etc.
In the next version of Substance i have decided to reuse Karsten's code (thanks for choosing a liberal BSD license :) and to take it one step forward - scale the entire UI. Currently, Looks doesn't scale the other UI elements, such as checkboxes, radio buttons, scroll arrows etc (see screenshots below). This may result in inconsistent user experience, especially for DPI settings higher than 120 (such as 144 or even 192). Here is the complete list of UI elements that is scaled with the DPI in the next Substance release (release candidate scheduled on April 2nd with the release scheduled on April 16th):
- Check marks of check boxes and radio buttons (regular and as menu items), dimension and stroke width
- Arrow icons of combo boxes, scroll bars, split pane dividers, submenus, tabbed panes (dimension and stroke width)
- Title pane icons (for decorated mode) of frames, dialogs, internal frames and desktop icons + proper centering of the title pane buttons in Y direction
- Scroll bar width
- Slider icon and slider track size
- Tab close buttons (dimension and stroke width)
- Spinner button width
- Password field mark size (diameter and gap)
- Progress bar width / height
- Double arrow icon stroke size
- Minimum width and height of buttons with text
- Insets of combo boxes, text field and spinners
- Stroke width of focus ring
Now for the screenshots. Here is a screenshot of an internal frame under 96 DPI (normal settings):
Here is the same internal frame under 120 DPI (125% normal size). Note how all the UI elements (fonts, scroll icons, title pane icons, button size, check marks and radio buttons, combobox insets) scale:
Here is the same internal frame under 144 DPI (150% normal size):
For comparison, here are the screenshots of the same internal frame under Looks Plastic XP. Under 96 DPI:
Here is the same internal frame under 120 DPI. Note that the scroll bar remains with the same width, the title pane buttons (inherited from Metal) remain the same size and uncentered and the combobox button doesn't retain its proportions (and the arrow icon itself has the same size):
Here is the same internal frame under 144 DPI (with the same visual inconsistencies):
What about other core and third party look and feels? As far as i know, the other third-party look and feels do not respect the DPI settings (and i'd be very happy to learn otherwise). The default (for now) Metal / Ocean doesn't scale at all, but the Windows look and feel shows some promise. How does it do so? Well, since it uses the native APIs to paint the controls, it also respects the dimensions computed by these APIs. In most cases (see the table below), Windows look and feel does indeed match the native dimensions of the controls and UI elements. Here is the same internal frame under Windows LAF in 96 DPI:
Here is the same internal frame under 120 DPI. Pretty much everything scaled, including fonts, checkbox and radio button marks, scroll bar, tabs and combo:
Here is the same internal frame under 144 DPI. Now, while fonts, scroll bar and tabs scaled, the checkbox / radio button icons and arrow icons on scroll bar / combobox remain the same size:
The reason for the later is simple - the native implementation is still not perfect. Here is the table to illustrate this:
The first three columns show size of different UI elements under Vista in 96, 120 and 144 DPI. The last two columns show size of the same UI elements under Windows look and feel in Java 6.0. As you can see, while the native elements scale well from 96 to 120 (with the exception of combobox arrow size), the transition from 120 to 144 is not so smooth. The checkbox / radio button checkmarks have the same size, and the arrows on scrollbars, spinners and comboboxes are the same.
What about Windows look and feel? While it picks most of the native settings, it still has some issues. Look at the spinners, tab heights, progress bar height (not picked at all), slider thumb, menu arrow and combobox. There's still work to do here.
Which brings me to my main point. The current implementation of high DPI support in Vista (and in XP) is not perfect, especially for 144+ range. In addition, changing DPI setting requires OS restart (and once Explorer crashed under 144 DPI). Java must seize this opportunity now and provide the best implementation for the mass-market. Java shouldn't wait until the market demands this support (especially with releases coming out every 18 months and with the relatively slow adoption rate of the latest releases in production environments on the large scale). Be ahead of the curve, don't lag behind.