Found it. Each new demo on load call Control->Reset(), Reset call InitializeScottPlot, InitializeScottPlot make new subscribe to PbPlot_MouseWheel without correct unsubscribe from previous handler.
Thus, as a result of wandering through the demo, it was possible to get a dozen handlers that were all called on the single mouse wheel scroll.
This fix solves most of the problems and the latency is now comparable to the HighQuality render time. (10-500 ms instead of seconds, which led to confusion). Anyway i want to take additional time to make the another improvements.

but instantly canceled when a new request arrives.

There is no any possibility to cancel (or run and forget in other thread) Render in current ScottPlot implementation.
The only solution I see is to create a copy of the Plot and run HighQualityRendering on it in separate thread, but this is a very dubious decision...
It looks like there's nothing better than a delay timer.

Found an elegant way to render the Plot simultaneously on different Threads, through a copy of the settings, not the plots. Different copies of settings store different copies of Graphics objects and do not have conflicts.
But suddenly I discovered that GDI objects like Pen, Brush also cannot be called from different threads. And there is nothing to do with this, copying Plottable means copying their data, and this is the same as copying Plot.
Another well-known argument in favor of allocating/disposing GDI objects in place, instead of caching (this is a long-standing dispute) is multithreading. Now I am definitely all hands for the allocating/disposing of GDI objects in place. 😕

Improve mouse scroll wheel responsiveness by delaying high quality render #543

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions