[Webkit-unassigned] [Bug 231148] New: Capability to duplicate WKWebView to multiple views

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=231148

            Bug ID: 231148
           Summary: Capability to duplicate WKWebView to multiple views
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: dsaunders45459 at gmail.com
                CC: kkinnunen at apple.com

We have scenarios that require the same web content (WKWebView) to be rendered in multiple windows of the same Mac application simultaneously, and synchronized rendering of that content between the windows with high fidelity. The aspect ratio for the web content will be the same in all views, but the scale could be different. We don't own all of the web content, so we cannot utilize state synchronization JavaScript libraries with multiple instances of WKWebView.  Some of the web content may be hardware accelerated, including videos. The user also needs to be able to interact with the web content in all windows, and for it to be capable of being accessible through VoiceOver navigation.

With Chromium we can achieve these multiple view scenarios because Chromium browser supports off-screen rendering. At a high level, Chromium is rendering from the web content process to an IOSurface that can share hardware-accelerated buffer data across multiple processes. Chromium also gives control for the application to subscribe to changes in the pixel buffer, and render the content to multiple views in the application. Some applications have even rendered Chromium web content to an OpenGL texture with custom transforms to include in a visualizer application.

For our scenario the highest priority is to have a duplicate view into the web content, with real-time synchronization. Having direct access to the pixel buffer would allow for more flexibility, but providing a new API to give a duplicate NSView for a WKWebView instance could be sufficient as long as it also allows user to interact with the content, and provide proper accessibility.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211003/159231fe/attachment.htm>