Swing's repaint has large memory overhead

[K.I.L.E.R]

Basically I had normal Swing GUI, which always takes 20MB of memory, as always I wanted to reduce memory overhead.

I also decided I wanted to make my app less resource demanding by only updating it 50fps.

So I stuck it in a loop and I set "setIgnoreRepaint(true)" and only manually repainting it every 50 frames.

This yielded a substantial improvement in Swing's responsiveness(This was a surprise because to me Swing was already very responsive) and a 3MB reduction in memory, now standing at 17,100KB of memory under Window's task manager.

It's obvious what the issue is; Java2D, and not Swing, is the cause of some overhead in Swing apps.

While others have known Java2D was responsible for Swing's bad name, I never did get any numbers of how large the overhead was.

Can I assume the Java2D team already knows about this overhead?

If you want to test this, do as I've done; grab a swing app, and manually repaint it by calling myFrame.repaint() for every 50fps.
Check both times the memory it takes and note the responsiveness.

System specs:
A64 3000+, 1GB DDR400 RAM, nForce 3 mobo and a Radeon 9700 Pro 128MB card.

[Linuxhippy]

Why should there be more overhead - I think you do not understand how Java handles its memory.

If you repaint the Swing stuff every frame, the paint(methods) of each component have to be invoked, and there are generated objects in this methods.
If you invoke this methods frequently, the GC is quite stressed - so to be not a performance bottleneck it enlarges the heap.

Thats it, no magic at all ;-)

lg Clemens

PS: Don't think to be clever

[K.I.L.E.R]

Ahhh, thanks.
Sun's clever design. The more I understand, the better I get.

So it's not a bug, but a design decision.

Why should there be more overhead - I think you do not understand how Java handles its memory.

If you repaint the Swing stuff every frame, the paint(methods) of each component have to be invoked, and there are generated objects in this methods.
If you invoke this methods frequently, the GC is quite stressed - so to be not a performance bottleneck it enlarges the heap.

Thats it, no magic at all ;-)

lg Clemens

PS: Don't think to be clever

Games published by our own members! Check 'em out!

[Linuxhippy]

So it's not a bug, but a design decision.
[/quote

GC-based languages/programs always use 10-40% more memory than they actually need, call it an ugly side-effect of GC based languages ;-)

lg Clemens