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.
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? How are iframe layer trees handled? I would prefer a model where each Rust task owns a single ‘rendering context’, or whatever we want to call it, and another layer type (HostLayer, ProxyLayer, ???) that hosts one rendering context in another. Maybe this is more general than what we actually need, but synchronization problems will be easier to solve if each task has its own namespace(s) with the compositor and any relationship between tasks is tracked explicitly. Cameron On Jun 30, 2014, at 8:33 AM, Martin Robinson <mrobin...@igalia.com> wrote: > I've been working on a redesign of the compositor, in order to make > rust-layers more functional as a standalone library and also to simplify > ownership of the layer tree. In the current design, there are two > parallel trees, one of rust-layer ContainerLayers/TextureLayers and one > of servo CompositorLayers. > > The main aspects of the rework: > > * ContainerLayers (and thus rust-layers) will know about tiling and > BufferRequests. > * ComposiorLayer will disappear, instead tacked on via generics to > ContainerLayer with its methods replaced by ContainerLayer helper > methods in servo. > * The layer tree will be a simple tree owned by Scene, hopefully > eliminating mutable roots. > > Old design: > https://docs.google.com/drawings/d/1xcsfjxAsfhpAFIv0C9bMnC1VgiEPsmY5cawdBdiKCT4/edit?usp=sharing > New design: > https://docs.google.com/drawings/d/1oohFBhHM-AlhKbehTt8gbPPYWtrX_eZE7W7LXPSSxj0/edit > > I have a patch for the first two parts, which I hope to post soon. It's > big and complicated, because of the inherent messiness of reworking the > tree structure. My hope is that it can land soon and I can begin to move > onto the last phase of the redesign. > > After the first patch lands and before the work is done, performance may > regress, because I've had to create more mutable roots > (std::cell::RefCell) to access the data that used to be in > ContainerLayer. These should disappear in the future. My hope is that > functionality does not regress, though the change is large and invasive, > so there may be new unexpected failures. I will try to stay on top of > everything. > > --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
