Bug 58053

Summary: Investigate using surface sharing to speed up accelerated compositing in WebKit2 on Windows
Product: WebKit Reporter: Adam Roben (:aroben) <aroben>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: andersca, cmarrin, roger_fong, simon.fraser, thorton
Priority: P2 Keywords: InRadar, PlatformOnly
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows 7   

Description Adam Roben (:aroben) 2011-04-07 09:56:21 PDT
Accelerated compositing in WebKit2 on Windows currently reads every rendered frame back into system memory before sending it over to the UI process. This is quite inefficient. It would be much better if we could share a surface between the web and UI processes so that we wouldn't have to read each frame back into system memory.
Comment 1 Adam Roben (:aroben) 2011-04-07 09:56:58 PDT
Direct3D9Ex and Direct3D10+ have support for surface sharing. See <http://msdn.microsoft.com/en-us/library/ee913554(v=vs.85).aspx>.
Comment 2 Adam Roben (:aroben) 2011-04-07 10:00:15 PDT
<rdar://problem/9249836>
Comment 3 Adam Roben (:aroben) 2012-07-05 20:24:13 PDT
(In reply to comment #0)
> Accelerated compositing in WebKit2 on Windows currently reads every rendered frame back into system memory before sending it over to the UI process. This is quite inefficient.

This is no longer accurate. There is no now readback into system memory. The web process creates an HWND and renders directly into it using Direct3D.

It is possible that surface sharing would still provide some benefits. Having the web process create an HWND gives us a cross-process window hierarchy, which is susceptible to deadlocks due to synchronous window messages sent by Windows from the UI process to the web process. Maybe surface sharing would allow us to get rid of the cross-process window hierarchy, which might in turn allow us to simplify some of our code.