[webkit-gtk] WebKit2GTK+ and compositing in the UIProcess

[zan at falconsigh.net]

On Wed, Dec 9, 2015, at 05:18 PM, Emanuele Aina wrote:
> I'm relaying a message from Daniel which is probably stuck in the
> unloved moderation queue.
> 
> ---------------------------------8<---------------------------------
> 
> > Do you have a pointer to the old nested compositor implementation?
> 
> I understand this implementation was implemented as a Weston shell
> plugin. Again, I kind of understand the attraction, but using a bare
> compositor which just does what Em described previously (cf. Weston's
> clients/nested.c example) is the approach we recommend, rather than
> carrying the unnecessary baggage of the whole of Weston itself.
> 
> Is there any particular reason for you to choose the Weston shell
> approach? Did you try the clients/nested.c approach? My understanding
> is that this is what was happening upstream ... :\
> 

The nested compositor approach (as done in clients/nested.c) is the
approach
that was used in WebKitGTK+ for the initial accelerated compositing
support
under Wayland (which never landed), and we're sticking with that.

The Weston shell approach that's now being mixed here was a wrong
approach
that the wk4wl port originally used for single-page display use cases.

> > > Skimming the eglCreateWaylandBufferFromImageWL implementation in
> > > Mesa, it appears this would use a dma-buf buffer wherever available
> > > anyway. [4]
> > 
> > I see.
> 
> Using a dmabuf is completely fine; it's how most platforms operate
> under the hood. Using GBM to allocate in the first place is much less
> fine, ranging from 'unusably slow' to 'doesn't even work at all'.
> 
> I'm more than happy to chat about this, either over email, or as
> daniels on IRC.
> 
> Cheers,
> Daniel
> 
> -- 
> Emanuele Aina
> www.collabora.com
> 
> 
> 
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk