||Compositable client for 2d and webgl canvas.
||An implementation of PaintedLayer that ONLY supports remote
composition that is backed by tiles. This painted layer implementation
is better suited to mobile hardware to work around slow implementation
of glTexImage2D (for OGL compositors), and restrait memory bandwidth.
Tiled PaintedLayers use a different protocol compared with other
layers. A copy of the tiled buffer is made and sent to the compositing
thread via the layers protocol. Tiles are uploaded by the buffers
asynchonously without using IPC, that means they are not safe for cross-
process use (bug 747811). Each tile has a TextureHost/Client pair but
they communicate directly rather than using the Texture protocol.
There is no ContentClient for tiled layers. There is a ContentHost, however.
||CompositableClient manages the texture-specific logic for composite layers,
independently of the layer. It is the content side of a CompositableClient/
CompositableClient's purpose is to send texture data to the compositor side
along with any extra information about how the texture is to be composited.
Things like opacity or transformation belong to layer and not compositable.
Since Compositables are independent of layers it is possible to create one,
connect it to the compositor side, and start sending images to it. This alone
is arguably not very useful, but it means that as long as a shadow layer can
do the proper magic to find a reference to the right CompositableHost on the
Compositor side, a Compositable client can be used outside of the main
shadow layer forwarder machinery that is used on the main thread.
The first step is to create a Compositable client and call Connect().
Connect() creates the underlying IPDL actor (see CompositableChild) and the
corresponding CompositableHost on the other side.
To do in-transaction texture transfer (the default), call
ShadowLayerForwarder::Attach(CompositableClient*, ShadowableLayer*). This
will let the LayerComposite on the compositor side know which
CompositableHost to use for compositing.
To do async texture transfer (like async-video), the CompositableClient
should be created with a different CompositableForwarder (like
ImageBridgeChild) and attachment is done with
CompositableForwarder::AttachAsyncCompositable that takes an identifier
instead of a CompositableChild, since the CompositableClient is not managed
by this layer forwarder (the matching uses a global map on the compositor
side, see CompositableMap in ImageBridgeParent.cpp)
Subclasses: Painted layers use ContentClients, ImageLayers use ImageClients,
Canvas layers use CanvasClients (but ImageHosts). We have a different
subclass where we have a different way of interfacing with the textures - in
terms of drawing into the compositable and/or passing its contents to the
||A compositable client for PaintedLayers. These are different to Image/Canvas
clients due to sending a valid region across IPC and because we do a lot more
optimisation work, encapsulated in RotatedBuffers.
We use content clients for OMTC and non-OMTC, basic rendering so that
BasicPaintedLayer has only one interface to deal with. We support single and
double buffered flavours. For tiled layers, we do not use a ContentClient
although we do have a ContentHost, and we do use texture clients and texture
The interface presented by ContentClient is used by the BasicPaintedLayer
methods - PaintThebes, which is the same for MT and OMTC, and PaintBuffer
which is different (the OMTC one does a little more).
||Image clients are used by basic image layers on the content thread, they
always match with an ImageHost on the compositor thread. See
CompositableClient.h for information on connecting clients to hosts.
||Performs a progressive update of a given tiled buffer.
See ComputeProgressiveUpdateRegion below for parameter documentation.
aOutDrawnRegion is an outparameter that contains the region that was
drawn, and which can now be added to the layer's valid region.
||Provide an instance of TiledLayerBuffer backed by drawable TextureClients.
This buffer provides an implementation of ValidateTile using a
thebes callback and can support painting using a single paint buffer.
Whether a single paint buffer is used is controlled by
||TextureChild is the content-side incarnation of the PTexture IPDL actor.
TextureChild is used to synchronize a texture client and its corresponding
TextureHost if needed (a TextureClient that is not shared with the compositor
does not have a TextureChild)
During the deallocation phase, a TextureChild may hold its recently destroyed
TextureClient's data until the compositor side confirmed that it is safe to
deallocte or recycle the it.
||TextureClient is the abstraction that allows us to share data between the
content and the compositor side.
||Return a TextureClient that is not yet ready to be reused, but will be
||TextureClientRecycleAllocator provides TextureClients allocation and
recycling capabilities. It expects allocations of same sizes and
attributres. If a recycled TextureClient is different from
requested one, the recycled one is dropped and new TextureClient is
By default this uses TextureClient::CreateForDrawing to allocate new texture
||Represent a single tile in tiled buffer. The buffer keeps tiles,
each tile keeps a reference to a texture client and a read-lock. This
read-lock is used to help implement a copy-on-write mechanism. The tile
should be locked before being sent to the compositor. The compositor should
unlock the read-lock as soon as it has finished with the buffer in the
TextureHost to prevent more textures being created than is necessary.
Ideal place to store per tile debug information.