So far we've used a basic swap-and-invalidate model for layer surface updates. This works for ThebesLayers because we can always invalidate any area covered by the layer and get it repainted. The same is true for plugin layers. Frames created by ImageLayers will be write-once and throwaway with respect to cross-process layers, so there's no content we case to preserve. However, with canvas2d layers, we can't just invalidate parts of the layer to force repaint, since we'd have to track the entire canvas paint history to replay the operations needed to repaint an invalidated region. The swapping model breaks down here. A better model than always copying the entire canvas surface is to use back/front surfaces, and swap them on updates, but then read back the updated region from new-front-surface into new-back-surface. Currently Shmem doesn't support this. One option is to revive the patches from bug 524193 (https://wiki.mozilla.org/IPDL/Proposal:Shmem_access_control) to bring back this support. Another option is to create an UnsafeShmem handle that doesn't guard against shared-memory hazards. We could also explore using this support for faster Thebes and Plugin layers.

Alas, but the access-control spec isn't powerful enough to express our usage pattern in PLayers. Will need to impl UnsafeShmem.

(To clarify: it's powerful enough to express the *access* pattern, because the spec was designed for exactly this problem, but it's not powerful enough to express access control changes for Shmems that are elements of unions and structs, which we use in PLayers.)

Blocking-nom on behalf of bug 603885 which depends on this.

Comment on attachment 482770 [details] [diff] [review] part 2: Generate an AllocUnsafeShmem() method for shmem-using protocols Looks good!

useless without bug 603885 which is blocking b3 and those patches haven't been reviewed yet.

http://hg.mozilla.org/mozilla-central/rev/336b100dd53c http://hg.mozilla.org/mozilla-central/rev/8cd0af801cb9 http://hg.mozilla.org/mozilla-central/rev/8f3eecda38b2