[cairo] [patch] caching, glyph, font, and glyphset patch, round 2
graydon at redhat.com
Thu Oct 7 19:56:19 PDT 2004
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.
> 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
More information about the cairo