1290081 - Use a TextureReadLock instead of immediate uploads + sync transactions in CanvasClient2D

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Nicolas Silva [:nical]]

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.

Comment 1

[Nicolas Silva [:nical]]

Attachment: 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.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/67cb195b1b45
Make canvas layer transactions asynchronous. r=sotaro

Comment 3

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 4

[Nicolas Silva [:nical]]

The failures were caused by bug 1289816.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e46e53dfb22b
Make canvas layer transactions asynchronous. r=sotaro

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e46e53dfb22b