Samstag, 12. September 2009

Ductus vs Cairo vs Pisces

Today I got the AATileGenerator based on cairo into a useable state. This way software-rendering is done by cairo instead of the pisces rasterizer.

The relative results are quite pleasing:

On the positive side, most benchmarks improved by a factor of 2-3x :).
However cairo is no cure-all. The ductus rasterizer used in Sun's proprietary builds is still the winner in all tests.

Most likely this is the result of cairo beeing a two-step design:
First a path is tesselated into trapezoids, and later those trapezoids are rasterized, whereas ductus rasterizes directly.
However a positive side-effect of this design is trapezoid rasterization can be parallelized, so on dual-core systems it should be possible to get close to ductus.

Dienstag, 8. September 2009

Running Java2Demo on cairo's tesselator

I've just sorted out the worst problems, and its possible to run Java2Demo using the Cairo based rasterizer now. The hardest part was a small bug in cairo, which was caused by the uncommon situation how cairo is used.

Performance is excellent compared to pisces, and quite good compared to ductus.
By implementing more specific functionality (not only draw/fill) it should be possible to get even better performance for common cases like arcs or ovals.


A drawback is that this rasterizer backend needs a private version of cairo, because its tapping a lot into cairo internals. Hopefully this will find its way into IcedTea some day...

Freitag, 4. September 2009

Using cairo for antialiasing

I've written some glue code to use Cairo's tesselator to generate trapezoids for antialiased rendering, which can be directly fed to the X-Server. With a little more work, pixman could be used to generate AA tiles which could also be fed to the software loops (e.g. BufferedImage rendering) - replacing the slow pisces rasterizer currently used by OpenJDK.

For now I've only implemented the (simple) fill operation, stroking/drawing is still missing - however the results look already quite fine:

Boring background:
Currently both OpenJDK as well as Sun's proprietary JDK builds implement antialiased rendering by computing coverage values using C/Java code on the CPU, uploading those coverage values to the GPU and finally do blending on the GPU.

D3D/OpenGL drivers are usually highly optimized, so this works quite well there. For XRender however, especially with the Intel drivers (*cought*), this results in quite low performance, because every operation involves a syscall + a full GPU flush.
Furthermore when using OpenJDK, the rasterizer generating those coverage values is horribly slow, so AA rendering to any surface suffers.