[dev-servo] Compositor Tree Redesign
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
Re: [dev-servo] Compositor Tree Redesign
This looks like a huge improvement. Can you give us an idea of what the CompositorData type looks like? jack. On Mon, Jun 30, 2014 at 9:33 AM, Martin Robinson 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
Re: [dev-servo] Compositor Tree Redesign
BTW have you or anyone else working on Servo looked at TextureClient/TextureHost in Gecko? Getting buffer management interfaces correct across many platforms with multi-process and robustness in the face of crashes and platform quirks has proven to be very hard. I think we're in a good place now but we went down many blind alleys so there's some valuable lessons to be learned. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Compositor Tree Redesign
On 6/30/14 4:44 PM, Robert O'Callahan wrote: BTW have you or anyone else working on Servo looked at TextureClient/TextureHost in Gecko? Getting buffer management interfaces correct across many platforms with multi-process and robustness in the face of crashes and platform quirks has proven to be very hard. I think we're in a good place now but we went down many blind alleys so there's some valuable lessons to be learned. By TextureClient/TextureHost I assume you mean cross-process texture sharing? If so, yes, we have been doing this from day one. (We have to, because we do painting on a separate thread.) It's a giant pain on all platforms and we have been fighting bugs with it from day one. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Compositor Tree Redesign
On Tue, Jul 1, 2014 at 11:46 AM, Patrick Walton wrote: > On 6/30/14 4:44 PM, Robert O'Callahan wrote: > >> BTW have you or anyone else working on Servo looked at >> TextureClient/TextureHost in Gecko? Getting buffer management interfaces >> correct across many platforms with multi-process and robustness in the >> face >> of crashes and platform quirks has proven to be very hard. I think we're >> in >> a good place now but we went down many blind alleys so there's some >> valuable lessons to be learned. >> > > By TextureClient/TextureHost I assume you mean cross-process texture > sharing? If so, yes, we have been doing this from day one. (We have to, > because we do painting on a separate thread.) > Yes. But if you haven't got robust support for D3D10 and Android gralloc and Windows Media Foundation accelerated video decoding and all that sort of thing, you probably don't have the design right unless you're cleverer and luckier than the rest of us :-). Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Compositor Tree Redesign
On 6/30/14 6:20 PM, Robert O'Callahan wrote: Yes. But if you haven't got robust support for D3D10 and Android gralloc and Windows Media Foundation accelerated video decoding and all that sort of thing, you probably don't have the design right unless you're cleverer and luckier than the rest of us :-). It'd be good to discuss what the right design is then. I'm not wedded to our current design--it's pretty bare-bones at the moment anyhow (as things like synchronization are basically unhandled). Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Compositor Tree Redesign
On Tue, Jul 1, 2014 at 1:21 PM, Patrick Walton wrote: > On 6/30/14 6:20 PM, Robert O'Callahan wrote: > >> Yes. But if you haven't got robust support for D3D10 and Android gralloc >> and Windows Media Foundation accelerated video decoding and all that >> sort of thing, you probably don't have the design right unless you're >> cleverer and luckier than the rest of us :-). >> > > It'd be good to discuss what the right design is then. I'm not wedded to > our current design--it's pretty bare-bones at the moment anyhow (as things > like synchronization are basically unhandled). > I don't know the details myself. Nicolas Silva would be a good person to talk to. Maybe you should go through a design review with him. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Compositor Tree Redesign
On Jun 30, 2014, at 6:20 PM, Robert O'Callahan wrote: > On Tue, Jul 1, 2014 at 11:46 AM, Patrick Walton > wrote: > >> On 6/30/14 4:44 PM, Robert O'Callahan wrote: >> >>> BTW have you or anyone else working on Servo looked at >>> TextureClient/TextureHost in Gecko? Getting buffer management interfaces >>> correct across many platforms with multi-process and robustness in the >>> face >>> of crashes and platform quirks has proven to be very hard. I think we're >>> in >>> a good place now but we went down many blind alleys so there's some >>> valuable lessons to be learned. >>> >> >> By TextureClient/TextureHost I assume you mean cross-process texture >> sharing? If so, yes, we have been doing this from day one. (We have to, >> because we do painting on a separate thread.) >> > > Yes. But if you haven't got robust support for D3D10 and Android gralloc > and Windows Media Foundation accelerated video decoding and all that sort > of thing, you probably don't have the design right unless you're cleverer > and luckier than the rest of us :-). How much of that changed the basic nature of the abstraction and how much of it was just difficult platform-specific implementation work? Most of my experience is with IOSurface on Darwin, which is comparatively sane. Cameron ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Compositor Tree Redesign
On Tue, Jul 1, 2014 at 3:27 PM, Cameron Zwarich wrote: > How much of that changed the basic nature of the abstraction and how much > of it was just difficult platform-specific implementation work? > Depends on the level of abstraction you're talking about, but we had to restructure our IPC protocols a couple of times to account for specific platform issues. The API between layers and layout did not change, but a lot of the layers implementation did. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Compositor Tree Redesign
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 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
