[Webkit-unassigned] [Bug 147258] New: [GTK] Software-only basic compositing

[bugzilla-daemon at webkit.org]

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

            Bug ID: 147258
           Summary: [GTK] Software-only basic compositing
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P3
         Component: WebKit Gtk
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: emanuele.aina at collabora.com
                CC: mrobinson at webkit.org, zan at falconsigh.net

At the moment WebKit depends on OpenGL until bug 146511 gets fixed. Unfortunately, disabling OpenGL means disabling composition too.

On our old 2.4.1-based branch for the Raspberry Pi we had some features and some really ugly hacks in place to reduce memory copies as much as possible, since those where one of the most severe performance bottlenecks on a device with a rather slow memory bus: we enabled the Tiled Backing Store with a Cairo backend to improve scrolling responsiveness, and we punched some holes through several layers to make sure video frames get blit to screen directly, without hitting the backing store first.

Now that we're (finally!) moving to the modern world I'd like to get rid of such hacks: my very high level idea would be to have some form of restricted compositing where only rectangular, non-transformed, fully-opaque areas are promoted to layers. This way, compositing would roughly consist in a series of clipped memcpys on the windowing surface.

The main use-case I'd like to target is video playing: with our hacked up branch at the moment we're able to play 720p videos on the Pi 1 and I'd like to retain such ability while getting rid of the hacks. What currently slows things down is that without compositing each frame is copied to the backing store first and only then blit to windowing surface, doubling the amount of memcpy'ed data for each drawing loop.

Another use-case that would benefit from such sort of composition would be the scrolling of the vast majority of pages with position:fixed headers or sidebars.

Implementation-wise I started looking at reviving the TextureMapperImageBuffer that was removed in http://trac.webkit.org/changeset/183807 (see https://lists.webkit.org/pipermail/webkit-dev/2015-April/027384.html for some context).

I'm now a bit confused about which infrastructure I should use to develop such feature, in LayerTreeHost.cpp[1] there seems to be three choices: USE(COORDINATED_GRAPHICS_MULTIPROCESS), USE(COORDINATED_GRAPHICS_THREADED) and USE(TEXTURE_MAPPER_GL). LayerTreeHostGtk assumes GL, so I guess I  will need to add a software-only implementation. I'm not sure about the status of Coordinated Graphics and the GTK+ port: building with -DENABLE_THREADED_COMPOSITOR on my amd64 laptop failed due to a mismatch with the ThreadedCoordinatedLayerTreeHost::create() prototype. :/

I guess that Coordinated Graphics may be more interesting for me: it already has a Tiled Backing Store implementation and the prospect of being able to use the threaded compositor to use the four cores of the Pi 2 to render the layers is very interesting (we have a special multi-threading feature where we render to a Cairo recording surface and dispatch the real drawing to a thread pool for each tile).

Any guidance is appreciated! :)

[1] https://trac.webkit.org/browser/trunk/Source/WebKit2/WebProcess/WebPage/LayerTreeHost.cpp?rev=187332#L41

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150724/bceb06b0/attachment-0001.html>