Platform/GFX/Surfaces: Difference between revisions

Jump to navigation Jump to search
Line 171: Line 171:


TextureClient isn't quite ready yet to be blessed as "MozSurface", for the following reasons:
TextureClient isn't quite ready yet to be blessed as "MozSurface", for the following reasons:
* 1. MozSurface should be a unique abstraction used on both sides of IPC, while the TextureClient/TextureHost pair is two separate abstractions. It should be possible to unify TextureClient and TextureHost into a single class; that should be a prerequisite before it can claim to be MozSurface.
* 1. Not all layer types use the new TextureClient/Host API yet, some still use the DeprecatedTextureClient/Host. We can't use MozSurface with layers that are still on the deprecated API.
* 2. MozSurface should be free of any dependency on Layers classes, because even though ultimately graphics aren't visible to the user until they get composited as layers, we can have to start creating and even passing around surfaces before layers are created. A good example is a canvas that hasn't been inserted into the DOM yet. Currently TextureClient/Host refer to compositables to identify themselves. This is getting fixed with the introduction of the PTexture protocol in bug 897452.
* 2. MozSurface should be free of any dependency on Layers classes, because even though ultimately graphics aren't visible to the user until they get composited as layers, we can have to start creating and even passing around surfaces before layers are created. A good example is a canvas that hasn't been inserted into the DOM yet. Currently TextureClient/Host refer to compositables to identify themselves over IPC, and the lifetime of shared texture data is constrained by the lifetime of the Compositable. This is getting fixed with the introduction of the PTexture protocol in bug 897452.
* 3. MozSurface should be a unique abstraction used on both sides of IPC, while the TextureClient/TextureHost pair is two separate abstractions. It should be possible to unify TextureClient and TextureHost into a single class; that should be a prerequisite before it can claim to be MozSurface.


Once the above items are done, we should be able to call MozSurface the class created from the merging of TextureClient and TextureHost, and declare it our universal surface abstraction to use in all producer/consumer/ipc contexts.
Once the above items are done, we should be able to call MozSurface the class created from the merging of TextureClient and TextureHost, and declare it our universal surface abstraction to use in all producer/consumer/ipc contexts.
Confirmed users
138

edits

Navigation menu