Neil Hodgson wrote:
Robert Roessler:
This is even faster than before (presumably because I only alloc and
play with GdkPixmaps, not entire Surfaces)! :)
Do you have some numbers?
Well, the same kind I have had all along (they just are nicer now)...
I load up my OCaml app which is displaying several thousand lines of
syntax-colored-by-Scintilla OCaml source in a 640x480 window, and hold
down the PageDown key.
Without the caching, it is not able to keep up, running @ 100% CPU
(50% kernel). WITH caching, I see 55%-60% CPU (40% kernel)... with
things being noticeably snappier, and it can even keep up when I go to
full screen and drag the vertical scroll thumb around (but the CPU
will eventually go to 100%).
While this informal performance evaluation may not sound like much, it
does make the difference between "sluggish" and "snappy"... but it
would be a lot more interesting for someone to build this and run it
on "real" GTK, as this is "GTK on Windows", and I am thinking more and
more that a GTK-only setup would benefit much more, since it would not
have to go through the extra GTK world to Windows conversion ugliness.
I am ready to do cache flushing, but it wasn't entirely clear to me
when to do it based on your previous comment... what is visible in
PlatGTK that could trigger flushing? Is the Font[Cached] release
events what I should use?
I think fonts leaving the cache should trigger a flush.
Easy for you to say - but what does it *mean*? ;)
Is it the Release() calls? The ID changing? Just at the destructor?
I do not have a "big picture" model of even, say, precisely how Font
and FontCached objects relate...
Is whatever event(s) needed for this always visible at the platform level?
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
