The caching is going well - it is reasonably straightforward to do,
and seems to be yielding good results. :)
So far, I have an efficient caching *mechanism* - fast, good
distribution, few collisions - and very low dynamic memory allocation
/ fragmentation.
It is already "functional" (with one minor buglet), but as might be
expected, this raises a number of issues/questions:
0) What is cached? Right pretty much anything, subject to a few
controls - max length of glyph fragments, total # of cached elements,
and possibly styles to include/exclude. This last, while allowing for
very selective control, is nasty in that it requires Scintilla client
software (e.g., SciTE) do some extra setup based on the lexer in
use... to test this, I currently [with the OCaml lexer] can just say
to cache elements with styles < 11 to ignore strings and comments.
1) While admittedly, NON-GTK implementations (i.e., Windows) do not
*need* this as much, I saw no reason to stuff this down into the
"platform" layer - so it is implemented in Editor.
2) Currently, because of the issues that prompted the creation of
"2-phase drawing" mode, it is simpler to have caching active in
parallel with "buffered" drawing, but disabled if "2-phase" drawing is
enabled... the 2-phase model *could* be used with caching, but then it
will be uglier for both generating pixmaps for caching AND using those
pixmaps when a cache hit occurs.
3) To allow synchronization at one critical point in cache management,
I would like to add locking as an operation visible in the platform
layer. While this *could* be done just be repackaging / formalizing
the existing platform-specific locking mechanisms in use, it might be
better to have both explicit "internal" (platform layer) locks to be
used by "platform" code, and a second "external" lock on each platform
available to non-platform-specific code (like in Editor).
4) While just caching glyph fragments (I am currently testing with
string lengths of 11 and 19) has done a lot for GTK (and even gives a
perceived gain to the Windows native case), I am still looking for
more... I will look at layout/rendering efficiency issues next.
I suppose I am back to being more than a little concerned with [GTK on
Windows] things like, I don't know, the fact that dropping the time
for width measurement to 0 and just doing rect fills in place of
showing text STILL doesn't even come close to the minuscule time taken
by the Windows native version... :(
I mean, what are these folks *doing* in the depths of the Win32
implementation of all things GTK? It also seems like they are not
using GdiPlus, which from my admittedly limited use of it, is
blazingly fast (vs the raw GDI calls model).
If Neil is still reading this, here is my "minor buglet" - *rarely*,
my cached pixmaps start off fine, but their right-hand portions just
render as all black boxes. It looks like when I copy them back out of
where they were just rendered in pixmapLine, they are occasionally
getting "clipped", as if the rcSegment at that point extends past the
end of pixmapLine... or something equally unfortunate. Hmmm.
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
