[cairo] [patch] caching, glyph, font, and glyphset patch, round 2
keithp at keithp.com
Fri Oct 8 09:43:23 PDT 2004
Around 22 o'clock on Oct 7, graydon hoare wrote:
> yeah, I started into doing so and realized I could think of too many
> ways which might work:
> - send all the 8-bit substrings in one message, then any 16-bit
> substrings, then any 32-bit ones.
The trick here is that glyph indices are per-glyphset, so a glyphset with
thousands of glyphs will have relatively few 8-bit glyphs indices.
Grouping commonly used glyphs together in one glyphset means that you need
to switch glyphsets more often, but that sequences of glyphs from that
glyphset can use 8-bit encodings.
For now, I suggest just tracking the max glyph index you've got in the
cache; that will almost always fit in 16 bits, so you can use a static
check before drawing to select between 16 and 32 bit indices. Or, just
ignore it and ship all 32 bits until we figure out a better plan.
> necessitate? hm. I am not sure I see why. isn't it all 32-bit indices on
> both the client and server end? I thought we were just looking at the
> transmission format.
Necessitate meaning that using a single glyphset will pretty much
eliminate the ability to use 8 bit encodings as most strings will contain
16-bit glyph indices.
Doing a glyphset on a font boundary will provide lots of opportunity for
the 8-bit case in western locales where most of the time applications use
fewer than 256 glyphs from each font.
Again, all of this is just mostly to keep our eyes open for possible
improvements in the wire encoding. But, we should avoid
micro-optimziations at this point until we've demonstrated performance
issues in real situations where I expect some compression to be performed
on top of this encoding in any case.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20041008/983684e2/attachment.pgp
More information about the cairo