Author Topic: Slow scrolling? [Ubuntu]  (Read 89907 times)

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Slow scrolling? [Ubuntu]
« Reply #75 on: September 05, 2012, 02:28:09 am »
Bisected: revision 8278 introduces the problem.  Something must have gone wrong with the Scintilla update.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Slow scrolling? [Ubuntu]
« Reply #76 on: September 05, 2012, 06:34:53 am »
So we should not touch it for the moment, but search the real cause.

Now I see it here also (I tested it with 8248).
Hope to find it soon.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Slow scrolling? [Ubuntu]
« Reply #77 on: September 05, 2012, 11:03:50 am »
First I thoght it is caused by changes in ScintillWX.cpp:DoPaint(), but it works correctly in the stc-sample of wxWidgets trunk (after patching it to highlight occurrences).
And they have the same changes (in fact they are taken from there, I guess).
The call to Refresh as workaround, after the ClearRange call should not be too harmful.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Slow scrolling? [Ubuntu]
« Reply #78 on: September 05, 2012, 04:41:30 pm »
I think the issue is in Editor::NotifyModified (line 4578 of Editor.cxx), in particular:

Code
	if (mh.modificationType & (SC_MOD_CHANGESTYLE | SC_MOD_CHANGEINDICATOR)) {
if (mh.modificationType & SC_MOD_CHANGESTYLE) {
pdoc->IncrementStyleClock();
}
if (paintState == notPainting) { //  ***********************
if (mh.position < pdoc->LineStart(topLine)) {
// Styling performed before this view
Redraw();
} else {
InvalidateRange(mh.position, mh.position + mh.length);
}
}
if (mh.modificationType & SC_MOD_CHANGESTYLE) {
llc.Invalidate(LineLayout::llCheckTextAndStyle);
}


Because we have a cursor move paintstate!=notPainting, (see the line marked with ********) but that cursor move only invalidates the region between the new and old positions, we don't get the full redraw that we need. A simple (but potentially inefficient) fix would be to skip the paintstate check.

I think we could also make a highlight mode code a little more efficient by only clearing the highlight if we have previously set it.
« Last Edit: September 05, 2012, 04:45:57 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Slow scrolling? [Ubuntu]
« Reply #79 on: September 05, 2012, 04:55:44 pm »
btw, either approach seems to work fine on my netbook (doesn't slow things down too much). I would still advocate reducing the number of ClearRange calls, because that could be expensive on a really big file.

I don't understand why this wouldn't also affect the wx demo.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Slow scrolling? [Ubuntu]
« Reply #80 on: September 05, 2012, 04:57:47 pm »
What makes me wonder, is that IncrementalSearch still works, but HighlightOccurrences does not.
And the ClearRange code is the same in both cases.

We can do the Refresh as workaround for the moment, but it looks like there must be some deeper issue that should be fixed, before it bites us at another place.

At the moment I would prefer not to change the (wx)scintilla code, if it is not definitely caused by it.
But (as I posted) before, HighlightOccurrences work with wxSTC and IncrementaSearch works with "our" wxScintilla.
So it might still be something in ouzr code, probably in our (wx)scintilla-changes.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Slow scrolling? [Ubuntu]
« Reply #81 on: September 05, 2012, 04:58:59 pm »
btw, either approach seems to work fine on my netbook (doesn't slow things down too much). I would still advocate reducing the number of ClearRange calls, because that could be expensive on a really big file.

I don't understand why this wouldn't also affect the wx demo.

ClearRange is only called once for every selection change, so it does not happen too often.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Slow scrolling? [Ubuntu]
« Reply #82 on: September 05, 2012, 05:02:21 pm »
ClearRange is only called once for every selection change, so it does not happen too often.

probably right, but scrolling by holding the down arrow on a really big file could have a decent sized performance hit. (think of the children... err... netbooks)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Slow scrolling? [Ubuntu]
« Reply #83 on: September 05, 2012, 05:17:13 pm »
What makes me wonder, is that IncrementalSearch still works, but HighlightOccurrences does not.
And the ClearRange code is the same in both cases.

because (painstate==notpainting)  == true for incremental search. IMHO it's a scintilla bug.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Slow scrolling? [Ubuntu]
« Reply #84 on: September 05, 2012, 05:46:56 pm »
So how about this:

1. Use the refresh workaround wherever it is needed
2. File a bug with scintilla (checking their bug tracker and sources first)

I will do some testing of the performance of the clear indicator calls on a large file on my netbook and propose a patch if necessary. (I used to have highlighting switched off because of the scrolling performance but it may not be so bad after the scrolling patch.)

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Slow scrolling? [Ubuntu]
« Reply #85 on: September 05, 2012, 07:25:10 pm »
What makes me wonder, is that IncrementalSearch still works, but HighlightOccurrences does not.
And the ClearRange code is the same in both cases.

because (painstate==notpainting)  == true for incremental search. IMHO it's a scintilla bug.
Why does it work in wxSTC then ?
It also uses scintilla internally and the chnage that discovered the issue is in ScintillaWx.cpp:DoPaint() .
Before the change Refresh was called from there (or more exactly from FullPaint()) .

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Slow scrolling? [Ubuntu]
« Reply #86 on: September 05, 2012, 07:58:14 pm »
Why does it work in wxSTC then ?

Do you have a link to the code you tested? (I suspect there must be a full refresh/update being called somewhere or for whatever reason the editor is in a notPainting state)

Quote
It also uses scintilla internally and the chnage that discovered the issue is in ScintillaWx.cpp:DoPaint() .
Before the change Refresh was called from there (or more exactly from FullPaint()) .

Yes, I see that here. (search the page for "refresh", it's the second instance.)

But I think that change is the right thing to do because they are trying to minimize on the amount of screen they repaint to be more efficient on things like VMs. But now they can no longer assume that a paint in progress will result in a full redraw, such as in that NotifyModified code.

EDIT: Less sure about this, because the DoPaint stuff is a wx-specific change. I guess the question is whether there is equivalent code for the non-wx implementations.
« Last Edit: September 05, 2012, 09:00:58 pm by dmoore »

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Slow scrolling? [Ubuntu]
« Reply #87 on: September 05, 2012, 08:27:05 pm »
Another strange thing:
if I do the exact same call to ClearRange from inside IncSearch (for the Indicator used in HighlightOccurences), it clears the indicators.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Slow scrolling? [Ubuntu]
« Reply #88 on: September 05, 2012, 09:04:45 pm »
Another strange thing:
if I do the exact same call to ClearRange from inside IncSearch (for the Indicator used in HighlightOccurences), it clears the indicators.

Is that call from inside a handler to wxEVT_SCI_UPDATEUI ? I think that is why paintState != notPainting in the cbEditor code.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Slow scrolling? [Ubuntu]
« Reply #89 on: September 05, 2012, 10:07:05 pm »
Another strange thing:
if I do the exact same call to ClearRange from inside IncSearch (for the Indicator used in HighlightOccurences), it clears the indicators.

Is that call from inside a handler to wxEVT_SCI_UPDATEUI ? I think that is why paintState != notPainting in the cbEditor code.
No, it's from inide a key-event handler.

And what's more:
after using the wxScintilla UI-Event in the stc-sample to call HighlightOccurrences instead the wxUpdatUI event, the issue is there also.

That means you are right and it is most likely a scintilla and not a wxScintilla issue (bug?).

I did a simple measuring with a wxStopwatch and mikroseconds ( not very exact I know, but hopefully enough to see a possible difference).
There is no significant difference between scrolling with the cursor through a source-file with a call to Refresh() and without it.
In all cases each step takes between 60 and 120 µs (average a little less than 100 µs).

So the Refresh workaround should do it.