[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug awt/26486] Graphics.fillRect extremely slow
From: |
hendrich at informatik dot uni-hamburg dot de |
Subject: |
[Bug awt/26486] Graphics.fillRect extremely slow |
Date: |
6 Mar 2006 19:37:22 -0000 |
------- 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
- [Bug awt/26486] New: Graphics.fillRect extremely slow, hendrich at informatik dot uni-hamburg dot de, 2006/03/01
- [Bug awt/26486] Graphics.fillRect extremely slow, hendrich at informatik dot uni-hamburg dot de, 2006/03/01
- [Bug awt/26486] Graphics.fillRect extremely slow, hendrich at informatik dot uni-hamburg dot de, 2006/03/01
- [Bug awt/26486] Graphics.fillRect extremely slow, hendrich at informatik dot uni-hamburg dot de, 2006/03/02
- [Bug awt/26486] Graphics.fillRect extremely slow, fitzsim at redhat dot com, 2006/03/03
- [Bug awt/26486] Graphics.fillRect extremely slow, fitzsim at redhat dot com, 2006/03/04
- [Bug awt/26486] Graphics.fillRect extremely slow, fitzsim at redhat dot com, 2006/03/06
- [Bug awt/26486] Graphics.fillRect extremely slow,
hendrich at informatik dot uni-hamburg dot de <=
- [Bug awt/26486] Graphics.fillRect extremely slow, fitzsim at redhat dot com, 2006/03/06
- [Bug awt/26486] Graphics.fillRect extremely slow, hendrich at informatik dot uni-hamburg dot de, 2006/03/06
- [Bug awt/26486] Graphics.fillRect extremely slow, hendrich at informatik dot uni-hamburg dot de, 2006/03/06
- [Bug awt/26486] Graphics.fillRect extremely slow, fitzsim at redhat dot com, 2006/03/06
- [Bug awt/26486] Graphics.fillRect extremely slow, hendrich at informatik dot uni-hamburg dot de, 2006/03/07
- [Bug awt/26486] Graphics.fillRect extremely slow, hendrich at informatik dot uni-hamburg dot de, 2006/03/07
- [Bug awt/26486] Graphics.fillRect extremely slow, hendrich at informatik dot uni-hamburg dot de, 2006/03/07
- [Bug awt/26486] Graphics.fillRect extremely slow, fitzsim at redhat dot com, 2006/03/07
- [Bug awt/26486] Graphics.fillRect extremely slow, fitzsim at redhat dot com, 2006/03/07
- [Bug awt/26486] Graphics.fillRect extremely slow, fitzsim at redhat dot com, 2006/03/07