This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
NB trunk continuous build 20040525-1150 NB refactoring build 040524. JDK1.4.2_04. The drawing of "Memory" toolbar action is very slow on Linux. Simply open NB, open the Memory toolbar action and switch OS-workspaces or otherwise force NB to redraw. It takes ages to redraw (the NB main window is gray for ages, only the Memory view is being redrawn). It is probably caused by smooth colors in Memory view. I have made a few full thread dumps during the NB window redrawal (these thread dumps are from the continuous build 20040525-1150). It is much more visible in the refactoring build, but it is quite reproducible in the trunk NB build.
Created attachment 15134 [details] A few full thread dumps while the NB main window is being redrawn.
To clarify myself: if I switch the Memory view off, the IDE is quite responsive. When I switch the Memory view on, it is nearly unusable (in particular when I change the OS-workspaces often). This is why I suspect Memory view (action). I think that the thread dumps confirm this.
I'll have a look at it.
this is definitely a problem on Lahoda's linux laptop. Java2D transluency performance there is horrible. Windows seems to be okay. In any case, it's wise to turn off the memory meter when one measures actions which fall into the 100ms category
I'm not sure if the problem is on "Lahoda's linux desktop". Let's say "any linux desktop". AFAIK Marek Grummich has the same problem.
I didn't say "only on Lahoda's laptop". We knew it's definitely a problem for remote X. I don't have troubles on my linux laptop (Tecra S1, Radeon Mobility 9000, XFree 4.3)
I don't know who came with the idea to use GradientPaint - it eats 100kB per second just to paint the memory meter. With simple Color it is 15kB per second. BTW: there is a bug that is not visible just because every time we change the memory use. If the timer ticks and update method sets text to the same value no repainting is forced. It should use something like if (text.equals(getText())) { repaint(); } else { setText(text); } instead of setText(text).
I asked Petr N to revert the painting back to the old boring but lightweght one.
Note that if the GradientPaint objects are a problem there, it will probably also be a problem for any look and feel except Metal - winsys uses GradientPaint objects heavily for, e.g. GTK L&F. Note that I notice one third party look and feel uses its own GradientPaint impl, presumably for this reason. For simple things that could be a good idea for us.
Fixed in openide/src/org/openide/actions/GarbageCollectAction.java,v1.29
verified in [nb_dev](200408101800)