Hello,
right now, it's very hard to integrate flutter with DRM hardware planes, i.e. get the flutter engine to render each flutter layer into its own hardware-composited DRM plane. It's not impossible, it seems, but it's very hacky and basically requires you to implement your own double buffering.

It'd be much easier if I could get the engine to just render each flutter layer into its own drawing surface (EGLSurface).

The way it works right now

Right now I'm using FBOs as "pseudo"-offscreen render targets. Each FBO has a renderbuffer as a color attachment that is actually an EGLImage. That EGLImage was created using the EGL_MESA_drm_image extension and has a drm fb associated with it that can be scanned out.

If you want it to be double buffered, you'd need to create two renderbuffers per FBO and swap the fbo-attached renderbuffer after eglSwapBuffers.

Use case

Easier / better hardware composition for embedders. For example, this allows me to use omxplayer as a video_player implementation on the Raspberry Pi, which is way faster than using textures to display the video.

Proposal

• add a new FlutterOpenGLTargetType, maybe kFlutterOpenGLTargetTypeSurface.
• add a new struct FlutterOpenGLSurface that has an opaque handle to be used by user-defined callbacks inside it.
• add this struct to the union inside FlutterOpenGLBackingStore
• add a new (or modify existing) callback to be called on the rendering thread that takes the mentioned opaque handle and makes the associated surface (and some rendering context) current.

FlutterOpenGLSurface could look like this:

typedef struct {
  void *user_data;
} FlutterOpenGLSurface;

The whole thing doesn't even need to have the Surface name in it, for example kFlutterOpenGLTargetTypeSurface could also be called kFlutterOpenGLTargetTypeGenericCallback, since (I think) surfaces are an EGL-thing and the user could do anything they want inside that callback, not just making a surface current.