[Lazarus] IDE Editor incredibly slow on newer GTK2

[Martin]

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   
SynCheckPaintLock

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