If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

TextureForwarder implementations sometimes do not return the proper layers backend

RESOLVED DUPLICATE of bug 1281456

Status

()

Core
Graphics: Layers
P3
normal
RESOLVED DUPLICATE of bug 1281456
a year ago
7 months ago

People

(Reporter: nical, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

(Reporter)

Description

a year ago
There are patches in flight affecting this in various bugs I don't have a clear map of which of them have landed already so this bug might be redundant/obsolete, but:

TextureForwarder in current mozilla-central contains the TextureFactoryIdentifier which has default member values (in the case of the layers backend, it is LAYERS_NONE.

Some TextureForwarder implementations, such as CompositorBridgeChild do not set their texture factory identifier. The forwarder then gets used and returns LAYERS_NONE in various places, which should never happen. One of these places ShmemTextureData::CreateSimilar (the forwarder is a CompositorBridge child and it returns the wrong layers backend). I suspect there are other places.

Either the texture has to hold references to both the TextureForwader and something that knows the compositor backend, or the TextureForwarder should be made to reliably return the proper backend instead of LAYERS_NONE.

Matt, you are in the process of fixing the busted inheritance graph of the forwarder business, is this part of the equation?
In particular, is the plan to make it so the TextureForwarder is enough to create the texture (so it has a valid TextureFactoryIdentifier)?

Not so long ago the texture was always pointing to the ShadowLayersForwarder which has the correct textureFactoryIdentifier (TextureForwarder did not have the identifier), and the TextureForwarder methods in ShadowLayersForwarder were dispatched to the managing CompositorBridgeChild. I don't remember what changed this (I should because I probably reviewed it).
Yeah, my patches (up for review) will fix this.

The idea is that being able to allocate textures (TextureForwarder) and having a TextureFactoryIdentifier (KnowsCompositor) are separate interfaces, and each concrete class will only implement the ones that it actually can do.
Has STR: --- → irrelevant
OS: Unspecified → All
Priority: -- → P3
Hardware: Unspecified → All
Whiteboard: [gfx-noted]
Can this be duped off bug 1281456 or bug 1303897?
(Reporter)

Updated

7 months ago
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1281456
You need to log in before you can comment on or make changes to this bug.