4 ms·

WebKit2 behaves in the same way with regards to the points mentioned above. The sandboxed content process(es) are responsible for network, IO, layout, etc. The

WebKit2 behaves in the same way with regards to the points mentioned above. The sandboxed content process(es) are responsible for network, IO, layout, etc. The UI process (normally, the browser process) serves only as a broker for developer decision making and final drawing of the laid out content. See https://trac.webkit.org/wiki/WebKit2#ProcessArchitecture https://trac.webkit.org/wiki/WebKit2#ProcessArchitecture

greggman 10y ago
AFAIK WebKit2 does not use a separate process for graphics. Graphics calls go directly into whatever api is appropriate (CoreGraphics, OpenGL). Where as Chrome that's not the case, all OS/Driver level graphics happen in the GPU process. That means all data has to be shuttled from the process that wants to display the data to the GPU process. Even video for example gets decoded in a secure process (because there might be exploitable bugs in the codecs) then that data has to be shuttled to the GPU process so it can be composited with the page. The directives of compositing happen in the render process (the webpage) but eventually have to translated to graphics commands that happen in the GPU process. None of this is true in WebKit2 AFAIK and is one of the many reasons it has so many move code exploit bugs (15x actually for 2016).