Closed Bug 1305426 Opened 8 years ago Closed 8 years ago

TextureForwarder implementations sometimes do not return the proper layers backend

Categories

(Core :: Graphics: Layers, defect, P3)

Product:
Core
Component:
Graphics: Layers
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1281456

People

(Reporter: nical, Unassigned)

Details

(Whiteboard: [gfx-noted])

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]
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.