User forums > Using Code::Blocks
Slow scrolling? [Ubuntu]
Jenna:
--- Quote from: dmoore on July 16, 2012, 10:39:53 pm ---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.
--- End quote ---
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.
--- Quote from: wxScintilla::OnMouseWheel --- // 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.
--- End quote ---
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:
--- Quote from: jens on July 17, 2012, 07:17:04 am ---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
--- End quote ---
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:
--- Quote from: wxScintilla::OnMouseWheel --- // 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.
--- End quote ---
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..
--- Quote from: jens on July 17, 2012, 07:17:04 am ---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.
--- End quote ---
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:
--- Quote from: secks on July 17, 2012, 04:39:22 pm ---
--- Quote from: wxScintilla::OnMouseWheel --- // 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.
--- End quote ---
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..
--- End quote ---
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.
--- Quote from: secks on July 17, 2012, 04:39:22 pm ---
--- Quote from: jens on July 17, 2012, 07:17:04 am ---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.
--- End quote ---
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 ..... :)
--- End quote ---
I can create a patch for it, but if it makes it into trunk is not only my decision.
Jenna:
--- Quote from: dmoore on July 17, 2012, 04:13:25 pm ---
--- Quote from: jens on July 17, 2012, 07:17:04 am ---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
--- End quote ---
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.
--- End quote ---
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 ?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version