[Lazarus] IDE Editor incredibly slow on newer GTK2

[Martin]

On 31/03/2012 12:26, Bernd wrote:
> I cannot reproduce the extreme slowness anymore, no matter what I do.
I fixed an issue, that affected the editor, but on all widgetset.  
However it did not match you description (dependency on windows size).

It only happened if you had a lot of tabs open. then if you hold down a 
key (e.g. move right) it would stutter every 0.5 seconds. It was caused 
by an idle handler.
It was introduced when the "window" menu was re-ordered, and fixed 
yesterday.

Well the idle would have run after every keystrokes ....
And the menu was introduced on 23rd. One day before your report...

Maybe changing menu structure is extremely slow under your gtk?

- How many tabs do you usually have open? (5, 10 , 20 , more)
- How bad is the lag, if you now open the windows menu.

> What I have now is only generally relatively high CPU usage compared
> to Qt and some stuttering when scrolling, but the extreme lag and
> sluggishness when simply typing text is gone. I don't know what caused
> it and I don't know what made it go away (I did *not* restart X, it
> just went away from one moment to the other (and no there were no
> other processes running also)).

scrolling, you can again look how much needs to be painted.

In most cases it should just be the line(s) that scrolled in.

But if the caret touches a begin/end and the other word is highlighted 
then that causes the entire text between the 2 words to be repainted. => 
that could cause a stutter, depending on how slow painting is on your 
system.

>
> 2012/3/25 Martin<lazarus at mfriebe.de>:
>> please attach your editor options
> see attachment
Will look at later

>> Define SYNFONTDEBUG and watch the log when the IDE starts
>>   TheFontStock.CalcFontAdvance: ........ eto=True
> No messages with "eto" at all.
good

>> 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)
> The following is when I grep for PAINT and press a key three times.
> There will only be one paint per key press which seems ok to me
> (actually there are a few more paints every now and then when  the
> cursor blinks but also only one for cursor on and one for cursor off)
>
> PAINT SynEdit1:TIDESynEditor sfHasScrolled=False rect=l=0,t=374,r=689,b=408
> PAINT SynEdit1:TIDESynEditor sfHasScrolled=False rect=l=0,t=374,r=689,b=408
> PAINT SynEdit1:TIDESynEditor sfHasScrolled=False rect=l=0,t=374,r=689,b=408

34 pixel hight. May be normal. looks like 2 lines (the log showed caret 
= 15 pixel heigh + spacing). But that is normal (the highlighter add' 
the extra line...)
Certainly it isn't the full client area

> and here is some more output unfiltered for one keypress, surounded by
> a bit of focus change and cursor blinking:
Looks normal