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

Phil Race Phil.Race at Sun.COM
Fri May 30 21:21:16 UTC 2008

Chris Campbell wrote:
> Hi Clemens,
> On May 30, 2008, at 1:13 AM, Clemens Eisserer wrote:
>> Hi,
>> I've had a look at the doDrawGlyphList implementations of both the X11
>> and the OpenGL pipeline, however I have (as always) some questions:
>> - Why does the OpenGL pipeline not use setupBlitVector, but instead
>> does the work itself?
> It's been a while since I wrote that code, but I think the primary 
> reason was so that it plays better with single-threaded rendering (STR) 
> and the relatively lightweight process of throwing things on the 
> RenderQueue.  As you know, one of the benefits from STR is that it 
> avoids lots of JNI overhead.  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.
> This is all mostly necessary work for the software or X11 pipelines, but 
> with STR, we realized that we already have a structure (the RenderQueue) 
> that could be used to hold the glyph list information during the 
> rendering process.  Even better, all that information is available at 
> the Java level, so we can easily stuff the GlyphInfos on the RenderQueue 
> without dipping down into JNI (see BufferedTextPipe.enqueueGlyphList() 
> method), and then when the queue is flushed (rendered), we can do the 
> last little bit of massaging "inline" at the native level (see 
> OGLTR_DrawGlyphList()).  No need for setupBlitVector(), and overall it's 
> quite an efficient process.
>> - Are the values in GlyphInfo always the same, if the glyph does not
>> change (x/y/width/height)?

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.

> Phil will correct me if I'm wrong... When a String or GlyphVector or 
> whatever is rendered, each time a new set of GlyphInfo "instances" are 
> generated depending on the position of the text (i.e. the GlyphList) on 
> the screen, etc.  So once a GlyphList and its associated GlyphInfos has 
> been created, those fields won't change, but of course it's a temporary 
> structure, only valid for that one time that the GlyphList is rendered.

Chris is actually describing the "ImageRef" struct which is a temporary
structure used during blitting which holds the actual positions
at which a glyph in a particular rendering call (ie drawString
call) will appear on the surface. An array of these is the
main constituent of the GlyphBlitVector.

>> I ask, because XRender does store quite the same information on the
>> server when caching the glyphs, and if these values would stay the
>> same, I could avoid sending e.g. the position-fionrormation for every
>> glyph drawn.

Yes, I think you would want to use XRender's server side GlyphSet,
otherwise I don't see how you can really use XRender for text.
Should work, so long as it uses the same concepts as the JDK, which
I expect it does. Basically that is the dimensions of the image,
and where to position it relative to the glyph origin, and the
image data itself. It also holds the "default advance", ie where the
next glyph should be positioned, in the absence of opentype text
layout for example. 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.

> I'm not sure at which level you (or rather XRender) are caching the 
> glyphs.  You can certainly cache the glyph images, as we do for OGL/D3D 
> (see AccelGlyphCache.c), but I don't see how you could (or would want 
> to) cache position information, etc.

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.
This presumes that XRender and OpenGL aren't both in use at
the same time, which I expect will be true, otherwise they'd
be fighting over that field.

> Anyway, Phil's much more knowledgable with this stuff, so I'll stop 
> talking now :)
> Thanks,
> Chris
>> Or could it happen that the same glyphs are rendered with different
>> offset or width (e.g. "stretched" text)?
>> Thanks, Clemens

More information about the 2d-dev mailing list