[OpenJDK 2D-Dev] Why does the OpenGL pipeline not use setupBlitVector?

Clemens Eisserer linuxhippy at gmail.com
Mon Jun 2 20:36:46 UTC 2008

Hi Phil, Dmitri and Chris,

Thank you very much for the detailed explanations, it made things much
clearer for me.

>The setupBlitVector() method does a bunch of JNI field fetches
> from the native level, mallocs a GlyphBlitVector structure each time, fills
>it by doing a JNI Get/ReleasePrimitiveArrayCritical, etc.
I assume the Direct3D pipeline does basically the same as the OpenGL pipeline.
What would you think about something like
setupBlitVectorWithArguments(.,.,.,.,.), so code would not duplicated.
I thought the same about utility-functions like RETURN_IF_NULL,
wouldn't that be useful for everybody working with JNI, or at least on
the native side?

> The GlyphInfo holds the image and data about a particular glyph
> It is a long-lived (until memory is needed) cache, and its contents
> do not change. It doesn't have an absolute "x/y" rendering position.
> It does have relative positioning information: ie where the image
> should be placed relative to the glyph origin.
> XRender probably has somewhere for this information
> too, but perhaps more importantly, you also need a way in the
> rendering call to optionally tell it where precisely each glyph should be
> displayed relative to the prevous one since otherwise you will
> find it hard to use a cache in such cases. If XRender requires
> that information to be in the glyph cache, then its not very
> useful for such cases.
Ah great, thats basically the same as XRender does.

XRender stores the image data along with relative positioning
information into the server-side glyph-set, and when rendering it
optionally allows to specify the positioning information though the
XGlyphElt?? structure.
I hope that will fit nicely together.

> It makes sense to do the same as OGL, if you can. Note that the
> GlyphInfo struct has a field "struct _CacheCellInfo *cellInfo" which
> is used by OGL/D3D so that if the glyph is freed, it knows to tell the
> OGL/D3D and in Clemen's case, XRender cache to free it too.
> As Chris says, see AccelGlyphCache.c.
Yes, I already had a look at that Code because it was used a lot in
the OpenGL pipeline.
It seems to fit quite good, with the excepetion that X/Y information
would not be needed because XRender does the cache-handling itself and
uses linear IDs. But I guess the overhead should be quite small.

> In 6u10 the AccelGlyph has been improved to support multiple caches
> per glyph
Good to know, thanks :)

Currently I've implemented lines the same way as Cairo does
(generating three trapezoids), which gives the same result as with
XDrawLine when line_width is set to 1.0, it looks to some degree ugly
I created some screenshots: http://picasaweb.google.com/linuxhippy/Cairo

The problem is that I don't see any way to do nice lines with XRender,
without a lot of overhead and many trapezoids.
Carl Worth was very helful, pointing me to a solution:
However that means stroking with a pen -> complex stuff probably
generating many more than "just" 3 Trapezoids.

Does Java2D specify how a line has to look?
A possible workarround would be falling back to XDrawLine, but that
would complicate the state-management quite a bit.

3.) I have an awkward problem:

In sun/font/X11TextRenderer there is a trampoline-function into
another shared-libary.
To play a bit with text I changed it a bit and it looks like this:
JNIEXPORT void JNICALL Java_sun_font_X11TextRenderer_doDrawGlyphList
    (JNIEnv *env, jobject xtr,
     jlong dstData, jint totalGlyphs, jboolean usePositions,
                    jboolean subPixPos, jboolean rgbOrder, jint lcdContrast,
                    jfloat glyphListOrigX, jfloat glyphListOrigY,
                    jlongArray images, jfloatArray positions)
                    jlongArray imgArray, jfloatArray posArray)
  AWTXRDrawGlyphList(env, xtr, dstData, totalGlyphs, usePositions,
                     subPixPos, rgbOrder, lcdContrast, glyphListOrigX,
                     glyphListOrigY, images, positions);

and it calls the method in X11TextRenderer_md:
    (JNIEnv *env, jobject self,
     jlong dstData, jint numGlyphs, jboolean usePositions,
                    jboolean subPixPos, jboolean rgbOrder, jint lcdContrast,
                    jfloat glyphListOrigX, jfloat glyphListOrigY,
                    jlongArray imgArray, jfloatArray posArray)
    jlong *images;
    images = (jlong *) (*env)->GetPrimitiveArrayCritical(env, imgArray, NULL);

The strange thing is that the GetPrimitiveArrayCritical call crashes,
but if I copy exactly the same call into the trampoline-function,
everything works fine:
V  [libjvm.so+0x24252b]
C  [libmawt.so+0x1fc6c]  AWTXRDrawGlyphList+0x8c
C  [libfontmanager.so+0xb294]
j  sun.font.X11TextRenderer.doDrawGlyphList(JIZZZIFF[J[F)V+0

I am not a JNI nor a C profesional, any idea what I am doing wrong?
Am I passing the JNI-Envirment-pointer somehow wrong, or the
array-handles, or is it related to the fact that both methods are
located in different shared libraries? If I copy the second method
from X11TextRenderer_md directly into X11TextRenderer (doing nothing
except the GetPrimitiveArrayCritical) everything works as expected.
Sorry for this question ;)

Thanks a lot, lg Clemens

More information about the 2d-dev mailing list