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. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
