[Bug awt/26486] Graphics.fillRect extremely slow

[hendrich at informatik dot uni-hamburg dot de]

------- Comment #8 from hendrich at informatik dot uni-hamburg dot de  
2006-03-06 19:37 -------
Subject: Re:  Graphics.fillRect extremely slow

> The gdk_flush calls are there for a reason.  The AWT allows applications to
> make graphics calls from any thread but GDK prefers that all painting be done
> in the main thread.  Where that's not the case the app must explicitly call
> gdk_flush after calling the paint routines, otherwise painting won't be done
> on-screen until the end of the current gdk main loop iteration.

Well, you are the expert here :-)

On the other hand, you asked me to do the experiment. A factor of four
performance penalty under JamVM is bad enough news, but the data I posted
shows that a faster VM (like gcj) incurs an even worse penalty.

My question was whether we could remove the gdk_flush() calls after
every atomic paint operation, and instead perform a single gdk_flush()
just before repainting a component - perhaps e.g. at the end of the Swing 
paintComponent() and AWT paint/update() methods? For animations similar 
to GameOfLife, this reduces the amount of gdk_flush() calls from ~100000 
per second to about 50 per second. (This assumes that gdk_xxx calls
are possible in a multi-threaded environment.)

AFAIR the AWT thread model allows that multiple threads may access
AWT components concurrently - this includes painting and things like
resizing, showing/hiding components, etc. I don't recall that the
AWT specifies that concurrent Graphics calls will be executed in any
specific order. Neither is component.getGraphics().drawXXX() guaranteed 
to show on-screen before the next repaint, or is it?

If an animation fails because it expects atomic drawXXX and fillXXX
operations to immediately show on-screen, the application might need
to be fixed...

- Norman


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26486