Re: [dev-servo] Compositor Tree Redesign

2014-06-30 Thread Cameron Zwarich
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 b

Re: [dev-servo] Compositor Tree Redesign

2014-06-30 Thread Robert O'Callahan
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 proto

Re: [dev-servo] Compositor Tree Redesign

2014-06-30 Thread Cameron Zwarich
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 int

Re: [dev-servo] Compositor Tree Redesign

2014-06-30 Thread Robert O'Callahan
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

Re: [dev-servo] Compositor Tree Redesign

2014-06-30 Thread Patrick Walton
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

Re: [dev-servo] Compositor Tree Redesign

2014-06-30 Thread Robert O'Callahan
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 rob

Re: [dev-servo] Compositor Tree Redesign

2014-06-30 Thread Patrick Walton
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

Re: [dev-servo] Compositor Tree Redesign

2014-06-30 Thread Robert O'Callahan
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 bu

Re: [dev-servo] Compositor Tree Redesign

2014-06-30 Thread Jack Moffitt
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

[dev-servo] Compositor Tree Redesign

2014-06-30 Thread Martin Robinson
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 CompositorL