Bug 69850 – Enable out-of-thread compositing in WebKit compositor API

• Component: New Bugs
• Status: RESOLVED FIXED

[Antoine Labour]

Enable out-of-thread compositing in WebKit compositor API

[Antoine Labour]

Created attachment 110536 [details]
Patch

[Antoine Labour]

It needs https://bugs.webkit.org/show_bug.cgi?id=69048 to work correctly if the client thread is not the main thread.

[Antoine Labour]

Ping ?

[James Robinson]

I don't understand this patch.  Why would users of the WK API want to use the threaded path?

[Nat Duca]

(In reply to comment #4)
> I don't understand this patch.  Why would users of the WK API want to use the threaded path?

This makes sense to me. This reduces complexity --- either thread is in use or its not. Rather than "oh, its in use by the renderer compositor but if you're talking about the browser compositor, well thats a different story." Sorry, but ew.

[Antoine Labour]

We're already seeing the browser UI thread limited by painting in certain conditions. We could gain parallelism by moving the rendering to a separate thread.
We'll also want to be able to drive animations from the compositor thread.

Also, it works. So why not?

[James Robinson]

All valid points - I just wasn't really sure what the goal was.  I agree being able to do animations, etc will be pretty sweet once we get that rolling.

[James Robinson]

Comment on attachment 110536 [details]
Patch

R=me but there's still something a bit amiss here.  Right now there are 2 ways to indicate threading support via the WK API - you can set the appropriate CCSettings value and call WebCompositor::setThread(). If you do the former but not the latter you hit ASSERT()s and crash today.  I think we want to just make the latter be the control - if you pass a thread to WebCompositor::setThread() then the compositor uses it, otherwise it runs single-threaded.

Does that sound like a good plan going forward, Nat?  To be clear I think this patch is fine to land - we can clean things up later.

[WebKit Review Bot]

Comment on attachment 110536 [details]
Patch

Rejecting attachment 110536 [details] from commit-queue.

[e-mail] does not have committer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py.

- If you do not have committer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags.

- If you have committer rights please correct the error in Tools/Scripts/webkitpy/common/config/committers.py by adding yourself to the file (no review needed).  The commit-queue restarts itself every 2 hours.  After restart the commit-queue will correctly respect your committer rights.

[Nat Duca]

Yeah, I like it. Saying back what I heard, its "do away with the CCSettings field for threaded compositing and derive this entirely from whether CCThread was handed a thread."

[WebKit Review Bot]

Comment on attachment 110536 [details]
Patch

Clearing flags on attachment: 110536

Committed r97795: <http://trac.webkit.org/changeset/97795>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.