Abysmal arrow key scroll performance

SyntaxEditor for Windows Forms Forum

Posted 14 years ago by mbren
Avatar
There is significant performance issue with scrolling through a document in the syntax editor with the arrow keys. With the sample application running full screen at 1600x1200 pressing and holding either the up or down arrow key with even a relatively small document (100 or so lines) results in scrolling about 10 lines at the expected scroll speed, but this quickly then degrades to a speed of around 1-2 lines per second, making navigating through the document via this method practically unusable. Running at smaller control sizes exhibit similar results but the initial speed is maintained for a little longer.

Is this a known issue, is there a method to improve this performance with the current build? Is this something that is likely to be looked at for future releases?

Comments (11)

Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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?


Actipro Software Support

Posted 14 years ago by mbren
Avatar
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.
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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!


Actipro Software Support

Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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.


Actipro Software Support

Posted 14 years ago by mbren
Avatar
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.
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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?


Actipro Software Support

Posted 14 years ago by mbren
Avatar
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.
Posted 14 years ago by mbren
Avatar
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!!!!!
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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.


Actipro Software Support

Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
We've made several changes to speed up scrolling in various scenarios. I'm emailing you a link for you to test it out.


Actipro Software Support

Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Today's maintenance release has the speed increases in it.


Actipro Software Support

The latest build of this product (v2018.1 build 0341) was released 6 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.