RE: remapGlyph caching (was Re: Win32 performance results)


Subject: RE: remapGlyph caching (was Re: Win32 performance results)
From: WJCarpenter (bill-abisource@carpenter.ORG)
Date: Wed Mar 07 2001 - 16:10:14 CST


tomas> This would have an additional great advantage; by chaching the
tomas> text of the run, we could actually draw the whole text by a
tomas> single call to the OS graphical rutines; at the moment we draw
tomas> every single character individually (at least on Unix), which
tomas> is also a performance hindrance.

I don't think it was that, per se, that was keeping us from drawing
strings instead of characters on Unix. After all, that kind of
situation is easily corrected by making a local copy of string into
the "native" format needed by the platform renderer.

tomas> The thing that does worry me a bit, is that our memory
tomas> requirements could easily swell doing this; we would need some
tomas> kind of logic to ensure that only runs currently on the screen
tomas> had the chache.

Better to do it and worry about the memory consumption later. Sounds
like a decent amount of trouble to keep track of when a text run
leaves the display so the cached text can be discarded. (Good job for
another background process similar to spell checking.) After all, I
could be misremembering, but I believe at this point that our text
runs are relatively small and get coalesced at export time. (I think
the infrastructure is there for on the fly coalescing, but is it ever
called?) Compare the size of chunks of text to the size of the C++
objects holding them and duplicating the text all of a sudden doesn't
seem to be the critical path.

-- 
bill@carpenter.ORG (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3



This archive was generated by hypermail 2b25 : Wed Mar 07 2001 - 17:09:02 CST