Java2d Benchmarking results

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Francis,

> I've run the java2d benchmarker in a few configurations, with the
> results as follows.

Interesting results. I noticed earlier (and the benchmark confirms it)
that drawing lines is overly expensive with our impl. I suspect that Sun
optimizes the standard case (no custom stroke/paint/composite set) for
drawing lines, because that's used often in Swing. Cairo always performs
stroking for lines, regardless of the stroke setting, which makes
drawing lines (and drawing shapes in general) quite expensive.
Unfortunately I don't know how to optmize this properly, except maybe in
Cairo itself. We could check if stroke/composite/paint/AA has been set
and fall back to drawing lines by GDK or X for the simplest case on X
surfaces, but that doesn't sound very 'nice' to me. 

One conclusion we can draw from that is that we should add benchmarks
for compositing, custom painting (gradients/textures) and custom
stroking and compare that too. Drawing different kinds of images and
drawing fonts would also be interesting, as is applying custom
transformations to all that :-)

>   Natively compiling the code doesn't yield much of
> an improvement over jamVM.  Some interesting results.

Yeah sure, most of the work is done in native code, so it doesn't really
matter if the VM is an interpreter, completely compiled or jit.


-- 
?Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.? - William Blake
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://developer.classpath.org/pipermail/classpath/attachments/20060621/ac4ac7b5/attachment-0001.pgp

[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux