[Bug awt/26486] Graphics.fillRect extremely slow

[hendrich at informatik dot uni-hamburg dot de]

------- Comment #22 from hendrich at informatik dot uni-hamburg dot de  
2006-03-10 10:17 -------
Subject: Re:  Graphics.fillRect extremely slow

> Please disregard the numbers in Comments 18 and 19.  Because of a bug in GNU
> Classpath's build machinery (PR 26623), I was testing the same patch both
> times.  Here are the actual results for GCJ:

one bug report almost always triggers the next ;-)


> I think these results are pretty conclusive.

yep. Thanks for fixing this; applications using lots of drawing should 
run much faster now.


> - oneslime.net hardly flickers at all but feels sluggish.
> - oneslime.net flickers badly but is fast and playable
> - oneslime.net is unplayably choppy

Do you have the source code for oneslime?  

I tried to look at the source code, but failed to find a download.
If you don't have the source code, I am not sure that oneslime is
the best reference application for gcj/classpath - except for its
historical value of being the first applet/game ever running with
classpath, of course. I have received (mild) flak on gcj/classpath 
lists for using non-open-source apps as tests myself...

Using javap on the class files shows that there is a paint() method,
but no update() method. The flickering indicates that oneslime doesn't
use its own double-buffering. Therefore, the lack of update() is a 
strong indication of a "broken" design - prone to flicker.

Perhaps we can find another reference app for testing and benchmarking
animations?

- Norman


-- 


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