The copy-on-write lock is just an atomic reference count that we put in
shared memory when doing multi-process.
On Wed, Jul 2, 2014 at 5:49 PM, Patrick Walton wrote:
> On 7/2/14 5:51 AM, Nicolas Silva wrote:
>
>> In the "internal buffer" scenario, we don't need to create a new shmem or
>> swap
On 7/2/14 5:51 AM, Nicolas Silva wrote:
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 rele
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 t
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
ContainerLay
Thanks for the detailed reply. I never expected that Servo would be able to be
able to avoid the possibility of concurrent access to surfaces, for a lot of
those same reasons that you mention.
I have a few questions about the docs.
1. What copy-on-write optimizations is this referring to?
"* W
Hi there,
A few words about TextureClient/Host (since it's been mentioned in this
thread):
we have a bit of design doc about it at:
* http://dxr.mozilla.org/mozilla-central/source/gfx/doc/MozSurface.md
* http://dxr.mozilla.org/mozilla-central/source/gfx/doc/SharedMozSurface.md
Basically TextureC
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
