Confirmed users
753
edits
Platform/GFX/Surfaces: Difference between revisions
Jump to navigation
Jump to search
→Developing a standard MozSurface abstraction
| Line 166: | Line 166: | ||
As explained in the previous section, we currently have two different abstractions, at two different levels, for "a surface that a producer can render to, and then pass over IPC". One is TextureClient, the other is SurfaceDescriptor. | As explained in the previous section, we currently have two different abstractions, at two different levels, for "a surface that a producer can render to, and then pass over IPC". One is TextureClient, the other is SurfaceDescriptor. | ||
As explained above, TextureClient is the right one that we want everything to use; while SurfaceDescriptor is too low-level and has only become widely used because we didn't have anything else to do that job (it predates TextureClient). The key difference between TextureClient and SurfaceDescriptor is that TextureClient handles locking; so the key problem with code that uses SurfaceDescriptor's directly is that it is hard for such code to get locking right. | As explained above, TextureClient is closest to being the right one that we want everything to use; while SurfaceDescriptor is too low-level and has only become widely used because we didn't have anything else to do that job (it predates TextureClient). The key difference between TextureClient and SurfaceDescriptor is that TextureClient handles locking; so the key problem with code that uses SurfaceDescriptor's directly is that it is hard for such code to get locking right. | ||
Let's use the term "MozSurface" to refer to that universal abstraction for "a surface that a producer can render to, and then pass over IPC". | Let's use the term "MozSurface" to refer to that universal abstraction for "a surface that a producer can render to, and then pass over IPC". | ||
TextureClient isn't quite ready yet to be blessed as "MozSurface", for the following reasons: | |||
* 1. MozSurface should be a unique class used on both sides of IPC, while the TextureClient/TextureHost pair is two separate classes. 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. MozSurface should be a unique class used on both sides of IPC, while the TextureClient/TextureHost pair is two separate classes. 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. | ||
* 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. This is getting fixed with the introduction of the PTexture protocol in bug 897452. | ||
| Line 190: | Line 190: | ||
| | | | | | ||
+-------------------------------------------+ | +-------------------------------------------+ | ||
= Developing a standard MozStream abstraction = | = Developing a standard MozStream abstraction = | ||