Donnerstag, 29. Oktober 2009

What to do with the Cairo rasterizer?

I've the cairo based rasterizer on my disk, and to be honest I don't really know what to do with it.
I'll release it hopefully soon ;)


- A lot faster than pisces, could be speeded up further by some optimizations as well as multithreading.
- Runs Java2Demo perfectly, even gets some things right pisces fails at.
- Better image quality than pisces

- Uses private cairo symbols
- Uses a modified version of cairo (one line commented out).
- Writes into C structures from Java-code
- Currently depends on the XRender pipeline code a bit.

There are some really dirty assumptions in that code that could break from one cairo version to another, but they are there for performance reasons. The more clean you make it, the more performance you loose.

Actually I don't see the modified cairo version as a bit problem itself, because if I wouldn't have used cairo and written a rasterizer from scratch in native code, the code would be there too - and nobody would care about it. The problem however is, cairo's codebase is huge, and nobody wants to integrate a private version of it of course.

Any ideas howto "solve" that dilemma? I doubt the cairo guys would open up their interface, not to the level I am using it.


Ismael Juma hat gesagt…

Hey Clemens,

Have you considered telling the Cairo guys, "I've used internals in this way to get X performance. If I use the public API I get Y performance. Any suggestions on how to achieve X performance with the public API?"


rkennke hat gesagt…

As far as I understand, the basic problem with Cairo and Java2D is that they are both on the same level in the graphics stack, i.e. quite highlevel APIs. This is why you need to use lowerlevel internal code in Cairo. Right? At least, this is why I never attempted Java2D on Cairo. Or Qt. However, I'd love to see it in OpenJDK, so maybe we can get into talks with the Cairo people on how to solve that, as Ismael suggests?

Linuxhippy hat gesagt…

rkennke: Right, Java2D on top of cairo (as the cairo guys suggested) would have its own problems.

I'll simply ask them, and if they refuse, I guess the best idea is probably to fork cairo, compile it as shared library and try to load it at runtime.
With this at least the whole mess would be OpenJDK independent.

Linuxhippy hat gesagt…

Another way would be, to integrated the binding into the cairo-fork and link both statically into a shared library.

This way, the whole forked cairo-code would stay out of OpenJDK's build system - and we could fall back to pisces at runtime, if the shared library could not be found/loaded.