It can be seen from the demo that there will be obvious jamming and delay when scrolling in the text rendered by "collectiontagger < isquigletag >. It will affect our fluency in the coding process, which has a serious impact on the use experience of our products.
The project has been sent to you by email. You just need to reply me here.
Hello,
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.
We have such needs in the actual use process. In many cases, we don't need to render on the "editor", but in some cases, we need to obtain the "isquigletag" at this location, and obtain the display information of "QuickInfo" through the "isquigletag".
In this case, is there any good solution to meet my needs?
If you don't need to render the UI squiggles for most of these tagged ranges, then you should use another kind of tag for the ranges instead. You can make any kind of custom tag type that doesn't inherit ISquiggleTag to store your data, and can make a custom IQuickInfoProvider language service (inherit QuickInfoProviderBase) that watches for the view's offset being in a tagged region and shows the related tag's quick info data. If you'd like us to send your our source code for SquiggleTagQuickInfoProvider so you can see how we do it for ISquiggleTag and then modify it for your own tag type, please write us offline.
To sum up, you should only use ISquiggleTag for regions that really need a squiggle rendered. Otherwise, you are spending a lot of time rendering them unnecessarily, and squiggle-rendering is one of the slowest parts of the UI.
Please log in to a validated account to post comments.