Bring up to date with Arbatel? :) about eto.veldrid

[ItEndsWithTens]

I certainly intended to keep this up to date with anything I learned in the process of using Veldrid in my main project, but a quick glance over the code and I don't think any of it applies outside of Arbatel.

Over there I do create a new CommandList at the start of every frame and dispose of it at the end, which I don't do here, but frankly I'm not sure if I really need to do that, and I plan to review my motivations for the practice. This project seems to work without any such disposal, as far as I can tell.

Are there specific changes you noticed that you think belong in Eto.Veldrid? I may very well just be overlooking something important.

[philstopford]

I didn't dig closely into the details, but was curious about :
ItEndsWithTens/Arbatel@9d42b9f
ItEndsWithTens/Arbatel@bdd09c0
ItEndsWithTens/Arbatel@4c6cf66

[ItEndsWithTens]

Regarding those three commits:

The first upgrades the version of Veldrid.SPIRV to 1.0.9, where I'd neglected to update Arbatel from 1.0.7. Eto.Veldrid was already using 1.0.9, so that didn't need to be brought over, but I took the opportunity to clean up the package reference anyway with commit 1f3d70d.

The second is just a submodule update of my custom version of etoViewport that got my XamMac build back up and running after some problems, but I've come to realize I might just be hiding other issues, and I don't want to bring over any of those changes until I sort out what's going on. Currently Eto.Veldrid doesn't even have a XamMac version, and in the past couple hours of trying to put one together I've been reminded how much I absolutely despise working with Xamarin.Mac; nothing but problems, compile errors, it's a disaster I'm still working through. Once I get it handled I'll add an Eto.Veldrid.XamMac project, but I can't promise when I'll crack that one.

Finally, that third commit is about my use of a customized OpenTK build. Currently, OpenTK 3.0.1 has a bug preventing RenderDoc from capturing OpenGL, so debugging is that much more difficult. Previously the OpenTK team had said they wouldn't be accepting any further bug fixes for the 3.0 series, so I thought the only way to get RenderDoc working was to make my own fork of OpenTK containing the fix I was after. I did that, but after putting it on NuGet was asked by one of the developers not to do so, in the interest of not confusing users. I completely understand the reasoning, and he in fact suggested I instead submit a pull request with the change, since they've reversed course on the 3.0 branch and are now accepting changes in anticipation of a possible final 3.X release. I did that, it was merged, and although no releases of OpenTK beyond 3.0.1 are yet available, I look forward to it happening eventually. As such I'd rather not switch Eto.Veldrid to use my customized OpenTK fork, so as to keep as many people as possible using the official codebase, reducing the support burden for both them and myself. Keep in mind that even with 3.0.1, RenderDoc can capture Eto.Veldrid's use of Vulkan and Direct3D just fine, it's only the OpenTK/OpenGL backend that presents a problem.