Slow scrolling? [Ubuntu]

[MortenMacFly]

does anyone have any clues as to what the issue might be?

- Try to turn of CC
  -> if that help, try to only turn off real-time parsing of CC
- Try to turn off the SpellChecker plugin
- Try if other scintilla based editor like SciTE does slow-down, too
  -> if so, its a window manager issue

[secks]

does anyone have any clues as to what the issue might be?

- Try to turn of CC
  -> if that help, try to only turn off real-time parsing of CC
- Try to turn off the SpellChecker plugin
- Try if other scintilla based editor like SciTE does slow-down, too
  -> if so, its a window manager issue

I tried --safe-mode (which should disable CC and spell checker) .. still the same effect ..
scite scrolls just fine .. as i mentioned scite scrolls about 10x more per full-wheel-scroll than does c::b

[dmoore]

does anyone have any clues as to what the issue might be?

- Try to turn of CC
  -> if that help, try to only turn off real-time parsing of CC
- Try to turn off the SpellChecker plugin
- Try if other scintilla based editor like SciTE does slow-down, too
  -> if so, its a window manager issue

I tried --safe-mode (which should disable CC and spell checker) .. still the same effect ..
scite scrolls just fine .. as i mentioned scite scrolls about 10x more per full-wheel-scroll than does c::b

This is an old, old issue that hasn't been resolved. I spent a bunch of time trying to figure this out but I wasn't able to isolate the cause to a single factor. I can't remember if anyone tried running a minimal wxScintilla sample to see if the same performance issue shows up there. That may be worth exploring.

[Kalith]

What about wxWidgets samples (if I understand correctly, wxScintilla has been integrated into wxWidget as wxStyledTextCtrl) ?

[Jenna]

What about wxWidgets samples (if I understand correctly, wxScintilla has been integrated into wxWidget as wxStyledTextCtrl) ?

Is slow here too (wx2.9.5 from trunk).

[Jenna]

This is an old, old issue that hasn't been resolved. I spent a bunch of time trying to figure this out but I wasn't able to isolate the cause to a single factor. I can't remember if anyone tried running a minimal wxScintilla sample to see if the same performance issue shows up there. That may be worth exploring.

If I remember correctly there are two different issues:

• the scrolling is slow, even if the scrollbar is dragged
• the scrolling in priciple is fast enough, but the amount of lines scrolled per mousewheel-delta is very low

The first issue can be related to several things, one is that the mousewheelevents are blocked as long as the last one took to be processed.

    // Prevent having an event queue with wheel events that cannot be processed
    // reasonably fast (see ticket #9057) by ignoring all of them that happen
    // during the time interval corresponding to the time it took us to handle
    // the last one.

The second issue is a wxWidgets restriction, because the mousewheel-event always returns three as linesperaction.
We could work around that by introducing a (configurable) factor that is multiplied with the default number of linesperaction, in the call to DoMousewheel in wxScintilla::OnMouseWheel.

[dmoore]

If I remember correctly there are two different issues:

• the scrolling is slow, even if the scrollbar is dragged
• the scrolling in priciple is fast enough, but the amount of lines scrolled per mousewheel-delta is very low

The first issue is the higher priority for me. On low end hardware, scrolling performance sucks (It's still noticeable, but good enough for me on my desktop). Others might feel more strongly about the mousewheel-delta.

[secks]

    // Prevent having an event queue with wheel events that cannot be processed
    // reasonably fast (see ticket #9057) by ignoring all of them that happen
    // during the time interval corresponding to the time it took us to handle
    // the last one.

This sounds like the culprit .. So it must be overhead from c::b that causes the events to hang and be discarded .. scite scrolls the same file at nearly 10x the lines per wheel..

The second issue is a wxWidgets restriction, because the mousewheel-event always returns three as linesperaction.
We could work around that by introducing a (configurable) factor that is multiplied with the default number of linesperaction, in the call to DoMousewheel in wxScintilla::OnMouseWheel.

This sounds like the only viable option .. I have a wedding coming up and am short on free time .. I'll look into it when I get a chance but I have no clue on when that will be .. If someone else can get to it before me, then by all means ..... 

[Jenna]

    // Prevent having an event queue with wheel events that cannot be processed
    // reasonably fast (see ticket #9057) by ignoring all of them that happen
    // during the time interval corresponding to the time it took us to handle
    // the last one.

This sounds like the culprit .. So it must be overhead from c::b that causes the events to hang and be discarded .. scite scrolls the same file at nearly 10x the lines per wheel..

It was neither a C::B bug nor a C::B patch.
As far as I know, it is a wxScintilla patch, and you find it in wxwidgets stc also.
It is most probably related to wxwidgets event handling.
If I remove all the slowing stuff scrolling still works.
I did not look into the original bug-report, so I don't know whether it is really (still) needed or not.

The second issue is a wxWidgets restriction, because the mousewheel-event always returns three as linesperaction.
We could work around that by introducing a (configurable) factor that is multiplied with the default number of linesperaction, in the call to DoMousewheel in wxScintilla::OnMouseWheel.

This sounds like the only viable option .. I have a wedding coming up and am short on free time .. I'll look into it when I get a chance but I have no clue on when that will be .. If someone else can get to it before me, then by all means ..... 

I can create a patch for it, but if it makes it into trunk is not only my decision.

[Jenna]

If I remember correctly there are two different issues:

• the scrolling is slow, even if the scrollbar is dragged
• the scrolling in priciple is fast enough, but the amount of lines scrolled per mousewheel-delta is very low

The first issue is the higher priority for me. On low end hardware, scrolling performance sucks (It's still noticeable, but good enough for me on my desktop). Others might feel more strongly about the mousewheel-delta.

I don't have a slowdown here, so it might be related to the graphics driver.
Did you test it with pure scite, so no wxwidgets-stuff is between scintilla and the system ?

[secks]

I don't have a slowdown here, so it might be related to the graphics driver.
Did you test it with pure scite, so no wxwidgets-stuff is between scintilla and the system ?

I'm on Mint 12 - Lisa (oneiric) .. Using i7 intel video .. I installed scite from the repo (Version: 2.25-1) .. The scrolling is very fast (around 200-250 lines per full wheel) where c::b only does around 20

EDIT: also, another employee here has a nvidia geforce 8600 gts .. it's not the beefiest card, but that thing is only scrolling a few lines at a time ..

[secks]

I install juffed and eric (qscintilla) .. those are slow too .. both are at ~50 lines

[Kalith]

This sounds like the culprit .. So it must be overhead from c::b that causes the events to hang and be discarded ..

I'd say the fact that C::B scrolls slowly is a single symptom of a more general problem, that is the overall slowdown of the whole IDE when dealing with text rendering. I don't code on linux no more these days, but from what I recall, selecting and even typing text could become laggy (I wrote it in my first post in this topic, by the way, and also here).

[dmoore]

If I remember correctly there are two different issues:

• the scrolling is slow, even if the scrollbar is dragged
• the scrolling in priciple is fast enough, but the amount of lines scrolled per mousewheel-delta is very low

The first issue is the higher priority for me. On low end hardware, scrolling performance sucks (It's still noticeable, but good enough for me on my desktop). Others might feel more strongly about the mousewheel-delta.

I don't have a slowdown here, so it might be related to the graphics driver.

Yes tested on various scintilla based editors, which were by and large free of the issue (I don't think I ever got around to testing the wxWidgets sample, but will do). My suspicion is that it is something specific to the wxWidgets wrapper. The bug fix implemented for that ticket #9057 is probably just masking the real bug (or performance problems) in the rendering/event pipeline.

[p2rkw]

So, it seems that is only linux related bug. Maybe its problem of wxGtk: http://comments.gmane.org/gmane.comp.lib.wxwidgets.devel/12412 and http://old.nabble.com/why-do-wxMac-and-wxGTK-always-erase-window-background--td20532056.html ?

btw. I can't find PlatGTK.cxx, found only PlatWX.cxx. What's location of this file?