[cairo] Cairo vs. Xft glyph rendering

[Vladimir Vukicevic]

Xan Lopez wrote:
> The GTK+ 2.6 call, coming from libXft, looks pretty much ok to my
> untrained eyes. You can even recognize the glyph codes from each
> character in the timetext[2] program. The GTK+ 2.10 call looks like an
> abuse of the API :)
 >
> If you compare the code from xftrender.c:XftGlyphSpecRender() and
> cairo-xlib-surface.c:_cairo_xlib_surface_show_glyph8() it seems that
> this the intended behaviour and not a bug. My question is: is this ok?
> what is the reason of the divergence?

The main reason is that for XftGlyphSpecRender only a destination origin 
point and an array of glyph indicies is given.  For cairo's show_glyphs, 
each glyph has its own x/y coordinate.  So, one element in the call to 
Render per glyph is used.  Cairo could probably generate better runs by 
comparing the x/y delta from the previous glyph with the cached glyph 
offsets, but that data currently isn't available in the functions used 
and would require a hash lookup per glyph.

Maybe one of the X folks here could let us know whether doing this could 
result in a performance gain?  We already have to do the lookup per 
glyph to make sure that it's sent to the server, so we could always 
change the data structure that's used to pass things down to 
xlib_show_glyphs{8,16,32} so that it sends the right info, instead of 
just sending down the cairo_glyph_t array.  That is, either pass down 
cairo_glyph_t + per-glyph offsets, or even do the run computation ahead 
of time and pass down some structure that can be trivially converted to 
the appropriate size XGlyphElt array.

Now that I think about it, the right thing is probably to always create 
an XGlyphElt32 array in xlib_surface_show_glyphs, because we have all 
the data needed to do so.  Then for the 8-bit and 16-bit case, we'd just 
do a conversion from xGlyphElt32 to XGlyphElt8/16 to cut down on the 
data size (and could probably do all this in xlib_surface_show_glyphs, 
instead of going through a function call to show_glyphs8/16/32).

     - Vlad