After looking at the sample project, this thread is related to the squiggle line rendering performance slightly slowing down scrolling performance when there are a large number of squiggle lines.
While we didn't notice much of a slowdown in your sample project, we did performance profiling and did see that squiggle line rendering in that sample with many squiggle lines is taking ~80% of the rendering time. Nearly all this time is spent building up a PathGeometry to render each squiggle line properly. The time-consuming part of the code is calling into the APIs Microsoft provides to build the PathGeometry, and our code calling into that is pretty basic and does not take much time itself.
We tried several other ideas on calling into the API and/or rendering the lines differently. In the end, we were able to speed things up a small amount, but still must use PathGeometry. One thing we were able to do to help with PathGeometry is to cache the geometry used for a certain width. If another squiggle line renders at the same width in the same drawing session, it will reuse that geometry, thereby skipping the time-consuming creation of a new PathGeometry instance. Thus if a lot of your squiggles end up being the same character count, you should see a large performance boost in rendering of the squiggle lines in the next maintenance release. If your squiggles are all over distinctly different character counts, the performance gain from our updates will be smaller. As mentioned above, we must continue to use PathGeometry in WPF.