glutin icon indicating copy to clipboard operation
glutin copied to clipboard

Add extra EGL extensions

Open chrisduerr opened this issue 1 year ago • 2 comments

This patch adds multiple new EGL extensions which are useful for implementing Wayland applications. These have been mostly implemented manually, since gl_generator lacks support for these newer EGL extensions (except for EGL_KHR_image_base).

The following extensions were added:

  • EGL_KHR_image_base
  • EGL_WL_bind_wayland_display
  • EGL_WL_create_wayland_buffer_from_image

Currently this PR doesn't really implement a good way to access this new functionality, instead it just exposes the EGL static publicly. Ideally there would be some abstraction that retrieves the Egl object, while automatically making sure it is initialized.

So I see two options, feedback appreciated:

  • Expose method that basically just does EGL.as_ref()? (does not ensure initialization)
  • Add method to Display (requires display creation)

chrisduerr avatar Mar 06 '24 00:03 chrisduerr

Fwiw for #1658 I'd also like to use updated EGL bindings from gl_generator, which is very trivial to achieve: https://github.com/brendanzab/gl-rs/pull/546

Unfortunately it seems that efforts to transition ownership of gl-rs (which is still an important cornerstone in the Rust ecosystem) have stalled: https://github.com/brendanzab/gl-rs/issues/524

MarijnS95 avatar Mar 06 '24 09:03 MarijnS95

I'm not sure how we should expose the ref to EGL and similar types, since we should have it for all the platforms where we use loader (so, except macOS).

Maybe we should have a method to manually load(which will return Option) and just a method to get a &'static Egl from the Display(this will always work)? And the manual loading will be present only for EGL, because the rest is a bit special and shouldn't be used anyway in the context of device extensions.

I'm also interested in solving the generator issue upstream, but I'll see what we can do

kchibisov avatar Mar 09 '24 18:03 kchibisov

I added some functions to access the APIs for EGL and GLX. This works for my usecase at least, so maybe that's enough to just merge it?

Let me know if you want a cleaner/more elaborate solution.

chrisduerr avatar Apr 28 '24 15:04 chrisduerr

For completeness, since I mentioned updating EGL headers in gl-generator above, here's a branch showcasing that everything is still there when generated with a newer generator:

https://github.com/MarijnS95/glutin/compare/gl-generator-update

MarijnS95 avatar Jun 07 '24 19:06 MarijnS95