1289105 - Don't use PersistentBufferProviderShared with BasicCompositor.

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Nicolas Silva [:nical]]

...Or more precisely, when the FrameLayerBuilder/nsDisplayList consider that compositing is not "cheap". In this case the canvas will most of the time be flattened into the content layer underneath (which amounts to compositing canvas on the content thread rather than the compositor). Since the canvas does not have it's own layer sent to the compositor, drawing in a shared texture is a waste.
Beyond the performance issue, PersistentBufferProviderShared is glitchy in some cases when these layers heuristics kick in. I am still trying to figure out why, probably something related to snapshots. The code was certainly not designed to be used that way.

Comment 1

[Nicolas Silva [:nical]]

Attachment: Don't use PersistentBufferProviderShared if !IsCompositingCheap()

Comment 2

[Jamie Nicol [:jnicol]]

Comment on attachment 8774301 [details] [diff] [review]
Don't use PersistentBufferProviderShared if !IsCompositingCheap()

Review of attachment 8774301 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/client/ClientLayerManager.cpp
@@ +849,5 @@
>  ClientLayerManager::CreatePersistentBufferProvider(const gfx::IntSize& aSize,
>                                                     gfx::SurfaceFormat aFormat)
>  {
> +  // Don't use a shared buffer provider if compositing is considered "not cheap"
> +  // because teh canvas will most likely be flattened into a thebes layer instead

typo ("the" instead of "teh")

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/64900003b7cc
Don't use use PersistentBufferProviderShared if the canvas layer is unlikely to be chared with the compositor process. r=jnicol

Comment 4

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

https://hg.mozilla.org/mozilla-central/rev/64900003b7cc