~eliasnaur/gio#26:
OpenGL Widget

Would be nice to support embedding an OpenGL context somehow. Maybe a way to support lower-level opengl access could be to make it a layout-able widget (like drawing a rectangle), which defines an opengl context.

Status
REPORTED
Submitter
~paulbellamy
Assigned to
No-one
Submitted
2 months ago
Updated
2 months ago
Labels
No labels applied.

~eliasnaur 2 months ago

Would be nice to support embedding an OpenGL context somehow. Maybe a way to support lower-level opengl access could be to make it a layout-able widget (like drawing a rectangle), which defines an opengl context.

Gio will at some point need to run on other GPU APIs such as Vulkan, which will then make OpenGL-using Gio programs less portable.

I see several ways you could get access to a lower level drawing context without exposing directly from Gio:

  • Make the Gio drawing area transparent and place another native OpenGL view under it. This is also the way you would embed heavy widgets such as Google Maps.
  • Provide a way to output drawing commands from Gio. Instead of doing a app.Window.Update(ops), you would then have a way to translate Gio drawing operations to OpenGL, Vulkan etc. commands. I believe this is how Dear ImGUI works.

~mvdan 2 months ago

In the long term, wouldn't simply supporting Vulkan be very portable? Even on OSX these days, one could use MoltenVK to get it working there, and Windows/Linux/Android machines generally ship with Vulkan support today.

~eliasnaur 2 months ago

In the long term, wouldn't simply supporting Vulkan be very portable? Even on OSX these days, one could use MoltenVK to get it working there, and Windows/Linux/Android machines generally ship with Vulkan support today.

It's indeed my naive hope that Vulkan is enough for all modern platforms, with OpenGL ES as fallback for older systems.

However, I still think exposing a low level graphics API would be a mistake. Even if we did expose a graphics context, how do we avoid the app and Gio stepping on each other's toes? Multiple contexts seems more clean and better for the long term.

That's not to say we can't expose a limited form of API to the graphics API. For example, I'd like to expose shaders in some form so that you can write arbitrary materials in Gio.

~paulbellamy 2 months ago

Makes sense, thanks. My immediate use case is to render a camera-preview on iOS/Android, so will use the transparent under-layer you suggested. Thanks!

~eliasnaur 2 months ago

On Mon, Aug 26, 2019 at 8:58 AM ~paulbellamy outgoing@sr.ht wrote:

Makes sense, thanks. My immediate use case is to render a camera-preview on iOS/Android

I see. A camera preview is much easier than the whole of OpenGL. And even with OpenGL available, you still need a way to connect the camera to a texture.

Supporting, say, a camera.PreviewOp is on my list of ideas.

will use the transparent under-layer you suggested.

Note rendering Gio in a transparent view is not yet supported.

~joeblew99 2 months ago

I also wanted the ability to access the camera. The use case is to build a webrtc app using the pion golang lib.

This of course raises the issue of native plugins in that the WASM version will be different from the iOS and Android version. Even opening a file / folder picker dialogue varies per OS.

But golangs ability to use build tags and system calls should not make it too bad.

Register here or Log in to comment, or comment via email.