Bug 27926 - Graphics2D drawing primitives performance (and demo)
Summary: Graphics2D drawing primitives performance (and demo)
Status: UNCONFIRMED
Alias: None
Product: classpath
Classification: Unclassified
Component: awt (show other bugs)
Version: 0.92
: P3 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-07 09:46 UTC by Norman Hendrich
Modified: 2007-04-11 18:55 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
testcase (3.37 KB, text/plain)
2006-06-07 09:46 UTC, Norman Hendrich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Norman Hendrich 2006-06-07 09:46:06 UTC
Hello all,

I have just rewritten my "FillRect" animation demo. It now allows switching between the different graphics primitives and uses a nicer colormap and animation algorighm to actually show some eye-candy. I will backport the changes made by Tom (fitzsim) to make this suitable for the free swing demo later.

Resizing the component now also changes the number of graphics primitives used during the animation. Feedback very welcome.

Unfortunately, the demo runs *much* slower on jamvm+cp than on the reference implementation. Part of this may be due to antialiasing, which is enabled by default in classpath. (Is it possible to compile the demo with current gcj?
This would make a better match for hotspot than jamvm...)
Comment 1 Norman Hendrich 2006-06-07 09:46:45 UTC
Created attachment 11621 [details]
testcase
Comment 2 Robert Schuster 2006-06-07 09:55:47 UTC
You could try running this application on a JIT-capable JVM like cacao. Cacao can be built as easy as JamVM and you can even let the two VMs share the same GNU Classpath installation.
Comment 3 Norman Hendrich 2006-06-07 12:08:18 UTC
> You could try running this application on a JIT-capable JVM like cacao. Cacao
> can be built as easy as JamVM and you can even let the two VMs share the same
> GNU Classpath installation.

OK; just got myself a brand new cacao 0.96 (Note to cacao developers: I had to specify --disable-disassembler to build the thing on my SuSE 8.2. I guess that doesn't break anything.)



Here is some data (x86 Linux SuSE 8.2 with GTK 2.8, Athlon 2600+, 512MB):

<java> GraphicsDemo -size 150   
paintComponent times in msec:
 
         #objects   Cacao   Jamvm   JDK 1.5   gcj -O3
fillRect (22500)      390     350        35         ?
drawRect (22500)     1220    1170        45         ?
fillOval (5625)       700     770         8         ?
drawOval (5625)      1880    1940         9         ?
drawLine (22500)     1300    1250        30         ?
drawArc  (5625)      1750    1840        12         ?


Either the JIT-compiler isn't working correctly, or it has little effect, or jamvm is pretty good (or all of the above). Perhaps the JNI overhead for calling into Cairo is the bottleneck?

Don't misunderstand me; I really like Graphics2D being the default now. But a little extra performance would be even better :-)

Comment 4 Francis Kung 2007-04-11 18:55:42 UTC
More recent data (all my stuff, including jamvm, cacao, gcj, and classpath, are compiled with -O0 though):

         #objects   Cacao   Jamvm   JDK 1.5   gcj
fillRect (9024)      430      650        30   230
drawRect (9024)      480      685        25   280
fillOval (2240)      675      830         4   580
drawOval (2240)     1160     1310         5   1200
drawLine (9024)     1660     1850        30   1700
drawArc  (2240)     1080     1300         3   1200

To be fair, I should recompile all my stuff with -O2 or -O3; I'm sure the performance will be significantly better (though still nowhere near Sun)

With regards to antialiasing, I've found turning it off in classpath results in minimal performance benefits (10-20%), while turning it on with the reference implementation results in a huge performance hit (almost doubles benchmarks).  Visually, classpath-without-antialiasing is comparable to Sun-with-antialiasing though.