You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Scott Palmer <sw...@gmail.com> on 2020/02/02 18:28:30 UTC
Memory usage text rendering issue
Does anyone else see really ugly text in the memory usage widget on the toolbar? This has been an issue for a while and I can’t recall if I have reported it or it is already a known issue. It seems like something that shouldn’t be hard to address. The text showing heap used vs available heap is rendered in such a way that the letters are very puffy and jagged. Almost like any anti-aliasing that would be blending the edges has the alpha channel interpreted as a binary 0% or 100% opacity. I’ve attached an image, not sure if it will are it through.
I’m testing NB 11.3-beta 2 with JDK 13.0.2 on macOS 10.15.3 (beta)
Regards,
Scott
Re: Memory usage text rendering issue
Posted by Peter Hull <pe...@gmail.com>.
On Mon, 3 Feb 2020 at 21:23, Laszlo Kishalmi <la...@gmail.com>
wrote:
> +1 for make it more simple!
>
> I have made a PR, https://github.com/apache/netbeans/pull/1918.
Images of current / proposed are in the PR. Please let me know if you have
any comments and also if you are able to test it on Mac, Linux, different
HiDPI settings that would be great.
Pete
Re: Memory usage text rendering issue
Posted by Laszlo Kishalmi <la...@gmail.com>.
+1 for make it more simple!
On 2/3/20 1:07 PM, Peter Hull wrote:
> On Mon, 3 Feb 2020 at 15:43, Eirik Bakke <eb...@ultorg.com> wrote:
>
>> You could make it work, but it will be easier to just redo the drawing
>> code directly. And it can really be something much simpler than what is
>> there now--no gradients etc, axis marker lines or anything. Just a single
>> polygon of a solid color (for the chart) with the text drawn on top. This
>> would look a lot more modern.
>>
>> I'll give it a go.
> Pete
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Memory usage text rendering issue
Posted by Peter Hull <pe...@gmail.com>.
On Mon, 3 Feb 2020 at 15:43, Eirik Bakke <eb...@ultorg.com> wrote:
> You could make it work, but it will be easier to just redo the drawing
> code directly. And it can really be something much simpler than what is
> there now--no gradients etc, axis marker lines or anything. Just a single
> polygon of a solid color (for the chart) with the text drawn on top. This
> would look a lot more modern.
>
> I'll give it a go.
Pete
Re: Memory usage text rendering issue
Posted by Tim Boudreau <ni...@gmail.com>.
Oh, sooner or later “flat” will look dated and old, and the gradients will
be back.
If you really wanted to do this right, create a MemoryMeterUI Swing UI
delegate, split the flat and gradient code into two implementation of it,
and have core.swing.plaf toss the name of the default one in UIManager on
startup, and the look and feel can override it if it wants.
(I’m not that serious that that’s a great use of anyone’s time, but it
would be the right way to solve it).
-Tim
On Fri, Feb 28, 2020 at 6:31 AM Emilian Bold <em...@gmail.com> wrote:
> > I believe the ugliness was caused by rendering the text + dropshadow
> into a buffer created with the 'nominal' pixel dimensions, then
> causing it to scale up a bit by drawing it on to the HiDPI screen
> (e.g. a 125% scale, which resulted in blockiness). As mentioned by
> David Green above it looks OK if the drop shadow effect is turned off.
> In this case text was drawn straight onto the Graphics2D.
>
> Can confirm I disabled dropped shadow on macOS and it was acceptable.
>
> I also never liked the gradient so if by getting rid of it we clean up
> some complex code, even better.
>
> --emi
>
> On Fri, Feb 28, 2020 at 1:04 PM Peter Hull <pe...@gmail.com> wrote:
> >
> > On Fri, 28 Feb 2020 at 10:37, Tim Boudreau <ni...@gmail.com> wrote:
> > > I happened to be around to chat with the author of that code
> > Thanks for the info; I mentioned above that the code seemed strangely
> > complicated and I could not find any comments or history to explain
> > it.
> > > The reason: GradientPaint's allocate large rasters (large being
> int[width
> > > * height * 4]) on every repaint.
> > I did not know this. But, the updated widget doesn't use gradient
> > paints any more, just a flat colour filled polyline and some text, so
> > hopefully we won't get that problem.
> >
> > > Most likely the root of the problem is simply
> > > theGraphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
> > > RenderingHints.VALUE_ANTIALIASING_ON)
> > I believe the ugliness was caused by rendering the text + dropshadow
> > into a buffer created with the 'nominal' pixel dimensions, then
> > causing it to scale up a bit by drawing it on to the HiDPI screen
> > (e.g. a 125% scale, which resulted in blockiness). As mentioned by
> > David Green above it looks OK if the drop shadow effect is turned off.
> > In this case text was drawn straight onto the Graphics2D.
> >
> > If you wouldn't mind running an eye over the code that would be great!
> >
> > Pete
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@netbeans.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.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com
Re: Memory usage text rendering issue
Posted by Emilian Bold <em...@gmail.com>.
> I believe the ugliness was caused by rendering the text + dropshadow
into a buffer created with the 'nominal' pixel dimensions, then
causing it to scale up a bit by drawing it on to the HiDPI screen
(e.g. a 125% scale, which resulted in blockiness). As mentioned by
David Green above it looks OK if the drop shadow effect is turned off.
In this case text was drawn straight onto the Graphics2D.
Can confirm I disabled dropped shadow on macOS and it was acceptable.
I also never liked the gradient so if by getting rid of it we clean up
some complex code, even better.
--emi
On Fri, Feb 28, 2020 at 1:04 PM Peter Hull <pe...@gmail.com> wrote:
>
> On Fri, 28 Feb 2020 at 10:37, Tim Boudreau <ni...@gmail.com> wrote:
> > I happened to be around to chat with the author of that code
> Thanks for the info; I mentioned above that the code seemed strangely
> complicated and I could not find any comments or history to explain
> it.
> > The reason: GradientPaint's allocate large rasters (large being int[width
> > * height * 4]) on every repaint.
> I did not know this. But, the updated widget doesn't use gradient
> paints any more, just a flat colour filled polyline and some text, so
> hopefully we won't get that problem.
>
> > Most likely the root of the problem is simply
> > theGraphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
> > RenderingHints.VALUE_ANTIALIASING_ON)
> I believe the ugliness was caused by rendering the text + dropshadow
> into a buffer created with the 'nominal' pixel dimensions, then
> causing it to scale up a bit by drawing it on to the HiDPI screen
> (e.g. a 125% scale, which resulted in blockiness). As mentioned by
> David Green above it looks OK if the drop shadow effect is turned off.
> In this case text was drawn straight onto the Graphics2D.
>
> If you wouldn't mind running an eye over the code that would be great!
>
> Pete
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.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.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Memory usage text rendering issue
Posted by Peter Hull <pe...@gmail.com>.
On Fri, 28 Feb 2020 at 10:37, Tim Boudreau <ni...@gmail.com> wrote:
> I happened to be around to chat with the author of that code
Thanks for the info; I mentioned above that the code seemed strangely
complicated and I could not find any comments or history to explain
it.
> The reason: GradientPaint's allocate large rasters (large being int[width
> * height * 4]) on every repaint.
I did not know this. But, the updated widget doesn't use gradient
paints any more, just a flat colour filled polyline and some text, so
hopefully we won't get that problem.
> Most likely the root of the problem is simply
> theGraphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
> RenderingHints.VALUE_ANTIALIASING_ON)
I believe the ugliness was caused by rendering the text + dropshadow
into a buffer created with the 'nominal' pixel dimensions, then
causing it to scale up a bit by drawing it on to the HiDPI screen
(e.g. a 125% scale, which resulted in blockiness). As mentioned by
David Green above it looks OK if the drop shadow effect is turned off.
In this case text was drawn straight onto the Graphics2D.
If you wouldn't mind running an eye over the code that would be great!
Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Memory usage text rendering issue
Posted by Tim Boudreau <ni...@gmail.com>.
>
>
> > and the current code *does* go through a BufferedImage.
> That's what I figured... I'd recommend redoing it without.
>
DO NOT.
I happened to be around to chat with the author of that code - Scott
Violet, at the time one of the lead developers on the Swing team, when he
rewrote that component - this was around the time of the defunct Swing
Application Framework JSR, and being friends with a few guys on the Swing
team, hung out in their offices in Santa Clara a good bit.
The reason: GradientPaint's allocate large rasters (large being int[width
* height * 4]) on every repaint. That creates a ton of GC pressure and
memory churn from something that's repainting itself on a timer, for
absolutely no reason.
The solution: Keep an offscreen BufferedImage with the gradient, which
only ever needs to be painted *once*, and then clear area that was *not* the
graph. A solution I suggested to Scott, who said (with an unspoken
trailing "you idiot") "Yeah, that's what I just wrote."
Anyway, it's like that for a very legitimate reason.
If there are scaling issues, try using (on the component)
getGraphicsConfiguration().createCompatibleImage(width,
height) (and if you want to be anal about it, keep track of the
GraphicsConfiguration and recreate it if it changes [window was moved to a
different size monitor]) - or if creating it independent of component
creation, GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().createCompatibleImage(width,
height) (but don't expect it to necessarily be right in a multi-monitor
setup).
Most likely the root of the problem is simply
theGraphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_ANTIALIASING_ON)
At any rate, it is using an offscreen BufferedImage for a very good reason,
and I'd strongly recommend not ripping that out unless you want to cause a
completely pointless performance issue.
-Tim
RE: Memory usage text rendering issue
Posted by Eirik Bakke <eb...@ultorg.com>.
> Sorry if it wasn't clear - this is all about Scott Palmer's issue with the HeapView widget
Yes!
> and the current code *does* go through a BufferedImage.
That's what I figured... I'd recommend redoing it without.
> I've made some mods which do improve things IMO, but these are drawing directly on the Graphics2D. This means the blur effect of the current code, using ConvolveOp, can't be done.
That's fine--those visual effects are out of fashion nowadays in any case.
> I tried using the cheap & cheerful way of drawing the text twice, the first time displaced and in a darker colour
That will work instead of the blur/drop shadow.
> If I understand correctly you're saying that there's no easy way to get it to work through BufferedImage? If so I can put in a pull request for my 'direct drawing' code.
You could make it work, but it will be easier to just redo the drawing code directly. And it can really be something much simpler than what is there now--no gradients etc, axis marker lines or anything. Just a single polygon of a solid color (for the chart) with the text drawn on top. This would look a lot more modern.
-- Eirik
-----Original Message-----
From: Peter Hull <pe...@gmail.com>
Sent: Monday, February 3, 2020 10:33 AM
To: dev@netbeans.apache.org
Subject: Re: Memory usage text rendering issue
On Mon, 3 Feb 2020 at 15:12, Eirik Bakke <eb...@ultorg.com> wrote:
> Do you have HiDPI scaling activated? (Check "Scale and Layout" in the
> windows Display control panel.)
>
> To make things like this work well on HiDPI screens, it's best not to
> go through a BufferedImage, but rather draw directly on the supplied
> Graphics2D.
>
Hi Eirik,
Sorry if it wasn't clear - this is all about Scott Palmer's issue with the HeapView widget - and the current code *does* go through a BufferedImage.
My gist was just confirming that there is a difference in the output of the two methods (and I was hoping someone would know the 'magic' rendering hints which would make them the same!)
I've made some mods which do improve things IMO, but these are drawing directly on the Graphics2D. This means the blur effect of the current code, using ConvolveOp, can't be done.
If I understand correctly you're saying that there's no easy way to get it to work through BufferedImage? If so I can put in a pull request for my 'direct drawing' code.
Let me know what you think as I am not an expert in this.
Pete
Re: Memory usage text rendering issue
Posted by Peter Hull <pe...@gmail.com>.
On Mon, 3 Feb 2020 at 15:12, Eirik Bakke <eb...@ultorg.com> wrote:
> Do you have HiDPI scaling activated? (Check "Scale and Layout" in the
> windows Display control panel.)
>
> To make things like this work well on HiDPI screens, it's best not to go
> through a BufferedImage, but rather draw directly on the supplied
> Graphics2D.
>
Hi Eirik,
Sorry if it wasn't clear - this is all about Scott Palmer's issue with the
HeapView widget - and the current code *does* go through a BufferedImage.
My gist was just confirming that there is a difference in the output of the
two methods (and I was hoping someone would know the 'magic' rendering
hints which would make them the same!)
I've made some mods which do improve things IMO, but these are drawing
directly on the Graphics2D. This means the blur effect of the current code,
using ConvolveOp, can't be done.
If I understand correctly you're saying that there's no easy way to get it
to work through BufferedImage? If so I can put in a pull request for my
'direct drawing' code.
Let me know what you think as I am not an expert in this.
Pete
RE: Memory usage text rendering issue
Posted by Eirik Bakke <eb...@ultorg.com>.
Do you have HiDPI scaling activated? (Check "Scale and Layout" in the windows Display control panel.)
To make things like this work well on HiDPI screens, it's best not to go through a BufferedImage, but rather draw directly on the supplied Graphics2D.
If you want to use a BufferedImage, you would need to detect the supplied Graphics2D's scaling level from its current transform, create a correspondingly larger BufferedImage, and then apply a transform to scale it back down to the logical dimensions before painting the BufferedImage to the original Graphics2D. It's generally much easier to just just draw to the originally supplied Graphics2D. Also, if you want to use a backbuffer, beware that text rendering can end up looking different on BufferedImage vs. VolatileImage (on Windows or MacOS--can't remember which one).
-- Eirik
From: Peter Hull <pe...@gmail.com>
Sent: Monday, February 3, 2020 9:27 AM
To: dev@netbeans.apache.org
Subject: Re: Memory usage text rendering issue
I made a simple example, https://gist.github.com/pedro-w/b089e23db7aca037266b41cfc9c2ec2f
On windows, I see this:
[Annotation 2020-02-03 142402.jpg]
I think the unpleasant rendering in the 'Rendered via Image' sample accounts for what you can see in the Memory usage widget (it's worse for smaller text)
I suppose there is some RenderingHints which can fix this, unfortunately I haven't time to google just now!
Pete
Re: Memory usage text rendering issue
Posted by Peter Hull <pe...@gmail.com>.
I made a simple example,
https://gist.github.com/pedro-w/b089e23db7aca037266b41cfc9c2ec2f
On windows, I see this:
[image: Annotation 2020-02-03 142402.jpg]
I think the unpleasant rendering in the 'Rendered via Image' sample
accounts for what you can see in the Memory usage widget (it's worse for
smaller text)
I suppose there is some RenderingHints which can fix this, unfortunately I
haven't time to google just now!
Pete
Re: Memory usage text rendering issue
Posted by Peter Hull <pe...@gmail.com>.
On Mon, 3 Feb 2020 at 12:38, Scott Palmer <sw...@gmail.com> wrote:
> How is the BufferedImage created? What is the pixel format?
>
It is BufferedImage.TYPE_INT_ARGB
Reference:
https://github.com/apache/netbeans/blob/820a688606a3777c673ab6cfb3d6638fe87471cc/platform/openide.actions/src/org/openide/actions/HeapView.java#L663
Pete
Re: Memory usage text rendering issue
Posted by Scott Palmer <sw...@gmail.com>.
How is the BufferedImage created? What is the pixel format?
Scott
> On Feb 3, 2020, at 7:29 AM, Peter Hull <pe...@gmail.com> wrote:
>
>
>> On Sun, 2 Feb 2020 at 18:28, Scott Palmer <sw...@gmail.com> wrote:
>> Does anyone else see really ugly text in the memory usage widget on the toolbar?
> I had a quick look at this. It's very odd, rendering text into a Graphics2D derived from a BufferedImage (which is what the current dropshadow does) comes out differently from rendering to the Graphics2D supplied to the paintComponent method. Also the current code seems quite complicated and I'm not sure why. e.g. it creates a new Runnable to render the text.
> I tried using the cheap & cheerful way of drawing the text twice, the first time displaced and in a darker colour. It is more subtle than the current method of using ConvolveOps etc. but looks "not terrible" to my eye. To be honest, not having a drop shadow at all looks fine to me.
> Let me know what you think of the image below:
>
> The change is just one file, with 13 insertions and 94 deletions, so just a slight reduction in LOC.
Re: Memory usage text rendering issue
Posted by Peter Hull <pe...@gmail.com>.
On Sun, 2 Feb 2020 at 18:28, Scott Palmer <sw...@gmail.com> wrote:
> Does anyone else see really ugly text in the memory usage widget on the
> toolbar?
>
I had a quick look at this. It's very odd, rendering text into a Graphics2D
derived from a BufferedImage (which is what the current dropshadow does)
comes out differently from rendering to the Graphics2D supplied to the
paintComponent method. Also the current code seems quite complicated and
I'm not sure why. e.g. it creates a new Runnable to render the text.
I tried using the cheap & cheerful way of drawing the text twice, the first
time displaced and in a darker colour. It is more subtle than the current
method of using ConvolveOps etc. but looks "not terrible" to my eye. To be
honest, not having a drop shadow at all looks fine to me.
Let me know what you think of the image below:
[image: Annotation 2020-02-03 121418.jpg]
The change is just one file, with 13 insertions and 94 deletions, so just a
slight reduction in LOC.
RE: Memory usage text rendering issue
Posted by Eirik Bakke <eb...@ultorg.com>.
Yes, that's an issue that's existed for a long time. I created a JIRA ticket for it just now at https://issues.apache.org/jira/browse/NETBEANS-3785 .
(Anyone, feel free to fix it. Would be good to ensure that it looks good on HiDPI/Retina displays as well.)
-- Eirik
From: Scott Palmer <sw...@gmail.com>
Sent: Sunday, February 2, 2020 1:29 PM
To: Apache NetBeans <de...@netbeans.apache.org>
Subject: Memory usage text rendering issue
Does anyone else see really ugly text in the memory usage widget on the toolbar? This has been an issue for a while and I can’t recall if I have reported it or it is already a known issue. It seems like something that shouldn’t be hard to address. The text showing heap used vs available heap is rendered in such a way that the letters are very puffy and jagged. Almost like any anti-aliasing that would be blending the edges has the alpha channel interpreted as a binary 0% or 100% opacity. I’ve attached an image, not sure if it will are it through.
I’m testing NB 11.3-beta 2 with JDK 13.0.2 on macOS 10.15.3 (beta)
[cid:image001.jpg@01D5D9D7.03A4B6A0]
Regards,
Scott
Re: Memory usage text rendering issue
Posted by David Green <dg...@gmail.com>.
On 2 Feb 2020, at 12:28, Scott Palmer wrote:
> Does anyone else see really ugly text in the memory usage widget on
> the toolbar? This has been an issue for a while and I can’t recall
> if I have reported it or it is already a known issue. It seems like
> something that shouldn’t be hard to address. The text showing heap
> used vs available heap is rendered in such a way that the letters are
> very puffy and jagged. Almost like any anti-aliasing that would be
> blending the edges has the alpha channel interpreted as a binary 0% or
> 100% opacity. I’ve attached an image, not sure if it will are it
> through.
> I’m testing NB 11.3-beta 2 with JDK 13.0.2 on macOS 10.15.3 (beta)
I mitigate most of it by right-clicking on the image and choosing to
disable “drop shadow”.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists