User forums > Using Code::Blocks
Slow scrolling? [Ubuntu]
dmoore:
--- Quote from: oBFusCATed on July 19, 2012, 12:50:30 am ---dmoore: Is this perf: https://perf.wiki.kernel.org/index.php/Main_Page ?
--- End quote ---
Yep.
MortenMacFly:
--- Quote from: dmoore --- I guess the biggest difference between C::B and the STC sample is the sheer size of C::B. Would it make sense that a single STC event will propagate through many more handlers in C::B than in a stripped down sample?
--- End quote ---
Did you try:
- temporarily really *remove* all plugins, so C::B becomes an editor
- create a scintilla project using wxSmith with an embedded wxScintilla control?
- did you try to disable "hijacking" the scintilla events in cbEditor:
- do not connect the events not really needed in cbEditor::CreateEditor
?
dmoore:
A few more tests...
* Removing plugins (as opposed to disabling them) didn't have much of an impact on performance
* Disabling plugins does improve scrolling performance a bit
* If you switch off highlighting, scrolling performance all improves a bit
* It tried adding a wxScintilla control in a separate window in C::B with the CPP lexer with a large file, scrolling is still laggy
* With all plugins switched on, I do get scrolling lag on my desktop machine too (i.e. when holding down arrow for 10s, scrolling will continue for several secs after releasing)
So I suspect the problem really is a result of the sheer size of C::B and the number of events floating around. (Of course it's still possible there is some issue with too many events being fired off)
--- 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 ---
Given it looks like it is going to be hard to improve overall performance, why don't we come up with a better patch for this one. To be clear, this would help resolve the issue that user secks reported: when you scroll the mousewheel really quickly you get far less movement than if you had scrolled the same amount, but moving the mousewheel slowly. Perhaps one simple workaround would be to discard mousewheel events based on the lower of the time it took to process the last one and some absolute threshold (instead of just looking at the time to process that last one).
oBFusCATed:
What are the steps to reproduce the slow scrolling?
On my machine gentoo 64bit+core2quad+nvidia binary scrolling is responsive and non-laggy.
Jenna:
--- Quote from: dmoore on July 22, 2012, 05:51:30 pm ---
--- 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 ---
Given it looks like it is going to be hard to improve overall performance, why don't we come up with a better patch for this one.
--- End quote ---
If we do so, we should post it in wxWidgets mailing list also, because it's a wxWidgets patch and not a C::B patch.
And it only affects the scrolling with the mouse-wheel and not the scrolling at all.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version