[cairo] [patch] caching, glyph, font, and glyphset patch, round 2

[graydon hoare]

Keith Packard wrote:
> Around 0 o'clock on Oct 7, graydon hoare wrote:
> 
> + * This table is open-addressed with double hashing. the secondary hash
> + * function is rounded up to an odd number and the table is a power of two
> + * in size. These assumptions ensure that the table is fully searched; if
> + * you want to experiment with different hash functions, there is
> + * conditional machinery in place for measuring performance.
> 
> I believe this comment is incorrect now, right?

correct. will fix.

> <micro-optimization>
> I might also use a (semi-)kludge to avoid a memory reference:
> 
> 	#define DEAD_ENTRY	((cario_cache_entry_base_t *) 1)

I wondered about this when I saw it in glyph.c, but I decided I'd prefer 
to see "dead_entry" if I looked in gdb. of course, "0x1" is pretty 
obvious too. I don't really care. I'll set it to the #define if you like.

> These seem like a good opportunities to use calloc which needn't call memset 
> for newly mmap'ed pages.

oh? huh, I did not know that. learn something every day.

> The application must request vertical layout somehow.  I suggest that 
> perhaps cairo not worry about this and leave that kind of complexity to
> an upper level library like Qt or Pango.

ok. in practical terms, does this mean "remove the FIXME comment" or 
"remove the max_y_advance metric" or ... ?

> It seems like we should be able to add sub-pixel glyph rendering at this 
> point.  Is that true?

hrm. I'm not sure. istr owen (?) said that there's not often much 
benefit to it because the hints usually do grid snapping anyways. I 
don't really have any opinion on the matter. it's doable, for sure; it 
seems like all we'd need to do is key the glyph cache by a full 2x3 
affine matrix rather than just a 2x2 one.

> I'm wondering if there's a way to use 8 or 16 bit values for glyphs; for 
> some applications, quadrupling the size of glyph information will 
> measurably impact network utilization.   Perhaps we just don't care, 
> expecting that gzip will be able to compress this down in most cases.

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.

  - start building an 8-bit one and if we overflow copy them all out
    into a 16-bit one, etc.

  - do two passes, one to work out the maximum width needed and one
    to compose the transmission form.

when faced with such a paralyzing array of choices I decided to just get 
it working and let someone else micro-tune it. I'm not sure there's a 
single strategy which would be optimal for all clients.

> To do so would necessitate the use of multiple glyphsets.  Is this 
> possible?  Can we retro fit this later?

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.

-graydon