Sonntag, 1. November 2009

cairo integration continued...

The cairo guys made clear the functions in use are subject to change anytime, and won't be exported.
I'll create a custom cairo-version as shared library, which will include the JNI-binding code, with a different name.

That will:
- Not change the OpenJDK build process (just add a few pure-java files to it)
- Provide native code that fullfills all the assumptions I need.
- Allow distributors to package it as an extension library, if they wish to enhance performance of OpenJDK.
- Allow us to detect at runtime, wether the native rasterizer is available and fall back to pisces if not.

Unfourtunatly it will also waste a few KB of your disk ;)


Ismael Juma hat gesagt…

Hi Clemens,

For reference the discussion is here:

It seems to me that they are open to improving the public API if they receive concrete examples of why it's beneficial. For example, Chris Wilson said:

"If you have identified inadequacies in the public API or bottlenecks
anywhere within cairo that prevent you from using the library. Please
let us know how we can improve cairo, with profiles if possible!"


Linuxhippy hat gesagt…

The "problem" is, the XRender pipline isn't enterly based on Cairo.
So yes, they would be open to add functionality if the pipeline would be rewritten on top of cairo - but I don't have resources to do that for now, and I am quite confident it would bring other problems to pop up.

Furthermore I would loose the ability to generate X11 protocol directly with Java.

Ismael Juma hat gesagt…

Oh, I see. Fair enough.


rkennke hat gesagt…

You could try to strip down the parts of cairo that you need, and include them in your backend. I suppose, you only need <10% (maybe significantly less) of cairo code, maybe only a few source files. Might be worth trying.