Platform/GFX/textures

TextureClient & TextureHost

TextureClient and TextureHost are the way to share texture memory accross threads or processes.

New vs Deprecated textures

Depreacted texture clients and host suffer from a mix of imperfect design decisions (design decisions that did not work well in the specific case of B2G's memory model coupled with some of the funky sharing in Gecko) and the pile of quick hacks that had to be done to keep them around. As a result, deprecated texture clients and host are hard to reason about and bug prone on B2G.

In order to incrementally fix the badness of TextureClient and TextureHost, the classes have been marked deprecated and new texture clients and host were designed, using a more strict and defined memory model. The goal is now to replace all the usage of DeprecatedTexture* by the new classes. When writing new code, if possible please use the new classes.

Migration to the new textures (Meta bug 893300)

The idea is to add new compositable classes beside the deprecated ones and to remove the deprecated ones when the new ones considered stable enough on all platforms. This is an improvement for:

• Code maintainability (we can remove deprecated code and use the new one that is much easier to maintain)
• In some cases it opens the door for performance improvement

Port ContentClient/ContentHost compositable classes (Bug 893301)

• ContentClientSingleBuffered / ContentHostSingleBuffered

Probably the most important followup, the logic should not change so it should not take "too long" (maybe a week or two).

• ContentClientDoubleBuffered / ContentHostDoubleBuffered

Should be easy once SingleBuffered version is implemented (a day or two)

• ContentClientIncremental / ContentHostIncremental

The logic here needs to be modified a bit, would probably take a week.

Port TiledContentClient / TiledContentHost (Bug 893303)

Current implementation does it's own thing that does not fit even in the Deprecated textures model, so porting it to the new textures may require some investigation. The bright side is that then it would work on B2G.

Port CanvasClientWebGL / CanvasHostWebGL (Bug 893304)

Just like the tiled classes, right now it does it's own thing, needs some investigation. So porting it to new textures depends on whether we want to do it "properly" or do it like we did for the Deprecated textures.

Port the D3D9 backend

D3D9 compositing will land soon and has been made for the deprecated texture model I expect it to be similar to D3D11 so I would be surprised that this take more than a week, but I haven't read the code so I don't know for sure.

Remove all the IPDL messages that are specific to Deprecated classes

This is just cleaning up unsued code, will have to wait until all the compositable classes are ported to the new textures and enabled everywhere. This is an imporvement code maintainability, a lot of bad code will be removed.

Other texture-related plans

The items below are things we want to do with new textures, but if we don't do them we will still be on par with the deprecated textures. So I expect them to be lower priority, at this point we are mostly interested in the items above.

Implement partial updates for DataTextureSource implementations

This will let us use IncrementalContentHost for non-OpenGL backends. This doesn't have any dependency but will not be useful before IncrementalContentHost is implemented.

• DataTextureSourceD3D11
• DataTextureSourceBasic

Implement cross-process locks for TextureClient/TextureHost

Having them would let us have more choice in the treade-off speed vs memory usage. They can be implemented in parallel, should be really low priority. This doesn't depend on other items. (windows already has a CrossProcessLock)

• for Linux (for Shmem, shared textures)
• for OSX (for Shmem, shared textures)

This is an improvement for:

• flexibility/memory usage: we will be able to use single buffering in places where we can only double buffer if we don't have a lock

Implement TextureClient pools

This is a performance improvement that is important at least for video: rather than allocating/deallocating shared memory every time, recycle TextureClients (along with their shared buffers and reuse them). We had this feature only with async-video before the all mighty layers refactoring, and lost it during the refactoring. If we implement it now it should work also for non-omtc (thanks to the refactoring). This is an improvement for:

• performances in places where we tend to allocate and deallocate a lot of buffers (like video)

Make it possible for several compositables to use the same Texture.

This will be a big performance win in certain specific cases, and let us implement the "Texture atlas" optimization for mobile platforms where we want to reduce the number of draw calls. This doesn't have dependencies, although we'll probably see clearer when more compositables are ported? I expect ImageClient/Host to be the only compositable that would use it at least at first, but I may be wrong. See bug 897452

This is an improvement for:

• performances
• memory usage