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
3 matches
Mail list logo
