Skip to main content

Nimbus only on Windows?

8 replies [Last post]
Joined: 2004-01-07


Will Nimbus also be the default toolkit on Linux/Solaris?
I wonder because I tested it on my 2ghz-Core2Duo machine and it does not seem very usebale when using the X11 pipeline, because most work is done by the software-loops then.

In its current state I would not make Nimbus default, however on the other side would it be a good idea to provide different Cross-Platform-LnFs? (the JDesktopPane background is a _real_ performance sucker - why not cache it?)

Good job, lg Clemens

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-09-06

I would like to know a bit more details of what sort of application you are having difficalties with, screenshot would be a great help. The performance should be good in all but the case where you are resizing a JFrame with JDesktopPane inside it. Richard is developing on Solaris in a virtual machine on a Mac laptop 1.8Ghz and Nimbus runs fine.

Thanks, Jasper

Joined: 2004-01-07

Its runs a lot slower than swing for almost all actions I do:
- Moving the JFrame inside of JDesktopPane (it seems background painting is slow)
- Scrolling panels is slow (only buttons, textfields and Labels)
-Resizing something is slow too
- Moving a JFrame over another is slow...

It feels slower under almost any situations that require many repaints to feel fluently.

Those are ordinary swing panels, layouted with GroupLayout/Netbeans. My NOtebook has 2GB of Ram, an Intel-GMA950 (which is extremly fast at vram readbacks because shared memory) and a Core2Duo 2ghz 4mb l2 cache.
I don't have any problems with other 2D apps.

I am a bit worried because thats a traditional desktop app and it performs really bad even on my quite fast machine.
What would happen if somebody using a 1-ghz celeron desktop box ... it would maybe really anoying :-/

java2d.trace=count during the screenshots gave:
134 calls to sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
83481 calls to sun.java2d.loops.TransformHelper::TransformHelper(IntArgb, SrcNoEa, IntArgbPre)
173 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntRgb, AnyAlpha, IntArgb)
7502 calls to X11DrawLine
659 calls to X11CopyArea
160 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntArgb)
62232 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, "Integer RGB Pixmap")
483 calls to X11DrawGlyphs
263627 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntRgb)
13838 calls to X11FillRect
36 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb)
10272 calls to sun.java2d.loops.DrawGlyphListLCD::DrawGlyphListLCD(AnyColor, SrcNoEa, IntRgb)
61564 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb)
238 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgb)
2028 calls to sun.java2d.x11.X11PMBlitLoops::Blit("Integer RGB Pixmap", SrcNoEa, "Integer RGB Pixmap")
62398 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntRgb)
34284 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntRgb, AnyAlpha, IntRgb)
603109 total calls to 17 different primitives

So almost only software rendering :-/

Also its sad that bevel-border buttons also have such a circle in it (as seen in slow, where a small button only holds an image) ... and ComboBoxes are really small overall.

I uploaded the screenshots to my picasa web album:

lg Clemens

Joined: 2003-12-31

It's true, most of the Nimbus' rendering can't be accelerated by the X11 pipeline
because of X11 limitations (no AA, no translucency, etc).

If you had a better board you could have tried the opengl pipeline but with your
chipset I'm afraid you're out of luck.

Could you try this:
- set env variable J2D_PIXMAPS=shared
or, separately
- run your app with -Dsun.java2d.pmoffscreen=false

See which one helps more..


Joined: 2004-01-07

Hi Dimitri,

Thanks for the suggestion. I really like the OpenGL pipeline - the big problem is however it doesn't work most of the time (boards, distros, drivers) and furthermore isn't enabled by default (and applets like my application don't even have that choice, except complex option-switching in the Control-Center) .
Is nimbus also planned as the default-toolkit for Linux? For now I am not sure whether its really a good idea to trade look-and-feel for usability and performance.

I really don't know which way Java should go. XRender seems quite well suited for most tasks, on the other side its adaption-rate is low and there's only very little progress to get better driver support.Exa still seems far away from beeing complete (many users complain bad performance for even the Intel chipset, one of the best exa drivers arround).
OpenGL on the other way seems quite heavyweight, the open-source drivers seem totally limited and the commercial ones are extremely tuned for games. (e.g. the nvidia driver on Linux consumes ~20mb per OpenGL app just for buffers and behaves bad with many side-by-side contexts) and you loose all the cool benefits of X11 like glyph-caching which has to be done seperatly for every app.

So to bet on OpenGL is maybe a bit a radical step, to enhance the X11 pipeline to use XRender if available maybe lost effort.

lg Clemens

Joined: 2003-12-31

FYI, I'm not even sure Nimbus will be the default L&F on Windows: since it changes the metrics (and thus layout) it may introduce great incompatibilities.

As for Nimbus on X11 - there may be a way to tweak the L&F on X (use less
translucency, things of that sort),
along with choosing better X11 pipeline rendering mode (with or w/o pixmaps,
shared memory pixmaps etc).


Joined: 2004-01-07

Well I am a bit against Nimbus as default, I guess it would do the same for the GDI/DDraw pipeline as it does on X11. Furthermore most PCs which will not be able to run the D3D pipeline will also have slow CPUs ... which would java make appear slow again.
And last but not least it also introduces visual glitches in my application ;)

However I am very happy about the efforts to create a modern cross-platform UI.

lg Clemens

Joined: 2003-12-31

First, there's no longer a DDraw pipeline.. Only GDI or D3D.

And, Nimbus works pretty well with the GDI pipeline. Most of the rendering
is done by our software loops, GDI is only used when copying
back-buffer to the screen). Try it - disable the d3d pipeline with
-Dsun.java2d.d3d=false . There may be issues with huge
frames/scrolling, though.

On X11 it's not the slowness of our software rendering, it's the fact
that the backbuffer lives in an X11 Pixmap. As I suggested in my other
post, you can try disabling that with -Dsun.java2d.pmoffscreen=false
property and see if it helps.


Joined: 2004-01-07

I tried -Dsun.java2d.pmoffscreen=false, and its really a lot better.
Scrolling the panel with the textfield is now possible without a stutter-effect :)

JInternalFrame movement and resizing are still slow, I guess partly because of the complex background of the JDesktopFrame (is that cached?).

Thanks, lg Clemens