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.