Neil Hodgson wrote:
Robert Roessler:
Other than that, any comments? Given how simple the code looks, is it
something you could see going into Scintilla? If not now, then
shortly after 1.68 goes out? Or do you feel that the GTK performance
issues will be addressed some day, and you do not want "band-aid" code
in Scintilla?
I don't like the extra complexity and may want it moved down into
the platform layer so is not seen for platforms that don't need it.
Maybe even #ifdefed out by default. The increase in memory or graphics
resource usage may not be viable for all. Unfortunately, I don't have
a lot of time currently for thinking about Scintilla.
All right - presto! The caching is moved down into PlatGTK.cxx (only).
While I sort of liked "normalizing" the mutex naming in PlatGTK, it
isn't strictly necessary... so like with Editor.cxx, there is only the
class def near the front, and a single use in DrawTextNoClip in
SurfaceImpl.
Logically, things are largely the same - caching only operates in
"buffered" mode. This is detected by the Surface having a pixmap AND
by only caching in this call - 2-phase uses the DrawTextTransparent
call. However, since style data is no longer available, we just
"guess" as to whether we should cache based on the first char NOT
being numeric (as well as length, of course).
This is even faster than before (presumably because I only alloc and
play with GdkPixmaps, not entire Surfaces)! :)
Posted in
http://www.rftp.com/PlatGTK.cxx
with the new stuff being controlled by "TEXT_RENDER_CACHE" ifdef.
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?
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
