Some time ago, Andy Piper wrote...
At 02:28 PM 2/8/00 -0800, you wrote:
>Cached are only "border glyphs", such as continuation-glyph etc.
>Lisp-defined glyphs are not put in no caches.
Let's pursure this a-while. You may turn out to be right - but not without
a fight :)
redisplay_output.c:compare_runes calls get_glyph_cachel_index which as a
side-effect adds to the cache glyphs not there already.
In real life this code is not reached unless glyphs changed, see
redisplay-output.c:(compare_runes)
else if (crb->type == RUNE_DGLYPH &&
XFRAME (w->frame)->glyphs_changed)
Note that this code is called on every redisplay, much much
more often than glyphs really change, and the glyph cache is
reset every so often.
That way, the cache *almost* always contains only the internal
border glyphs. I walked this code with the debugger all the
way along and across, but have never seen a cachel for a lisp-
begot glyph in there.
When a glyph is to be output (see redisplay.c(add_glyph_rune)),
the cachel parameter, the last one, may be used or passed NULL.
For border glyphs, it is a real cachel. For lisp created
extent glyphs, it is always NULL.
It seesm to me that the glyph cache fundamentally does not work
(or if it does the way it should then I fundamentally
misunderstand the logic behind it). I am going to look into it
soon.
Anybody can remember, what was the initial concept of the dirty
flag of a glyph and of an image instance? This is a mess currently,
as dirty flags are never reset for lisp-created glyphs, except -
a proposito - for widget glyphs.
Big K