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
