[wpe-webkit] Backend objects for multiple WebViews

[Ryan Walklin]

Hi Adrian,

Thanks for the reply.

On Wed, 5 Jun 2019, at 11:23 PM, Adrian Perez de Castro wrote:

> What I have done myself is issue the calls to “_dispatch_frame_complete()”
> at intervals (for example, once every three seconds) to make sure all keep
> running normally for Web views which are not being displayed. While it is
> not strictly needed to keep JavaScript running in most cases, it comes to
> my mind that for example “requestAnimationFrame()” is tied to frame
> synchronization; therefore it is probably a good idea to report frame
> completion every now and then.

Makes sense, thanks.

> Note that you can use change the WPE backend's “activity state” [1] to add
> or remove the “wpe_view_activity_state_visible” flag to provide hints to WPE
> WebKit. IIUC at the moment this does *not* stop dispatching of new frames
> through the WPE backend right now, but there are plans to implement that—at
> which point throttling calls to “_dispatch_frame_completed()” will not be
> needed anymore.

Cool, seems like that's easy enough to implement in anticipation anyway.

> Rendering to subsurfaces is known to work. Probably the most straightforward
> achieving that is to use the “.export_buffer_resource” callback, which makes
> the FDO backend give you a “wl_resource” with a buffer, and in the callback
> use “eglCreateImageKHR()” + “eglCreateWaylandBufferFromImageWL()” to turn it
> into a “wl_buffer” which finally you can use with “wl_surface_attach()” on
> the subsurface. You will also want to add a callback on the “wl_buffer” to
> know when the compositor has committed it, which is a good location to call
> “wpe_view_backend_exportable_fdo_dispatch_release_buffer()”.

Great, that makes perfect sense. I've been using the exportable_egl API for a single view directly to a wl_surface as Cog does and wasn't quite sure how to make that work with multiple views, but of course it makes no sense to upload 10 view frames to the GPU if you're only rendering one. I assume the wl_buffers are in system RAM. 

Hopefully in some bright future we're doing all our text and SVG rendering on the GPU and using a HW compositor to actually lay out the page ;) but that seems like an ideal architecture in the meantime ;). 

> (Let me know if you run into trouble or have doubts, I wrote the above
> quickly and the explanation might be a bit too terse.)

No that's perfect, exactly the pieces I was missing!

Regards, 

Ryan