Initial opentk4 support

[cwensley]

Initial Mac, Gtk, and Wpf support for OpenTK 4.x

WinForms is not done yet (there's no GLControl for OpenTK4), and WPF requires WGL_NV_DX_interop extension which I cannot test due to using windows in Parallels.

[ItEndsWithTens]

Same result here on my Windows 10 machine; I didn't tweak any project files, but the same message shows up when debugging the net5.0-windows build. Resizing the window makes the control go black, even if I set the control backcolor and the GL.ClearColor to something else. Setting breakpoints inside AttachEvent for the WPF handler shows the GLSurface events are never actually passed in as arguments, just MouseUp/Down/Move/Wheel and KeyDown.

The net48 build, using OpenTK 3, still works as expected in Windows, and the OpenTK 4 stuff seems to work fine on my Big Sur mini, so thankfully it does seem to be specific to WPF. I've tried uncommenting the code in the WPF test app to explicitly add the handler to the platform, but nothing seems to improve.

I'll keep poking around as best I can, for what it's worth.

[ItEndsWithTens]

Commit aaa73d2 looks like it does the trick as far as getting OpenGL up and running, and indeed it clears the viewport, replicating what I had experimented with yesterday. There now seems to be an issue with actually drawing, as grid lines and polygons are invisible, but that's the same thing I saw.

I suspect it's related to WGL_NV_DX_interop and the way it exposes D3D stuff to OpenGL, but I'm not an expert there, I've never worked with that extension before. From working with Veldrid I know there are differences in e.g. the clip space between OpenGL and Direct3D (right-handed vs. left-handed coordinates and a range of [-1,1] vs [0,1], respectively), and I imagine those and possibly others come into play when writing OpenTK code to work on top of this particular extension.

In any event, the actual act of getting rendering to function inside Eto seems to be working, so the rest with any luck will be changing the test program, not the actual control. Thanks for the update!

[philstopford]

I was coming to report and got beaten to the punch. Here's what I see in WPF testing. Events are firing, and no exceptions seem to be thrown, but the widget is gray.

[ItEndsWithTens]

Ah, yes, forgot about that detail: the control doesn't actually render until you resize the window. Not sure yet what a resize triggers that activates it, but that's currently necessary before you see anything. Beyond that, the test app's OVPSettings class defaults to a white 'backColor', which gets used for the GL clear color, so even after a resize you'll just see white (until the aforementioned drawing issues are sorted out).

[cwensley]

Thanks for the (insanely) quick test! I've updated a few more things to see if things work.

@philstopford could you test this on linux with your Nvidia card? I want to know if things are working correctly as it may help with the Veldrid issues.

[philstopford]

@cwensley : GTK (Ubuntu Groovy, nVidia 1080 with 460 series drivers) shows a color cycling display in the viewport with that set of changes. No need to resize for the viewport to show up and it respects resizing of the window as well. Not tried any other platform yet - tested with dotnet 5.0.3 on that platform.

[philstopford]

Uncertain why the other modes don't work, though. Still issues elsewhere to address or the test is defective somehow?

[cwensley]

My current guess is that it shouldn't be calling MakeCurrent() during the OnDraw event... in which case is not difficult to protect against so that if it is called, we just simply don't do anything..

[cwensley]

Another issue might be something to do with using VBO..

[philstopford]

@cwensley : WPF also looks fine under intel and nVidia with this updated PR. The non-simple viewports all work (unlike under GTK). The non-simple viewports are blank initially until a refresh (e.g. move a splitter, resize the window, or click-and-drag to pan the view)

[philstopford]

Just curious about the status of this PR