JDK now has a standard way of loading HiDPI icons on both MacOS, Linux, and Windows: An icon named "foo.png" can be paired with an icon named "[email protected]" of double resolution. Swing will then pick the best icon to use at any given point, even when a window is dragged from a HiDPI screen to a non-HiDPI screen in a multi-monitor setup. This kind of @2x resolution loading works with standard Image APIs such as "new ImageIcon(URL)". Relevant resolved JDK issues:
https://bugs.openjdk.java.net/browse/JDK-8011059 (MacOS support) https://bugs.openjdk.java.net/browse/JDK-8073320 (Windows support) https://bugs.openjdk.java.net/browse/JDK-8044189 (on making MacOS and Windows HiDPI work the same) https://bugs.openjdk.java.net/browse/JDK-8055212 (Windows & Linux) I think NetBeans should follow the same convention. Generating PNG files from SVG files is something that should be done at icon design time--often the icon designer needs to do pixel-level tweaks to the small version of the icon, or even remove some details for the icon to remain legible. This is especially the case for tiny 16x16 icons, or for the suuuuuper-tiny 8x8 icon "badges" that netbeans superimposes on project files to indicate errors, repo changes, and such. As far as NetBeans is concerned, the first step in better HiDPI support would be to get ImageUtilities to support the @2x.png loading convention on all platforms. I think Emilian has already some some of this work: https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407 b53d30e85ead1 . Questions for Emilian about the work you already did on ImageUtilities: (1) Did you ever try this on Windows? (I know you're a Mac guy, like me :-) (2) Are you taking advantage of the new interfaces that were added to Swing to handle HiDPI rendering? If so, that will likely make it easier to get your code working on Windows and Linux as well. I see you have a class that extends from MultiResolutionImage, which bodes well. (3) Does your code work when a window is dragged from a HiDPI screen to a non-HiDPI screen in a multi-monitor setup? Once ImageUtilities is made to support @2x loading, the next step is to actually update some of the icons. Some icons are much more important than others. In particular, just getting 2x versions of the Windows and Mac icons in openide.awt/src/org/openide/awt/resources would go a long way. Those are all the little UI buttons that are part of the core window system (maximize/close tab etc.). If I knew that ImageUtilities would support it, and if I have some free time one day, I might be tempted to do some of these myself. I'd just make them look exactly as they currently do, but at a double resolution (to avoid long design discussions). My next laptop will be a HiDPI Windows one, so I might have a chance to do more testing on that platform eventually. -- Eirik On 3/11/18, 5:13 PM, "Tim Boudreau" <[email protected]> wrote: >IMO, if we wanted to do this and be future-proof, the thing to do would be >to convert the icons to SVG or some similar vector format and update the >icon loading code in ImageUtilities to use it. > >There are some tools - particularly potrace - that can assist in initial >conversion, but deal in tracing lines and shapes and give 2- or 3- color >output (potrace lets you set a single interior color for closed shapes), >but which could be helpful as a start. > >Given that SVG is XML-based, I could imagine that just using something >like >Batik to load SVG would be unacceptable; but SVG could be used as a >designer-friendly input stage, and then be compiled by the build process >into something more performant (either literal Java code that paints the >contents of the svg, or some binary representation of drawing >instructions), much the same way resource bundle message annotations are >turned into static methods. > >I've written code before that implements a Graphics2D that simply stores a >list of everything it was told to do - wouldn't be that hard to take the >list of drawing instructions from there and generate Java code to >reproduce >those steps. > >Straw man example: > > - Code that uses an SVG icon is annotated with >@Icon("org/netbeans/modules/x/myIcon.svg") > - At build time: > - Annotation processor looks up that file, reads it with Batik, paints >it into a code-generating Graphics2D which outputs a generated static >method myIcon() on a generated class in the same package > - Code that wants to use the icon calls the static method, the same way >bundle messages are loaded in modern NetBeans code > - At run time: > - If using the generated static method, the output is just an image or >an icon, no surprises > - For the case where icons are shared across modules (this happens), >ImageUtilities could be tweaked to, in the case of a .svg extension, try >to >look up the generated class / method (and optionally fall back to Batik if >nobody minded a dependency on it, but that could be pluggable via Lookup >if >it's even needed) > >The hard part is converting to SVG, since turning an image into efficient >vectors is a genuinely hard problem where there are many non-optimal >answers and few optimal ones - particularly for converting gradients. I >could imagine getting a little better output by running the icon through >potrace with several color filters on it and combining the output. But >likely it simply requires a bunch of manual tweaking. > >-Tim > > >On Sun, Mar 11, 2018 at 4:07 PM, Emilian Bold <[email protected]> >wrote: > >> > In my opinion, the correct fix would be for applications to provide >> > higher resolution icons :) It's a win-win for everyone. >> >> https://nextbeans.com/retina >> https://jaxenter.com/netbeans/netbeans-retina >> >> --emi >> >> ??????? Original Message ??????? >> >> On 11 March 2018 9:49 PM, cowwoc <[email protected]> wrote: >> >> > I might be in the minority, but I actually prefer the new look. It >>makes >> > >> > Netbeans a lot easier to use in high DPI environments (yes, on >>Windows). >> > >> > Netbeans with JDK 8 looks super tiny. >> > >> > In my opinion, the correct fix would be for applications to provide >> > >> > higher resolution icons :) It's a win-win for everyone. >> > >> > Gili >> > >> > On 2018-03-11 3:14 PM, Neil C Smith wrote: >> > >> > > Hi, >> > > >> > > On Sun, 11 Mar 2018, 19:02 , [email protected] wrote: >> > > >> > > > It's a 13,3" FHD 1920 x 1080 with app scaling set to 150%. Not >>sure >> if >> > > > >> > > > that already counts as high dpi. >> > > >> > > Looks like you're not alone anyway >> > > >> > > https://bugs.openjdk.java.net/browse/JDK-8187367 >> > > >> > > Not sure if there's a workaround amongst that lot! >> > > >> > > Best wishes, >> > > >> > > Neil >> > > >> > > > -- >> > > > >> > > > Neil C Smith >> > > > >> > > > Artist & Technologist >> > > > >> > > > www.neilcsmith.net >> > > >> > > Praxis LIVE - hybrid visual IDE for creative coding - >> www.praxislive.org >> > >> > -- >> > >> > To unsubscribe, e-mail: [email protected] >> > >> > For additional commands, e-mail: >>[email protected] >> > >> > For further information about the NetBeans mailing lists, visit: >> > >> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> >> > > >-- >http://timboudreau.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
