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

[Clemens Eisserer]

Hi Phil, Dmitri and Chris,

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

1.)
>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 :)

2.)
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:
http://cm.bell-labs.com/who/hobby/87_2-04.pdf
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:
JNIEXPORT void AWTXRDrawGlyphList
    (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]
Java_sun_font_X11TextRenderer_doDrawGlyphList+0x74
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