Closed Bug 1290081 Opened 4 years ago Closed 4 years ago
Use a Texture
Read Lock instead of immediate uploads + sync transactions in Canvas Client2D
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.
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
You need to log in before you can comment on or make changes to this bug.