I recently updated my ancient Ubuntu Hardy to Oneiric which has GTK-2.24.6. Now I noticed that the SynEdit in the Lazarus IDE feels painfully sluggish. If I press a key there is a 0.2 seconds delay until it updates the screen. If I keep the key pressed (auto-repeat) then xorg will burn 60% and kernel (IO or something) the remaining 40% of my CPU. It gets worse the bigger the editor window is (maximize window for maximum pain).

Although one could argue that a Pentium-M (1 ) is not the fastest CPU I am not yet willing to throw away my good old thinkpad T40 which has served me so well for such a long time.

It does not happen if I use the Qt widgetset (but I rather do not want to use Qt but if this can't be fixed then I will have to, otherwise it is completely unusable, currently it feels like I'm sitting in front a 66MHz 386 from 1990).

I can NOT reproduce it if I create a minimal application with a synedit and Pascal highlighter on it. I'm unable to reproduce this, no matter what options I set in my synedit or what highlighter I use and on the other hand I cannot find any editor option in the IDE to disable to make it run as fast as the synedit in my own application. I also went back a few thousand SVN Revisions until I could not compile with fpc2.6 anymore but could not find any revision that wont have (or trigger) this bug.

The IDE seems to do something with the synedit that (judging from the massive xorg and kernel usage and the dependency on the window size) must have something to do with the rendering of the control. And it also seems to do this only in certain GTK2 versions and not in Qt. What could it be? Where should I start looking for the cause of this?

Bernd

PS: I have no problems with any other GTK2 Application, no problems with slow rendering. Accelerated rendering/compositing is working, Firefox, Flash-Videos, OpenGL-Applications, everything working exactly as good (and some things even better) as in my old Hardy install. Only the Lazarus source editor has become slower by a factor of next part -------------- A non-text attachment was scrubbed...
Name: 0x3945A21D.asc
Type: application/pgp-keys
Size: 16637 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120324/668f938f/attachment.bin>

Interesting.

This is without scrolling?

I would reckon that there is unnecessary painting going on (at least it's a possibility). Any none painting code should be the same for QT, so ...

Compile the SynEdit package with the following defines SynDebug
SynCaretDebug
SYNSCROLLDEBUG
VerboseSynEditInvalidate
SynCheckPaintLock

and get a logfile.

Please also try if switching the overview gutter (right hand site) (Options/Editor/Display) makes a different. IIRC some WS does unnecessary invalidates (but not as bad as you described)

Or switch off highlight of all occurrences of the word under caret (obviously that can lead to a full invalidate, but usually it has a time delay, so it does not affect editing)

2012/3/24 Martin :

I will try these defines and make the log (tomorrow). The right overview gutter (and also the left gutter) does not have any notable effect.

Meanwhile I have made another interesting discovery: It only happens when there is *no* horizontal scrollbar. As soon as the horizontal scroller appears the CPU usage of the X server immediately drops from 60% to 20%, total CPU usage well below 100% and the caret is moving smoothly again and no notable delay. This is why I noticed it only today and not 2 weeks ago: I started a new project today and the unit where I spent most of my time today does not have long enough lines yet to have a horizontal scrollbar.

Weird.

How about, if there is a horizontal scrollbar, but not a vertical?

Ok, forget those defines. (WEll we maybe later...)

Try what happens with
SynScrollBarWorkaround
defined

2012/3/24 Martin :

Weird. How about, if there is a horizontal scrollbar, but not a vertical?

I can now reproduce it with a synedit in my own application. It seems it needs both scrollbars.

none or only one scrollbar: sluggish, high CPU
both scrollbars: smooth.

It also seems to have something to do with eoScrollPastEOL, my synedit test-app became slow after I set this to False. (This also makes scrollbars disappear in small documents when ssAutoBoth but it almost seems to me this setting also has an additional effect on the CPU usage even if scrollbars are already present)

It may make both scrollbars permamently on.

There is an old bug in the gtk code, that will show a scrollbar, even if not requested.

That happens in SynEdit. SynEdit works around by hidding it again, before any painting is done. But it is possible that this still adds some extra work somewhere...

------------------------
Actually, with the new mouse wheel handling, it may be possible to change the workaround, and skip the call that set it to visible in first....

Only, this may have some risk...

If I am guessing right, then it is a result of
http://bugs.freepascal.org/view.php?id=16458

I added a workaround. Define: SynNewScrollBarUpdate

BUT: This works in the IDE. It breaks standard SynEdit. If Scrollbars are set to SSNone (or either one is forcefully hidden), then it is still possible to scroll (including by wheel) With the workaround that breaks. (Unless you configure the SynEdit with "MouseActions"

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.

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.

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.

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?)

It might also be a bug in GTK2, I have googled "GTK2 xorg high CPU" and it seems there are some rare (and unclear) circumstances where GTK can somehow provoke xorg into hogging the CPU but I have no idea whether this might be related.

Bernd

___________
?) Did you change something else besides implementing this new define or is this a Heisenbug that will become less clear the closer you get? Since this morning's svn up (after trying the defines and after removing them again) I have the impression that total CPU usage today will always stay just a little bit below the 100% (around 90%) and yesterday's extreme sluggishness hasn't yet returned.

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.

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.

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...

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

I cannot reproduce the extreme slowness anymore, no matter what I do. 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)).

2012/3/25 Martin :

please attach your editor options

see attachment

Define SYNFONTDEBUG and watch the log when the IDE starts ?TheFontStock.CalcFontAdvance: ........ eto=True

No messages with "eto" at all.

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.)

Envy Code R, size 10. This is the font size this font was optimized for, most other sizes would look ugly anyways, (at least the smaller ones). Changing the font and also the antialiasing settings was the first thing I tried when the problem appeared but it did not make any difference at all.

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

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

SynEditCaret CreateCaret for HandleOwner=SynEdit1:TIDESynEditor DebugShowCount=0 Width=2 pref-width=2 Height=15 FCurrentCreated=False FCurrentVisible=False
SynEditCaret SetPos for HandleOwner=SynEdit1:TIDESynEditor x=119 y=375 SynEditCaret ShowCaret for HandleOwner=SynEdit1:TIDESynEditor FDebugShowCount=0 SynEditCaret DestroyCaret for HandleOwner=SynEdit1:TIDESynEditor DebugShowCount=1
SynEditCaret CreateCaret for HandleOwner=SynEdit1:TIDESynEditor DebugShowCount=1 Width=2 pref-width=2 Height=15 FCurrentCreated=False FCurrentVisible=False
SynEditCaret SetPos for HandleOwner=SynEdit1:TIDESynEditor x=119 y=375 SynEditCaret ShowCaret for HandleOwner=SynEdit1:TIDESynEditor FDebugShowCount=0 PAINT SynEdit1:TIDESynEditor sfHasScrolled=False rect=l=119,t=374,r=121,b=389 SynEditCaret HideCaret for HandleOwner=SynEdit1:TIDESynEditor FDebugShowCount=1 SynEditCaret ShowCaret for HandleOwner=SynEdit1:TIDESynEditor FDebugShowCount=0 TCustomSynEdit.InvalidateTextLines SynEdit1:TIDESynEditor FirstLine=27 LastLine=28
TCustomSynEdit.InvalidateTextLines TLazSynTextArea FirstLine=26 LastLine=27 rect=l=55,t=374,r=676,b=408
TCustomSynEdit.InvalidateTextLines TLazSynTextArea FirstLine=26 LastLine=27 rect=l=55,t=0,r=676,b=0
TCustomSynEdit.InvalidateTextLines SynEdit1:TIDESynEditor TCustomSynEdit.InvalidateGutterLines SynEdit1:TIDESynEditor FirstLine=27 LastLine=28
TCustomSynEdit.InvalidateGutterLines TLazSynGutterArea FirstLine=26 LastLine=27 rect=l=0,t=374,r=55,b=408
TCustomSynEdit.InvalidateGutterLines TLazSynGutterArea FirstLine=26 LastLine=27 rect=l=676,t=374,r=689,b=408
TCustomSynEdit.InvalidateGutterLines TSourceLazSynSurfaceGutter FirstLine=26 LastLine=27 rect=l=0,t=0,r=55,b=0
TCustomSynEdit.InvalidateGutterLines TSourceLazSynSurfaceGutter FirstLine=26 LastLine=27 rect=l=676,t=0,r=689,b=0
TCustomSynEdit.InvalidateGutterLines SynEdit1:TIDESynEditor SynEditCaret SetPos for HandleOwner=SynEdit1:TIDESynEditor x=126 y=375 PAINT SynEdit1:TIDESynEditor sfHasScrolled=False rect=l=0,t=374,r=689,b=408 SynEditCaret HideCaret for HandleOwner=SynEdit1:TIDESynEditor FDebugShowCount=1 SynEditCaret ShowCaret for HandleOwner=SynEdit1:TIDESynEditor FDebugShowCount=0 SynEditCaret HideCaret for HandleOwner=SynEdit1:TIDESynEditor FDebugShowCount=1 SynEditCaret DestroyCaret for HandleOwner=SynEdit1:TIDESynEditor DebugShowCount=0
PAINT SynEdit1:TIDESynEditor sfHasScrolled=False rect=l=126,t=374,r=128,b=389

For all else: run in valgrind. and see where the CPU goes

Maybe a sampling profiler like oprofile would be a better idea because most of the CPU actually goes to the X server process and also valgrind is painfully slow, next to unusable on my old hardware, I suspect I would have to wait an hour until I see the first IDE window appearing.

I suspect a GTK and/or xorg bug or flaw. There will be a new Ubuntu version in April, maybe the entire problem will go away, the 11.10 I am currently using is not known for great freedom from defects anyways.

Should the effect ever re-appear I will try to profile it and make more logs with the above defines, meanwhile I thank you for your assistance, since I am now more and more suspecting a bug in GTK itself I don't want to waste too much of your time.

Bernd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: editoroptions.xml
Type: text/xml
Size: 3468 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120331/91868928/attachment.xml>

Maybe your theme was reloaded.

Mattias

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.

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: > 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

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