Re: Gtk+4.x and broadway ( and other remote options )

[Brion Vibber <brion pobox com>]

On Tue, Dec 6, 2016 at 8:00 PM, Fan, Chun-wei via gtk-devel-list <gtk-devel-list gnome org> wrote:

Specifically what this means is that there isn’t OpenGL support in it (we need OS/platform-level support for OpenGL for creating and switching (making current) OpenGL contexts), which likely needs to be done with WebGL, which most probably needs to be done in the .js file in the broadway subdir in gdk/.  GTK+-4.x is going to switch to GL drawing, at least for the majority of the various components, which makes OpenGL support a requirement.

 

AFAIK, the backends that have the needed support are x11, Wayland, mir and Windows.

 

If you know how to do initialize OpenGL in WebGL (ie _javascript_), please let the people know here, as this is what I think is mainly what needed for Broadway to stay.

WebGL is roughly equivalent to a _javascript_ API for OpenGL ES 2 (not full OpenGL). Since it runs on the remote browser side, not in-process with the app, I believe you'd need support in the local (app-side) OpenGL driver to get the GL calls made in the app to actually talk to the web page.

I think there are two main possibilities:

1) Remote the OpenGL commands over the network to JS running in the Broadway renderer's HTML page, assuming that quasi-OpenGL ES 2 is enough to do GTK+'s rendering (or that any necessary bits can be emulated in WebGL).

This may require replacing the OpenGL library provider with a custom one, or digging around in Mesa3d to provide a suitable driver.

2) Use local headless GL rendering with default software or native GPU rendering, with some way to push on-screen bitmap updates as efficiently as possible over the network.

For native GPU, may require suitable permissions to access the kernel drivers.

I'm not sure how easy either is, though both should be possible.

-- brion