Abysmal arrow key scroll performance

I just fired up the 3.0 sample app in a maximized state and scrolled the entire length of a 4000 line document at normal scroll speed with no visible slowdown. Do you have any non-default settings that might cause this?

No, I start the sample app (no modifications from initial install), do a select all on the text (using the default loaded on start-up c# language and example text), paste it twice at the bottom as to create it long enough to scroll, and then when I try scrolling back up the issue then becomes apparent. If I only past one copy at the end I am able to scroll back up without any performance degradation but once I reach the top if I then attempt to scroll down the performance degredation happens immediately.

My bad... I was using the scrollbar arrows, not the keyboard arrow keys. I see what you mean now. I'll write this down to check it out. Thanks!

Do me a favor and try your repro with bracket highlighting disabled. I think I've narrowed it down to something to do with that. Let me know if the problem disappears when you turn off bracket highlighting.

I have just tried it with bracket highlighting disabled (BracketHighlightingVisible set to false via the properties panel in the test application) and I still get the same performance degredation. I thought at first it might have been related to caret position in this kind of way so I also did a Control + arrow key movement (ie. caret position does not change so any logic related to its movement would not be carried out) and this still resulted in the same slow performance.

Are you positive, because after I turn BracketHighlightingVisible to false, I see no slowdown whatsoever any more. Whereas I do see the slowdown if I leave it on. I repro the slowdown by opening the sample app, select all, pasting a couple times, going to the top of the doc and placing the caret at offset 1 (before second char), then holding the down arrow key. You have the latest 3.0 build, right?

The reason bracket highlighting is slowing it down is that if the caret is currently highlighting a bracket, and the selection changes we have to repaint the region where the brackets are. Right now, it's repainting the entire range between the brackets, which should be optimized. When it does that, that seems to kick off the slowdown. I test this by overriding the OnRender method of the EditorView and seeing what the clip bounds are. If there is no bracket highlighting change, fast backbuffer scrolling occurs meaning most of the backbuffer "slides" up and only 1-2 new lines are really painted from scratch. Therefore, that situation paints fast.

How fast does painting occur if you just hold the scrollbar down arrow?

Absolutely positive. Yes I have the latest build (3.0.0181). BracketHighlighingVisible set to false in the properties panel of the sample app. As I said it also occurs on Ctrl + arrow key scrolls – no caret movement so no caret movement logic! Scroll arrow performance is fine.

If you still don't believe that turning of bracket highlighting does not solve the problem I can provide you with profiler snapshots that speak to the contrary. The slow down is still apparent with bracket highlighting off, with Ctrl + arrow key scrolls, and with files with bracket matching characters removed!!!!!

I believe you. I'm just saying that here, I can see a slowdown that is caused by bracket highlighting and identified the reason why. When I turn it off, it scrolls about as fast as when using the scrollbars. Now Ctrl+Down and Ctrl+Up are still slower than they should be though so that needs to be figured out yet.

These sort of things are tricky to debug since something in the painting or scrolling code is causing them. Can I email you soon to discuss in more detail which scenarios things are working the expected speed and in which they are not? I might like your help with profiling too.

We've made several changes to speed up scrolling in various scenarios. I'm emailing you a link for you to test it out.

Today's maintenance release has the speed increases in it.