forked from chromium/chromium
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Remove cc::BlockingTaskRunner and cc::ReleaseCallbackImpl
BlockingTaskRunner was introduced in order for resources released by a commit to be returned from the impl thread back to the main thread (ie have the main thread ReleaseCallback run) before the commit ended. This allowed cc clients to reuse textures immediately upon commit ending, allowing for less buffering. With the implementation of delgated compositing, the value of BlockingTaskRunner disppeared. Now the cases where the impl thread has a reference to return to the main thread during commit are very few. The only one that appeared in cc unittests was: - Make a layer undrawable (sized 0x0) - Set a mailbox, commit - Remove the layer from the tree, dropping the impl thread ref. - Expect to see mailbox returned inside the commit that removes the layer from the tree. Another case would be a texture layer which is not part of the on-screen frame. But as soon as the layer became visible, committing a mailbox would mean by the time the next commit happend, the mailbox has been sent to the display compositor and *can't* be returned. If unused in the next frame, the display compositor will return it async outside of commit, and we'll forward it to the main thread. So the main thread always needs extra buffering for on-screen texture layers now. By removing the complexity introduced by BlockingTaskRunner we will make a cc client animating a texture layer outside the viewport require extra an extra texture of buffering, just as it would need once it's in the viewport. So the memory overhead shouldn't be impactful - offscreen clients shouldn't be animating textures, and we'd need to allocate another texture as soon as they became visible anyway. Another concern is that on shutdown/removal from the tree, the resources should all be returned before the commit ends, so the client can destroy its own structures immediately. This is no longer the case with delegated rendering and any clients depending on this have already been leaking in the common case (layer on screen, and can be drawn). Removing this class will greatly simplify the effort to split ResourceProvider into two classes - to service the layer and the display compositors separately, as there's no BlockingTaskRunner in DisplayResourceProvider anymoore, which was a layer-tree concept. R=piman@chromium.org Bug: 738190 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I5d9ffe70e245cdc763f6672c0e8c561f9992de0c Reviewed-on: https://chromium-review.googlesource.com/679481 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#504110}
- Loading branch information
Showing
42 changed files
with
270 additions
and
833 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.