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
