Currently CanvasClient relies on synchronous layer transactions to avoid copying the canvas in a texture that the compositor is currently using. Now that TextureReadLock works with all layer types we can use it to make sure that the canvas does not overwrite data that the compositor is reading. The tradeoff is: if we are over-producing, we may allocate more textures, but we'll be able to render faster since we don't cause the transaction to be synchronous. Synchronous transactions are quite expensive because the main thread wastes time doing nothing until the compositor has received the transaction and uploaded all textures. In particular, canvas games or animations may benefit from this since they tend to cause a lot of main thread activity.
Created attachment 8775555 [details] [diff] [review] Use a ReadLock instead of sync transactions. This patch only makes a difference if PersistentBufferProviderShared is disabled, I hope to enable it soon in most configurations, but in the mean time this optimization is simple enough to be worth taking.
Assignee: nobody → nical.bugzilla
Attachment #8775555 - Flags: review?(sotaro.ikeda.g)
Attachment #8775555 - Flags: review?(sotaro.ikeda.g) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/67cb195b1b45 Make canvas layer transactions asynchronous. r=sotaro
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/b498c2f4fdd8 for canvas failures like https://treeherder.mozilla.org/logviewer.html#?job_id=32818862&repo=mozilla-inbound
The failures were caused by bug 1289816.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/e46e53dfb22b Make canvas layer transactions asynchronous. r=sotaro
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox50: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in before you can comment on or make changes to this bug.