You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Eirik Bakke <eb...@ultorg.com> on 2018/04/22 22:23:57 UTC
Re: dpi on Windows Java 9
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
"foo@2x.png" 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" <ni...@gmail.com> 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 <em...@protonmail.ch>
>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 <co...@bbs.darktech.org> 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 , toni.epple@eppleton.de 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: dev-unsubscribe@netbeans.incubator.apache.org
>> >
>> > For additional commands, e-mail:
>>dev-help@netbeans.incubator.apache.org
>> >
>> > For further information about the NetBeans mailing lists, visit:
>> >
>> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>
>> 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: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: dpi on Windows Java 9
Posted by Emilian Bold <em...@protonmail.ch>.
> (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 <eb...@ultorg.com> 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
>
> "foo@2x.png" 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" niftiness@gmail.com 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 emilian.bold@protonmail.ch
> >
> > 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 cowwoc@bbs.darktech.org 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 , toni.epple@eppleton.de 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: dev-unsubscribe@netbeans.incubator.apache.org
> > > >
> > > > For additional commands, e-mail:
> > > >
> > > > dev-help@netbeans.incubator.apache.org
> > > >
> > > > For further information about the NetBeans mailing lists, visit:
> > > >
> > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > >
> > > To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> > >
> > > For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> > >
> > > 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: dev-unsubscribe@netbeans.incubator.apache.org
>
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists