It is now increasingly common for NetBeans to run on Windows, Linux, or MacOS machines with so-called "HiDPI" screens, aka. "retina" screens in the Apple world. These screens have about twice the physical pixel density of traditional screens, making it necessary to scale GUI graphics up by some amount, e.g. 150% or 200% (depending on OS and OS-level user settings), in order to remain readable. Since Java 9, this scaling is done automatically by AWT by means of a scaling default transform in each Component's Graphics2D instances. This makes text sharp on HiDPI screens, but leaves bitmap icons blurry. There are also various cases in which the JDK's automatic scaling of Graphics2D operations can lead to bugs or visual artifacts (in code written before HiDPI screens existed), which would ideally be fixed either in NetBeans or in the JDK itself.

Work already completed and merged as of NetBeans 11:

  • Windows launchers are properly marked as DPI-aware, enabling HiDPI handling at the Swing/AWT level.  Unable to render Jira issues macro, execution error.
  • Scalable window system icons on the Windows LAF.  Unable to render Jira issues macro, execution error.
  • Scalable window system icons on the MacOS (aqua) LAF.  Unable to render Jira issues macro, execution error.
  • Fix a tab control rendering artifact on retina screens on MacOS.  Unable to render Jira issues macro, execution error.

Work already completed and merged as of NetBeans 11.3:

  • Support scalable window system icons in the dark look and feel. Previously, this was Darcula LAF (see https://github.com/Revivius/nb-darcula/issues/160 ), but after 11.3, the new FlatLAF Dark theme has been introduced, which uses new scalable icons in the window system components.
  • Support HiDPI icons in ImageUtilities.
    • Support loading of SVG icons. Done.  Unable to render Jira issues macro, execution error.
    • Support loading of MultiResolutionImage instances based on filename suffixes (e.g. loading "icon.png" loads both "icon.png" and the larger-size "icon@2x.png"). (Meh, didn't end up taking this approach. It doesn't work on Windows in any case, due to JDK-8212226, see above. Also note that Windows and Linux users can use scaling factors other than 200%, e.g. 150%, probably making the SVG approach preferable.)  Unable to render Jira issues macro, execution error.
    • Make ImageUtilities.createDisabledIcon work with HiDPI icons (including custom Icon implementations). Done.  Unable to render Jira issues macro, execution error.
    • Make ImageUtilities.image2icon(ImageUtilities.icon2Image(icon)) reversible so that the original Icon instance is returned, even when the Icon is not an ImageIcon. For instance, the Icon could be an SVG icon (see above), or an instance of the new org.openide.util.VectorIcon class (which was created to support hand-painted LAF icons). (Done with  Unable to render Jira issues macro, execution error.  )
    • Make other ImageUtilities functions work with HiDPI icons/images (e.g. mergeImages). Emilian Bold did work on this for the MultiResolutionImage case, but it also needs to be made to work with SVG icons (for which it's not yet clear what kind of Image instance icon2image should return). (Done with Unable to render Jira issues macro, execution error. )
  • The memory gauge indicator in the toolbar is rendered in low resolution. ( Unable to render Jira issues macro, execution error. )
  • Support HiDPI icons in various NetBeans Platform APIs and their implementations, including icons loaded via action layer registrations. For instance, org.openide.nodes.Node.getIcon returns an "Image" rather than an "Icon"; if the Image was actually an SVG file loaded via ImageUtilities (see above) rather than a bitmap image, it should be rendered as such. (This was largely solved by making ImageUtilities.image2icon/icon2Image reversible; the Image-based APIs will work without modification.)

Relevant JDK-level bugs:

Windows 10 only:

Major tasks remaining:

  • Make DPI scaling happen automatically on Linux. Probably a matter of just enabling the right JDK/LAF options somehow.  Unable to render Jira issues macro, execution error.
  • Support scalable window system icons in the default LAF on Linux. Similar to the work done in https://github.com/apache/incubator-netbeans/pull/859 . Alternatively, we could switch to FlatLAF (light or dark) as the default theme on Linux.  Unable to render Jira issues macro, execution error.
  • Redraw or replace several hundred (or thousands) of NetBeans' most used bitmap icons with scalable equivalents (preferably SVG). This is a major task, see separate discussion below!
  • Various minor cosmetic UI tweaks as needed. E.g.:
    • When hovering over a long filename in the Projects pane, the tooltip that displays the obscured portion of the filename is rendered in low resolution ( Unable to render Jira issues macro, execution error. ). This problem occurs on MacOS, but not on Windows 10. On Windows 10 it would be good to improve the alignment of the border, however.
    • Green or red "Test Results" bar has low-resolution graphics ( Unable to render Jira issues macro, execution error. ).
    • "Drag not allowed" mouse cursor in OutlineView/TreeView needs HiDPI support.
    • Application toolbar needs the ability to use a single SVG resource for both possible settings of the "Small Toolbar Icons" action (enabled or disabled).

How to replace existing bitmap icons with scalable equivalents?

UPDATE: This effort is now tracked in NETBEANS-2617 and in this Google Sheet.

Even if the various NetBeans APIs can be made to support scalable icons (e.g. SVG), there are thousands of existing bitmap icons in the NetBeans repository that would have to be replaced with scalable (e.g. SVG) equivalents. See this page for a listing of all unique image files that existed in the NetBeans IDE mercurial repository prior to the Apache migration. This is a major effort, even if focused on only, say, the 200 most commonly seen icons. A few approaches are possible:

  1. Use a pixel art scaling algorithm to automatically scale the icons. Eirik Bakke did some experiments with this using the xBRZ algorithm; the results can be seen on https://people.csail.mit.edu/ebakke/misc/icons2xBRZ.html . Eirik thinks these do not look very good... though it could always be used as a fallback.
  2. Find replacement icons in an existing icon font library. Emilian Bold tried this approach and documented it at https://jaxenter.com/netbeans/netbeans-retina . Some manual work is included, but not as much as drawing new icons from scratch. The downside is that (1) quite a few NetBeans icons will have no suitable replacement in an existing font library, (2) icon font libraries yield monochromatic icons only, sacrificing the color of the old icons for an improvement in resolution, and (3) the style of new icons would appear mismatched next to old ones.
  3. Find replacement icons in the IntelliJ Community Edition codebase. IntelliJ had their own scalable icons drawn, and since IntelliJ is also an IDE, they are likely to have more icons "matching" those needed in NetBeans. Eirik took a look at these icons and concluded this option was not a substantially better alternative than (2). Besides, while the IntelliJ icons are released under an Apache 2.0 license, using them in the NetBeans IDE could cause brand confusion.
  4. Manually redraw the most displayed subset of NetBeans icons in Adobe Illustrator. Eirik Bakke did some experiments with this for his own NetBeans Platform application, and concluded this is an effort that requires on average 30 minutes of time per icon:

 

Creating new icons from scratch is a major task that will require a lot of time, although it does not require programming skills. It does require quite a bit of artistic taste, to get the right level of detail and sensible color combinations, and good familiarity with Adobe Illustrator. Ideally, all icons would be drawn by a single artist, to ensure a consistent style. Probably a style guide should be written up first (now done; see Unable to render Jira issues macro, execution error. ). In Eirik's opinion, if redrawing ends up being an option, it would be prudent to mostly keep the style and shape of the existing NetBeans icons, except removing gradients and bevels, which are, as of 2020, considered out of fashion (these effects also take more time to draw in Illustrator). The main advantage of keeping existing icon shapes is to save time; a lot of the work involved in designing an icon comes from deciding on its shape (e.g. "how do we visualize 'undo'"?). In cases where an existing bitmap icon is too cluttered and can be simplified, that's fine too; more complex icons take more time to draw.

Another option is to do a GoFundMe campaign to raise money to pay an icon design artist on Upwork or similar to create new SVG icons in Illustrator.

See the discussions at https://twitter.com/emilianbold/status/1102458017566654465 and https://twitter.com/eirikbakke/status/1114179794403516417 . See also this dicussion from a different open source project (Blender) which went through the same process.

A proposed prioritized list of initial icons to be redrawn is shown at https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.html . See  Unable to render Jira issues macro, execution error.  .

Potential Volunteers (feel free to add yourself to this list):

  • "I'd be up for helping out with that [icon-redrawing] effort. I have approximately zero artistic skill but icons are probably do-able ;-)" https://twitter.com/nicktail/status/1114234725151850496
  • Eirik Bakke has done some of the initial work here, and has a Windows 10 laptop with a HiDPI screen and multi-monitor setup to test with.

All Tagged JIRA Issues

In the Apache NetBeans JIRA, HiDPI/Retina-related issues should be tagged with the label "HiDPI". They will then show up here:

 

key summary type created updated reporter priority status resolution fixVersion

JQL and issue key arguments for this macro require at least one Jira application link to be configured

  • No labels