[Lazarus] IDE Editor incredibly slow on newer GTK2
lazarus at mfriebe.de
Sun Mar 25 13:46:09 CEST 2012
please attach your editor options
Also still working on the assumption that it works ok in QT (otherwise
same PC, same IDE.
But bad on GTK
So it must be code that interacts with the WS. Otherwise it had to be
bad for both.
On 25/03/2012 10:58, Bernd wrote:
> I have tried both defines. SynScrollBarWorkaround makes the horizontal
> scrollbar always visible and the effect on CPU usage is the same as if
> I made it intentionally visible.
Expected. reveals the bug I pointed out
> I'm not yet sure about the effect of SynNewScrollBarUpdate, I have not
> yet tried all combinations and I should make exact measurements and
> wite down the numbers.
If you were able to realize the diff between scrollbar visible and
hidden, then (if this was fixing it) you should note that too.
Otherwise it hasn't.
> For practical purposes of making the IDE useful again for me I have
> found that it is enough to simply activate "Caret past EOL" and
> "Scroll past EOF". This will make both scrollbars always visible and
> then the CPU usage and sluggishness will be just below the threshold
> of annoyance.
You can modify the source (or install IDEinspector package and change at
runtime, and set scrollbars to ssBoth instead of default ssAutoBoth.
But its only a work around...
> But it still uses high CPU and it seems it also depends on *where* in
> the file I am editing. For example I have found that (in some of the
> files) holding down the space key in the line just above the
> "implementation" keyword will make the X-server go to 50% and in the
> line just below "implementation" it will be only 10% (I assume this
> has something to do with the highlighter and the amount of text it
> invalidates?). (these numbers are with both scrollbars visible¹)
No I changed nothing else (depends how many revisions you updated. (Well
I changed the syntax of an IF, but it still does the same. / 100% sure
that has no effect at all)
In either case the highlighter should only scan a few lines. And in
either case on win, it invalidated a single line (for repaint). But see
below, for testinc yours
IIRC gtk is slower with TextOut than other frameworks.
Especially because SynEdit enforces the monospace grid.
If SynEdit does find your font is not 100% perfect, then that means
calls to a slower text out.
Define SYNFONTDEBUG and watch the log when the IDE starts
TheFontStock.CalcFontAdvance: ........ eto=True
If true, your font is problematic. Try an other one
(Also happens, if your system can have font sizes of half-pixel. That
may be the case with newer gtk. In that case: change the size.)
BUT in order for that to be an issue, there needs to be a lot of
repainting going on.
So time to go for the defines I originally mentioned:
SynCaretDebug SYNSCROLLDEBUG VerboseSynEditInvalidate
Watch for paint. It gives the rectangle that is painted.
it always paints full width. So left/right will be a big diff.
But it should only point 1 or 2 lines ( a line has between 10 and 20
pixel, depend on font). Watch Top Bottom
There may be a 2nd paint with left/richt all to the right (10 pixel on
the right: that is the overview gutter. Its an embedded panel, so it
does not interfere with the rest of paint)
Also note, that there are frequent, small paints: that is the caret. In
gtk that is also drawn using invalidate. So it shows in the log.
For all else:
run in valgrind. and see where the CPU goes
More information about the Lazarus