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
