Slow scrolling? [Ubuntu]

[eranif]

Hello,

I wanted to add my 10 cents:

I also noticed performance problems on GTK few years ago on Linux while scrolling with the mouse.
After a long debugging sessions, I changed the following in my code:

- Never call SetStatusMessage directly from the editor, instead fire a custom event using 'AddPendingEvent' in the OnScintillaUpdateUI (EVT_SCI_UPDATEUI) event handler
so my code looks like this:

Code

void Editor::OnScintillaUpdateUI(wxScintillaEvent &e) 
{
...
	//update line number
	wxString message;

	message << wxT("Ln ")
	<< curLine+1
	<< wxT(",  Col ")
	<< GetColumn(pos)
	<< wxT(",  Pos ")
	<< pos;

	// Always update the status bar with event, calling it directly causes performance degredation
	DoSetStatusMessage(message, 1);
...
}

void Editor::DoSetStatusMessage(const wxString &msg, int col)
{
        // fire custom event
	wxCommandEvent e(wxEVT_UPDATE_STATUS_BAR);
	e.SetEventObject(this);
	e.SetString(msg);
	e.SetInt(col);
	wxTheApp->GetTopWindow()->GetEventHandler()->AddPendingEvent(e);
}

- Line number margin: use a hard coded line margin width, calling TextWidth is a real pain under Linux:

Code

	// Line number margin
#ifdef __WXMSW__
	int pixelWidth = 4 + 5*TextWidth(wxSCI_STYLE_LINENUMBER, wxT("9"));
#else
	int pixelWidth = 4 + 5*8;
#endif

	// Show number margin according to settings.
	SetMarginWidth(NUMBER_MARGIN_ID, options->GetDisplayLineNumbers() ? pixelWidth : 0);

- Two phase drawing, buffered drawing settings are different from one OS to another here are the settings I am using:

Code

#if defined(__WXMAC__)
	// turning off these two greatly improves performance
	// on Mac
	SetTwoPhaseDraw(false);
	SetBufferedDraw(false);

#elif defined(__WXGTK__)
	SetTwoPhaseDraw(true);
	SetBufferedDraw(false);

#else // MSW
	SetTwoPhaseDraw(true);
	SetBufferedDraw(true);
#endif

Adding these 3 changes improved performance noticeably on GTK and Mac for me


Eran

[dmoore]

Here's an update.

I played around with the stc example (both C++ and python). The test machine is a netbook running ubuntu 12.04. My test of scrolling responsiveness is to hold the down arrow key for about 10 seconds. On Code::Blocks, in safe mode, scrolling lags badly. I release the key and the editor keeps scrolling for another 10 seconds. I tried switching off the handlers to all of the wxSCI_EVT, but that didn't appear to do much. Similarly tried all of eranif's tips, with no obvious improvement. I also tried switching off some (but not all) idle handlers and timers, and all of the styling calls.

When I run the wxWidgets samples (both C++ and Python) there is no lag. Scrolling stops when you release the key. (I wouldn't say that scrolling is super snappy, however.) Could it be something as simple as the key repeat rate in C::B being set too high?

What is left to switch off in C::B that might help isolate the cause?

[oBFusCATed]

dmoore: Have you tried to use a profiler? oprofile for example?

[dmoore]

dmoore: Have you tried to use a profiler? oprofile for example?

Someone would suggest a rational approach...  

Is oprofile any better than perf? I tried running perf, but the output didn't seem all that useful (most likely user error). I couldn't figure out if there  was a way to collapse the lower level calls into the calling code::blocks routines. In the run I did there was a lot of time spent in cairo and pango calls, but that's not really surprising when all i was doing was scrolling.

I also tried valgrind, but having some weird ubuntu issue with callgrind_control:

Code

moi@home:~$ callgrind_control 
No active callgrind runs detected.

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?

[oBFusCATed]

dmoore: Is this perf: https://perf.wiki.kernel.org/index.php/Main_Page ?

[dmoore]

dmoore: Is this perf: https://perf.wiki.kernel.org/index.php/Main_Page ?

Yep.

[MortenMacFly]

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?

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)

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

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]

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

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.

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.

[dmoore]

What are the steps to reproduce the slow scrolling?
On my machine gentoo 64bit+core2quad+nvidia binary scrolling is responsive and non-laggy.

Wouldn't be surprised if it was a Ubuntu problem.

To reproduce:
1. Open a large cpp file with lots of text on each line
2. Compare
a. Ripping the mouse wheel really quickly
b. Moving the mouse wheel slowly the same distance
3. Hold down arrow for about 10s. When you release scrolling will continue for several seconds.

My desktop is 2 yo dual core, older nvidia card. Ubuntu 12.04

[dmoore]

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.

Agree on both counts.

Perhaps a better fix than my first suggestion would be to put a cap on how many mousewheel events get queued. Events should only be discarded after exceeding a decent threshold. (Should be willing to trade off a little lag).

[Jenna]

A little test from my side:

• I always use te same c++ source file,
• I place the caret in the first line and scroll down with the arrow key until line 350,
• if I release the arrow key the editor does not stop scrolling for about 350~450 lines (!) (scrolling stops if the caret is somewhere between line 700 and 800).
• This happens for the first time I scroll it, if I do it a second time, scrolling is way faster and scrolling stops immediately.

So it looks like it's obviously related to doing the text layout in scintilla.
But the obvious is not necessary the truth, so further investigation is needed.

By the way making the amount of lines per wheel-click configurable is a good thing in my opinion.
Shall I prepare a patch for it ?

[oBFusCATed]

By the way making the amount of lines per wheel-click configurable is a good thing in my opinion.
Shall I prepare a patch for it ?

I think the problem with the scrolling is that there is no acceleration, not that the scrolling is slow.
At least firefox seems to have some acceleration in it, but I may be wrong as my mouse doesn't have a lock which limits the rotations (the mechanism making the mouse click when scrolling).

[MortenMacFly]

Shall I prepare a patch for it ?

Feel free to do. I have some changes related to wxScintilla pending, but I can handle...