Bug 1629788 Comment 13 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

It would be good to have a fast upload path from ffmpeg to WebRender like Windows has. Improvements for legacy X11 should only be a byproduct of the Wayland work, for better long-term maintenance. As my "knowledge" is restricted to Bugzilla I only assume(d) DMABUF is the desired solution for cross-process sharing.

bug 1129492 comment 24: "Remove X11 connections from content processes in all cases, for security"
It seems X11 Pixmaps must be avoided for sandbox hardening, even if that means Mesa users get the zero-copy dmabuf improvement while proprietary Nvidia sticks by its own wish (corporate policy) to status quo by not supporting it. Firefox as open-source project with much idealistic unpaid labor should have its primary focus on getting the best experience with open-source Mesa.
If I haven't misunderstood recent chat und bugzilla conversations, X11 connections are the top security problem on Linux as they allow further desktop access, so that only WebRender should be allowed to have one. Therefore, there is additional pressure to get WebGL remoting done (bug 1638466). That's why it seemed so sad Rinat didn't ask ealier because his [X11 VAAPI prototype](https://github.com/i-rinat/firefox/commit/73ee73df4e09ff0a5cfd6c30d92d6070fe722c21) is based on X11 Pixmaps, but the DMABUF code path should be used on X11 as well. However, it might help you with bug 1619882 as it demonstrates `TextureClientRecycleAllocator` usage, which is used by [Windows' fast upload path](https://searchfox.org/mozilla-central/search?q=TextureClientRecycleAllocator&path=D3D&case=false&regexp=false). Windows actually has two upload paths to WebRender ([RenderDXGITextureHostOGL + RenderDXGIYCbCrTextureHostOGL](https://searchfox.org/mozilla-central/search?q=NativeTextureToWrExternalImage&path=)). 

WebRender's [Native ExternalImage seems to expect YUV](https://github.com/servo/webrender/blob/master/examples/yuv.rs), conversion to RGB before handling over to WebRender seems unneccessary.
bug 1493198 added HDR YUV image support to WebRender and Windows' fast upload path.
Btw, jbonisteel wrote in chat last friday: "some Intel folks are interested in making HDR happen in Firefox"

https://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/omap-dmabuf-gstcon2012.pdf
> With wl_drm protocol, we can push YUV buffers directly to server

Pages 26 (X11) and 27 (Wayland) look nearly identical. I don't know if dri2video is a desired option for X11 or if it was only a prototype.
It's totally fine if only Wayland gets certain improvements.
It would be good to have a fast upload path from ffmpeg to WebRender like Windows has. Improvements for legacy X11 should only be a byproduct of the Wayland work, for better long-term maintenance. As my "knowledge" is restricted to Bugzilla I only assume(d) DMABUF is the desired solution for cross-process sharing.

bug 1129492 comment 24: "Remove X11 connections from content processes in all cases, for security"
It seems X11 Pixmaps must be avoided for sandbox hardening, even if that means Mesa users get the zero-copy dmabuf improvement while proprietary Nvidia sticks by its own wish (corporate policy) to status quo by not supporting it. Firefox as open-source project with much idealistic unpaid labor should have its primary focus on getting the best experience with open-source Mesa.
If I haven't misunderstood recent chat und bugzilla conversations, X11 connections are the top security problem on Linux as they allow further desktop access, so that only WebRender should be allowed to have one. Therefore, there is additional pressure to get WebGL remoting done (bug 1638466). That's why it seemed so sad Rinat didn't ask ealier because his [X11 VAAPI prototype](https://github.com/i-rinat/firefox/commit/73ee73df4e09ff0a5cfd6c30d92d6070fe722c21) is based on X11 Pixmaps, but the DMABUF code path should be used on X11 as well. However, it might help you with bug 1619882 as it demonstrates `TextureClientRecycleAllocator` usage, which is used by [Windows' fast upload path](https://searchfox.org/mozilla-central/search?q=TextureClientRecycleAllocator&path=D3D&case=false&regexp=false). Windows actually has two upload paths to WebRender ([RenderDXGITextureHostOGL + RenderDXGIYCbCrTextureHostOGL](https://searchfox.org/mozilla-central/search?q=NativeTextureToWrExternalImage&path=)). 

WebRender's [Native ExternalImage seems to expect YUV](https://github.com/servo/webrender/blob/master/examples/yuv.rs), conversion to RGB before handing over to WebRender seems unneccessary.
bug 1493198 added HDR YUV image support to WebRender and Windows' fast upload path.
Btw, jbonisteel wrote in chat last friday: "some Intel folks are interested in making HDR happen in Firefox"

https://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/omap-dmabuf-gstcon2012.pdf
> With wl_drm protocol, we can push YUV buffers directly to server

Pages 26 (X11) and 27 (Wayland) look nearly identical. I don't know if dri2video is a desired option for X11 or if it was only a prototype.
It's totally fine if only Wayland gets certain improvements.

Back to Bug 1629788 Comment 13