Allow using OpenGL ES3 with Angle and extract a Direct3D shared handle

[l3m]

This is an updated version of #234

As discussed in the previous prq and in chat with @Frassle, this version avoids using a specific offscreen rendering instance for Angle. Instead, the angle window info and the angle factory use an internal platform-window or platform-factory.

As shown in my wpf-gles demo here, a user can instantiate an angle window and the OpenTK graphics context as follows:

          int major = 3;
          int minor = 0;
          var flags = GraphicsContextFlags.AngleDirect3D11 | GraphicsContextFlags.Embedded;

          // create platform window
          var win = OpenTK.Platform.Utilities.CreateWindowsWindowInfo(_control.Handle);
          // create angle window
          _window_info = OpenTK.Platform.Utilities.CreateAngleWindowInfo(win);
          // create GraphicsContext as usual
          _context = new GraphicsContext(mode, _window_info, major, minor, flags);

Additional surfaces for offscreen rendering can be created and destroyed on IAngleWindowInfo, and the underlying surface pointer can be queried there as well. As the EGLDisplay is not otherwise exposed to the user, this seems to right place to do it.

[l3m]

Any chance this will get merged? Are there any other changes you would want me to do to get it merge-ready?

[Frassle]

Just haven't had a chance to look through it properly. Still feel the offscreen stuff needs to be exposed in a less angle specific way. This really needs others to give some input to work out how best to handle this.

[l3m]

Updated and rebased my prq on the latest develop.

I would be really happy if I could get some pointers on what to do to get this accepted.

We're using custom-built NuGet packages for a way too long now based on my branch, and while it runs well, I would prefer to be able to return to OpenTK baseline at some point...

[cpages]

Would it be possible to revive/review this pr? I'm also interested in the copy-less approach that this patch provides for wpf apps.

@l3m do you think this is still a valid approach or you have a better solution?

[l3m]

@cpages Well, I no longer work on this project, but it's in use since shortly after the original prq and it works well. ANGLE is a special case and therefore I feel it warrants treating it a bit differently, but I would be happy if someone could fix whatever issues people have with it that blocks it from being accepted.

Unfortunately, I won't have time for this, as I'm no longer at the company (moved on to greener pastures :)). Maybe @mzanin could take that over? Everyone would profit if this functionality made it into OpenTK mainline.

[varon]

@cpages It should be pretty simple to migrate this PR over to the new source organization, not much has changed in the actual code files if you want to give it a bash.

As a disclaimer, I'd need a maintainer who's familiar with GLControl to give a thumbs up before we can merge, too.

[wcdeich4]

Um - please forgive a dumb question as I have been busy @ work - but I just looked at code on https://github.com/opentk/opentk and the OpenTK.GLControl is still there......?

[varon]

Yes, but it's all been moved. Scroll down to where we merge and look at the 'conflicting files'.

[wcdeich4]

@varon - so then, they could access glControl, but they'd have to change the part of their code that calls it?

[wcdeich4]

BTW, @Frassle had a point about doing things in a more angle-non-specific way. Usually you specify what angle you want when you setup the camera.

[l3m]

@wcdeich4 ANGLE (Almost Native Graphics Layer Engine) is a google OpenGL ES toolkit, see https://github.com/google/angle. It efficiently maps OpenGL ES calls to other GLs (DirectX9/11, OpenGL), which means you can use GLES rendering on windows machines without recent graphics drivers or with drivers where Open GL support is lacking or broken.

[wcdeich4]

@l3m - I just looked at it. Is that native/un-managed C++ ?

[mzanin]

I rebased this on the develop branch just now without any major difficulty and it still appears to work as intended. The MakeCurrent call was removed from the EglContext constructor so I just needed to change the usage to call that explicitly. I can do a new pull request once this one is closed.

[l3m]

Closing this as @mzanin will open a new PRQ with the rebased version.

[JimSEOW]

@l3m
I am looking for suggestions on how to replace OpenTK.GLControl based on System.Windows.Forms.UserControl to e.g. UWP: Windows.UI.Xaml.Controls.UserControl

There is solution to use (OpenGL ES) Angle for UWP XAML (e.g. Windows.UI.Xaml.Controls.UserControl)

I am seeking suggestions on how to bring (OpenGL) e.g. OpenTKCore to UWP XAML (e.g. Windows.UI.Xaml.Controls.UserControl)

We already have .NET Core Systems.Drawing. We just need to replace the Form.UserControl to UWP's UserControl

I hope there is already users here thinking along this line.