- First Post
- Replies
- Stats
-
Go to
- ----- 2024 -----
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
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
At 07:03 PM 2/10/00 -0800, Kirill 'Big K' Katsnelson wrote:
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.
Yes, Jan has already pointed out that this code needs optimising.
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.
Ok understand.
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.
Well the problem is that its original purpose was subverted by me for
subwindow support. Lets not duplicate work, I am actively hacking on this
stuff at the moment - much of the motivation behind the layout support I've
been hacking on is so that redisplay only displays widgets when it really
has to, and even then only the bits that have changed.
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,
I wrote all this stuff. It is a mess, but necessary in order to make sure
redisplay doesn't re-output glyphs when it doesn't have to (causes lots of
nasty flashing with subwindows). Before there was a dirty flags, redisplay
used to assume a glyph had never changed or always changed, this doesn't
take into account more subtle changes like the glyph / image_instance
itself staying the same but some property changing (for instance the amount
a progress gauge is progressed). Now that widgets are updated more truly in
the spirit of redisplay it should be possible to clean this up somewhat.
as dirty flags are never reset for lisp-created glyphs, except -
a proposito - for widget glyphs.
Well widget glyphs are the ones that matter...
andy
BTW I have a feeling this started life as a private email.
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
9046
days inactive
9046
days old
1 comments
2 participants
tags (0)
participants (2)
-
Andy Piper -
Kirill 'Big K' Katsnelson