Project organisation

[StendProg]

Thoughts on organization

Separating user control from main library is a good idea, especially if you point to support console applications. Don't forget to advertise that a user control package exists in the NuGet description, readme, etc.

Notes about .NET standard

While .NET standard supports .NET Framework and .NET Core, it also supports different run-time identities (Windows, MacOS, Linux, etc). SkiaSharp has multiple platform support so this is not a problem. However, you need to make some tests to make sure it works fine on each release. What do you think about setup some CI/CD system?

SKSurface vs SKCanvas

I looked at QuickPlot and one thing I see that is negative is you are using SKSurface as parameter for drawing functions. But SKCanvas intended for this purpose. SKSurface describes something that is back-end specific so you must use it when it is really needed. SKCanvas can come from more potential sources than just SKCanvas.

Support layout without requiring a render

I noticed that you recently changed ScottPlot to use a dynamic layout (which resizes the data area based on things like how large the axis labels are). This requires a render to determine the proper layout. While working to add Skia support to ScottPlot I missed the old GetLayerRect() functions that calculate layer size and position using simple calculations that do not require a render. Supporting layout functions that do not require rendering would be helpful for QuickPlot, especially when it comes time to implement onscreen GL user control.

SKGLControl & Designer Crashes

I hope it possible to solve designer crashes. SKGLControl is a simple wrapper of TKGLControl. I copied its implementation when I wrote FormsPlotSkia because SKGLControl crashed the editor.

[swharden]

@StendProg I merged your comments into your original post like you asked. I also modified your text to make the English a little bit easier to read - I hope you find this acceptable.

I will work to improve QuickPlot this weekend based on your suggestions. Thank you again for your valuable insight into this project. I think QuickPlot can become something very good!

Make some tests to make sure it works fine on each release

Tests seem difficult because bugs will result in images with errors rather than exceptions. I was thinking about using the cookbook as tests. Rather than saving images as files, the tests would create each cookbook item as a bitmap in memory, then analyze the bitmap by computing the MD5 hash and comparing it to the expected MD5 hash. I fear this may fail because slight differences in anti-aliasing or fonts on different systems may cause subtle differences which cause the hashes to change.

What do you think about setup some CI/CD system?

I think this would improve code quality and confidence that this project works reliably on many systems. However, I have little experience with CI/CD. Do you have any recommendations of other open-source software projects that do a good job using CI/CD that I can study and mimic for QuickPlot?

[StendProg]

I think this would improve code quality and confidence that this project works reliably on many systems. However, I have little experience with CI/CD. Do you have any recommendations of other open-source software projects that do a good job using CI/CD that I can study and mimic for QuickPlot

AppVeyor as i hear was best CI for windows Visual Studio solutions. But a lots many others powerfull and free system for GitHub for now..Net Core have reach command line build support, this make setup much more simple. I have a bit experience with private Gitlab/Jenkins CI setup only. It take a time to initially setup, but after works for a years without any service. If you find it acceptable, additional unit tests may be implemented. It looked like a hell to write hundreds of tests for existing ScottPlot project. But not so scarry write tests together with the growth QuickPlot project. Can't point existing projects(get access to PC only tomorrow). .NETCore have Docker images with examples of build, test and deploy tasks. All CI support building with Docker for today.

[swharden]

@StendProg thank you for your suggestions!

CI: I set-up CI with Azure Pipelines and added a status badge to the front page. I noticed that this is the CI tool that SkiaSharp uses. It was easy to configure.

Tests: I have more work to do to determine the best class structure for QuickPlot, but once it begins to solidify I will start adding tests. Azure Pipelines will make it easy to run these tests after commits.

User control: I think I simplified the user control by having a single control and creating a SKControl or GLControl programmatically. This means that anyone who installs the user control will have to install the OpenTK and OpenTK.GLControl whether they plan to use OpenGL or not.

Automatically using OpenGL if it is supported: I think this code will automatically use SKControl if computer hardware does not support OpenGL, but I'm not sure how to test if this is true. What do you think about this method?

https://github.com/swharden/QuickPlot/blob/4b9f775badfce62944dc3ec7c3177a65d70bbe26/src/QuickPlot.Forms/InteractivePlot.cs#L41-L50

https://github.com/swharden/QuickPlot/blob/4b9f775badfce62944dc3ec7c3177a65d70bbe26/src/QuickPlot.Forms/InteractivePlot.cs#L61-L93

[swharden]

The QuickPlot project has made a lot of progress... but I'm probably going to abandon this effort.

The build target issue is just too painful for me to work with anymore. I have a .NET Standard library to handle plotting, a .NET Framework library to provide a WinForms user control, and a .NET Framework demo application which uses the user control. I had to try all sorts of combinations of build targets until I finally got it to work using ("any CPU", "any CPU", and "x64", respectively).

This week without explanation the user control now crashes Visual Studio. I tried all combinations of build targets but I can't get it to work anymore on my system. The program compiles and runs great, but Visual Studio crashes every time.

Unable to load DLL 'libSkiaSharp': The specified module could not be found.  
(Exception from HRESULT: 0x8007007E)

As much as I like Skia, and as much as OpenGL acceleration is great for plotting, I feel that SkiaSharp's NuGet package is too brittle to use in a public project whose primary goal is simplicity and ease of use. SkiaSharp's issues are numerous and they haven't posted an update on NuGet in almost a year. GDI+ is slow, but it always works for everyone...

[swharden]

I realized I can render thousands of lines on a WPF canvas (and convert it to a Bitmap if needed) very quickly. Hardware acceleration is used if supported, and software rendering is used if it is not. Unlike GDI+ (which is always slow for large images), rendering speed using WPF doesn't depend on image size but rather the number (and length) of lines. 1000 short lines renders very fast. 1000 long lines renders slow. This is independent of total image size...

EDIT: WPF drawing performance is similar enough with System.Drawing.Common that it doesn't excite me anymore. One advantage is that DPI is arbitrary, allowing options for high-quality image rendering and DPI scaling.

[swharden]

This week without explanation the user control now crashes Visual Studio. I tried all combinations of build targets but I can't get it to work anymore on my system. The program compiles and runs great, but Visual Studio crashes every time. Unable to load DLL 'libSkiaSharp': The specified module could not be found.

Update: This was problem was probably caused when I upgraded Visual Studio to version 16.3.1. Later, when I upgraded to version 16.3.3, Visual Studio started working again.

SkiaSharp's issues are numerous and they haven't posted an update on NuGet in almost a year.

Update: SkiaSharp posted a new package on NuGet about two weeks after I wrote that.

[swharden]

... also, I have now learned that if you create a user control in a project which targets x64, it will always crash Visual Studio!