Is the efficiency loss because the parent renderer can't skip drawing thing that are underneath the iframe when the iframe's document has an opaque background?

This shouldn't be blocked on security concerns; it's hard to imagine this information being worth compromising a renderer process for. The main cost is just the development effort, which I don't think would be too bad.

@#1: correct - if the parent has an opaque occluder, it can avoid rasterizing that's underneath.

Re: security issue, I think a concern is that if the child say "of course I'm opaque" but pushes a transparent frame, the parent could cull the quads that are underneath and so we could end up with garbage if nothing draws that area of the screen. That garbage could in theory be random GPU memory, and I'm not sure if information could leak that way.

However the opaque rect should be propagated to the SurfaceDrawQuad, and so the surface aggregator could validate that the frame for that surface is indeed opaque, and mitigate otherwise.

@#2: If information can leak in that way, then we might want a more general mitigation. We already need to verify that one renderer process can't read back pixels from textures created by another renderer process, even when they have the SurfaceId. I think we discussed at one point how the GPU process could do this with TextureMailboxes, I don't know if that still works.

Surface draw occlusion should solve this. I'm assigning to Yi!