Open MarijnS95 opened 3 weeks ago
@kchibisov you removing the ?
from this title counts as a "yes, it's okay to add an Image
wrapper to the EGL backend" answer?
If so, I'll open a PR with what I've been writing thus far.
I don't see why not, if there's a EGL api that could be wrapped, then I don't see why shouldn't we.
After adding a DRM example in #1691 I've on-and-off been using raw DRM as a base to allocate and present/flip GBM images (
gbm_bo
) by creating agbm_surface
(some sort of swapchain containing multiplegbm_bo
's) that one can import into anEGLSurface
(already supported inglutin
), and oncesurface.swap_buffers()
is called after rendering a newgbm_surface::lock_front_buffer()
becomes available to flip to DRM (or to give to a compositor?) [^1].[^1]: I'd like to submit these as extra
glutin_examples
at some point.However, OpenGL via EGL also support rendering to individual
gbm_bo
s, by importing them into anEGLImage
viaEGL_KHR_image_pixmap
(iirc resummarized inEGL_KHR_image
), and subsequently binding that to a new framebuffer viaOES_EGL_image
.I've written some code to test this out successfully, and would like to ask before stuffing this into a PR: should we add an
EGLImage
representation toglutin
's EGL backend (even though the code can already be written in "user code" againstegl_display.raw_display()
andegl_display.egl()
)? Furthermore, is there a similarity in other context APIs?Note that
eglCreateImage()
can also be used to createEGLImage
s from/for variousGL_TEXTURE_...
, if I read it correctly.