ClassificationTagger performance issues

Can you please elaborate on how you are producing the issue you described?

While running the "C# Editor (.NET Lang. Add-on)" sample, the sample file is relatively small and there is not a very big comment block in the sample. I zoomed out to the minimum level where pretty much the entire document was visible, so there wasn't much to scroll. I then commented out the entire file, copied it, and then pasted it several times to produce about 1500 lines of code, all comments. I was able to use the mouse wheel to scroll up and down without any noticeable delay in scrolling.

I also used our "SDI Code Editor (in-line)" sample with the same 1500-line file of comments and used both the "C# - Free Language Definition" and "C# (.NET Languages Add-on)" languages. I did not observe any scrolling issues. I also tried zooming in all the way (in case I misunderstood which direction you zoomed) and still did not observe any scrolling issues.

Example: https://ibb.co/vDYBknx

Sorry for the poor recording quality.

My monitor is 2K, so the viewing range is relatively large. Cursor movement can feel sluggish in places where text fills up. Once scrolled to an empty position it became smooth

Hello,

I made a very dense text file and loaded that up to use for performance profiling.  From what I can tell, it seems like pretty much all the time is spent in the OnRender phase, rendering text.  A problem with WPF is that when OnRender is called, you have to render the entire text area "canvas".  You can't only render an "invalidated bounds" area like in WinForms.  Thus it's unfortunately rendering the entire canvas (and all its text) as things like selections are changed and that is what leads to the sluggishness in that scenario.

Do you mean that this is a problem with WPF itself? It is not clear whether VS uses UWP or WPF for rendering components. But their experience on larger text is very smooth

VS does use WPF.  To clarify without getting into too much detail, our current SyntaxEditor design uses a canvas control that renders all parts of the text view in it.  This was done to support compatibility of rendering and other APIs between the WPF, WinForms, and UWP versions of the editor, so they can be maintained in sync moving forward.  While it is very robust and allows us to render things the same way across platforms, about the only downside is that you can lose out on some of the visual caching that WPF could do in certain situations if text lines and all the other parts of the text view were retained as individual visuals instead of being rendered together in a single canvas control.  That might be why VS has a slight performance edge in this scenario.