Gecko:ImageContainerManagement
From MozillaWiki
Requirements
- Optimized image copying and storage when playing video/plugins in a window, including after layer manager switches described below
- Seamless switch from BasicLayerManager to LayerManagerD3D9 due to D3D9 initialization
- Seamless switch from one (live) layer manager to another of the same type, when moving an element between windows
- Switch from one (dead) D3D9/D3D10 layer manager to a live one of the same type, during device resets; switchover may not be visually seamless (existing images may be lost)
- A video/plugin element not being displayed in a window can still render (e.g. via drawWindow), even after its original LayerManager dies.
Proposal
- Extract current ImageContainer threadsafe image creation functionality into ImageFactory classes.
- Add LayerManager::GetImageFactory accessor. For some backend types, there could be one global ImageFactory, for other backend types there could be one ImageFactory per layer manager.
- Make ImageContainer completely layer-manager-independent. It's mainly just a threadsafe holder for the current image and current image factory.
- Any Image can be set as the current image for any ImageContainer. Any ImageContainer works with any ImageLayer.
- When a LayerManager dies, any Images it owns are rescued if necessary/possible so they keep working (unless image data was lost, in which case it's treated as black). This does not require Image ownership to be explicitly tracked however.
- When a LayerManager dies, any ImageFactories it owns should keep working, either working normally or just delegating to the BasicLayers ImageFactory.
- Whenever an ImageLayer is created for a retained layer manager, update the ImageFactory of its ImageContainer to the ImageFactory of the retained layer manager.