> (3) Does your code work when a window is dragged from a HiDPI screen to a non-HiDPI screen in a multi-monitor setup?
I remember adding code specifically to handle this and dragging a window from my Retina screen to the other non-retina external display. Because otherwise retina assets might look worse scaled down than original non-retina assets. --emi ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On 23 April 2018 1:23 AM, Eirik Bakke <[email protected]> wrote: > 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 --------------------------------------------------------------------- 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
