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

Gustavo J. A. M. Carneiro gjc at inescporto.pt
Mon Oct 11 05:38:46 PDT 2004


Sex, 2004-10-08 às 09:36 -0700, Keith Packard escreveu:
> Around 22 o'clock on Oct 7, graydon hoare wrote:
> 
> > 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.
> 
> Yeah; the #define has the added benefit of segfaulting if you accidentally 
> use it.
> 
> > ok. in practical terms, does this mean "remove the FIXME comment" or 
> > "remove the max_y_advance metric" or ... ?
> 
> I think we just need to document it.
> 
> > 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.
> 
> heh. You're thinking *way* beyond me at this point.  I just wanted to do 
> the LCD optimization so that the existing pixel-aligned text looks good.
> This doesn't change how the cache works, it only affects how the glyphs 
> are actually rasterized (and quadruples the amount of memory they require).
> 
> However, once we do that, we can actually *shift* the text by 1/3 a pixel 
> to hit the sub-pixel grid and the glyphs will still look sharp while 
> providing 3x the horizontal resolution.  I think this will make it 
> possible to set text on the screen closer to printer metrics.  I view this
> as a future project as it will triple memory requirements again (after the 
> 4x expansion for sub-pixel text).

  Wow, so much memory increase... any chance this memory (glyph cache)
can be shared between all applications, somehow?  That is, if it doesn't
incur much performance hit due to semaphores, or anything like that...
 
  It would be nice to have a shared cache architecture, with a shared
memory segment, and with data in a structure such that you don't need
any kind of locking for reading, just for locking, and applications
would keep a temporary cache of local glyphs, and they periodically push
their private cache in chunks to the global one.  And maybe this could
be a generic caching system, not just for cairo glyphs, but for
anything... =)

  I could be dreaming though; maybe it's just not technically
possible :-P

> 
> -keith
> 
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo
-- 
Gustavo J. A. M. Carneiro
<gjc at inescporto.pt> <gustavo at users.sourceforge.net>
The universe is always one step beyond logic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3086 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20041011/09357d9e/smime.bin


More information about the cairo mailing list