Regular readers of this list may recall how I have been looking into
some [for me] ugly performance problems with GTK Scintilla on
Windows... readers with slightly longer memories may also recall that
I recently alleged gross amounts (relatively speaking) of Scintilla
startup time (including initializing styles etc) were going into the
suggested
SCI_TEXTWIDTH(STYLE_LINENUMBER, "_99999")
used to compute a width for the line margin.
As I was studying Scintilla usage of Pango, one of the calls I looked
at was SurfaceImpl::WidthText(), and how it seemed to be getting
called for every line IF the line# margin was being displayed...
Hmmm... an *expensive* call on every line... and I am having
performance problems... ;)
So I turned *off* the line numbers in my app using GTK Scintilla on
Windows and re-ran my test: instead of CPU usage pegged at 100% with
60%-70% kernel time, it is now ~80% with NO kernel time!
So, while this certainly is not the end of performance issues, it does
suggest that a better understanding of precisely *which* things are
disproportionately expensive would be nice...
And my concerns about coming up with a "quick and dirty" way of
estimating the width of the line# margin obviously did not go far
enough. ;) It seems clear (well, to me) that some sort of specialized
hack for getting render widths of numeric strings in the line# font is
both justifiable and necessary - at least for GTK/Pango performance.
Possible approaches: besides using a mono-spaced font for line numbers
(or just not using line numbers), is it the case that the rendered
width of a numeric string in s particular font is just the sum of the
widths of its individual glyphs (plus possible inter-character
spacing), *irrespective* of their ordering?
If so, then at least one approach is obvious: pre-compute a table of
the [digit] char widths for the line# font at startup and whenever the
font characteristics change, and then just sum the char widths to get
the render width for any particular [line] number.
If not, because of kerning (I do not know if this would happen with
the restricted of chars we are talking about here), then this is still
doable - just with a bit more complexity, since the possible kerning
pair values *could* still be pre-computed along with the glyph widths.
As for how much of this is exposed at the level of the Scintilla API,
there could either be an additional variant of the SCI_TEXTWIDTH call,
*or* SCI_TEXTWIDTH could just note that a given invocation is using
STYLE_LINENUMBER, and use the "alternate" implementation.
OTOH, maybe there is a different way to right-justify the numbers in
the line# margin that does not need to do a width call... :)
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
