We have two kinds of textures: the zero-copy ones such as Gralloc buffers on B2G or DXGI textures on D3D11 (we talk about "direct texturing" because we paint directly into the texture that we use for compositing) and the ones that have implicitly an internal buffer, for example some shared memory that is uploaded to a texture on the compositor side.
In the "internal buffer" scenario, we don't need to create a new shmem or swap back and forth between the front and back textures if the compositor is done uploading the texture. So we have a lock that the content thread takes when painting and that is released by the compositor after the texture is uploaded. Next time a tile needs to be painted we only create a back buffer if the front buffer's lock is still taken, in which case we copy the front tile's content into the back and repaint the damaged region (this is the copy-on-write I was referring to). If we already have a back buffer we only need to copy the parts of the front buffer that are valid (but not valid in the back as we track valid regions for both the front and back buffers). On some occasions (such as memory pressure events) tiles can drop their back buffers. In the case of direct texturing, a tile's front buffer is always used by the compositor when we need to redraw parts of it so we always end up creating a back buffer. I think that tiled and non-tiled layers now have more or less the same logic around synchronizing the front and back buffers, although we don't have a copy-on-write lock for non-tiled layers (we just always create a back buffer the second time a non-tiled content layer is painted into). Another example of a place where should use copy-on-write-like tricks (but we don't at the moment) is with canvas 2D: with 2d games they are typically cleared at the beginning of the next frame so we should send the texture that the canvas has drawn into to the compositor and only copy it into a back buffer if the next drawing command doesn't cover the entire canvas (rather than always copying the texture before sending it to the compositor as I think we do now). You don't have this use-case yet but it's just an example of something we could do thanks to the way we share textures. Cheers, Nical On Tue, Jul 1, 2014 at 6:41 PM, Martin Robinson <mrobin...@igalia.com> wrote: > On 06/30/2014 10:14 PM, Cameron Zwarich wrote: > > We discussed this a bit on #servo, but it isn’t obvious from your > > diagram if every Layer will have child layers, or if that will be > > reserved for specific container layers. > > The way I've designed it now, TileLayers are not siblings of > ContainerLayers, but are instead data members on ContainerLayers. All > ContainerLayers can potentially have children, but none of those > children will be TileLayers. > > > CoreAnimation takes the former approach, but I think the latter might > > be more applicable for Servo, since it would give a better separation > > of concerns. We would then have the following layer types: > > > > 1. ContainerLayer, which can only parent other layers. 2. TileLayer, > > which would manage tiling, BufferRequests, and all double buffering > > of individual tile backing stores. 3. TextureLayer (maybe ImageLayer > > would be a better name?), which is backed by a simple image. Would we > > even want it to be double buffered? > > I still need to look a lot more closely at how tiling works in the next > phase, but this design works for me. I think most of the pieces are > already in place actually. > > --Martin > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
