------- 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 _______________________________________________ Bug-classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-classpath
