Refactor all controls to use a common back-end

What can we do to make ScottPlot better? This was originally the intention, however, when the Avalonia module was created for 4.0.39 it was decided that it would be annoying to bump the package version of the rest of ScottPlot. This change would make a move to supporting another platform easier (or indeed updating the WPF and WinForms controls to use ControlBackend which would help in maintainability). I think I said I would backport ControlBackend to WPF and WinForms when I first created the Avalonia control, 4 months ago…

The ScottPlot Roadmap may provide additional context regarding current goals and future directions.

[erichiller]

I’m out of town and brought a laptop but I didn’t have any spare Windows licenses - so I quickly installed Ubuntu 20.10, normally I use Windows for desktop things.

Perhaps Linux fires mouse move events more often or something and a VM cannot keep up.

I was thinking the same, that Linux might be sending more mouse move events, but I don’t have a Windows machine ATM to confirm this (next week I will).

The call to bmp.Save() inside BmpImageFromBmp was taking ~32ms per call, I’m not sure if that’s the same as Windows or not. If it is the same, then the suspicion that Linux is sending more mouse move events than Linux seems likely.

Thank you for the comments, I will definitely go through and try the changes as soon as I’m back to my actual machine mid-next-week.

[swharden]

Control Backend Next Moves

I’m just thinking of moving the ControlBackend from the Avalonia project to the ScottPlot project

I suspect you wrote this before I posted https://github.com/swharden/ScottPlot/issues/637#issuecomment-735963270, but I agree! I plan to do this tonight.

There is perhaps benefit to not making ControlBackend part of the main ScottPlot project until this is done as this would necessitate a breaking change

Perhaps we could keep the ControlBackend that works, and we can keep the WpfPlot and FormsPlot controls as they are because they all work too. Experimentation could be done in ControlBackendExperimental, FormsPlotExperimental, etc. This way everything that currently works would keep working while we experiment with these ideas. When ScottPlot 4.1 gets out of pre-release we can delete the old ones and rename the new ones.

It may be unexpectedly easy to create new experimental controls to use the experimental backend, as those controls would be very thin and wouldn’t be much effort to maintain along the way as the backend is experimented on.

Displaying cropped giant plots

This is an interesting idea! It does take a lot of memory though (I’m recalling someone wanted to show 100s of plots #257). Right now (as of ScottPlot 4.1) a new Bitmap is created every time Render() is called. How long this actually takes may be worth benchmarking. My thought is that limiting creation of new bitmaps to Resize() events would be a big win because that’s a rare event. Your suggestion (display a portion of a huge bitmap) would eliminate even that step, but my lean is to consider resizes a rare event so probably not worth optimizing for at this time. Plus if we optimized for 5000px then someone with an 8K monitor will complain shortly after 😆

EDIT: Let’s benchmark how long it takes to create a large bitmap vs. how long it takes to draw a typical plot on it. The controls currently create a new bitmap on every render, so maybe this isn’t even a slow enough step to warrant optimization right now…