We can make getImageData more efficient by flushing the context and reading off of the shared backend instead of sending a sync IPC.
Created attachment 414004 [details] Patch
Does this mean we're now reading from the IOSurface mapped in the Web Content process? Because that would be a mistake going forward...
Yes, it does. We can't do this.
(In reply to Tim Horton from comment #3) > Yes, it does. We can't do this. Oh, right. That was another thing wrong with this approach. I guess I'd go back to adding new shared memory region.
(In reply to Tim Horton from comment #3) > Yes, it does. We can't do this. Can you please explain why "we can't do this"? If IOSurface/ShareableBitmap mapped in the Web Content process is read-only, it will act exactly as any shared memory we are going to create. Is there a threat of accessing the IOSurface from the Web Content process even if this access is read-only? Can this cause any security vulnerabilities?
(In reply to Said Abou-Hallawa from comment #5) > (In reply to Tim Horton from comment #3) > > Yes, it does. We can't do this. > > Can you please explain why "we can't do this"? > > If IOSurface/ShareableBitmap mapped in the Web Content process is read-only, > it will act exactly as any shared memory we are going to create. ShareableBitmap, true. IOSurface, not true. I think you got the details elsewhere, but we won't be able to use IOSurface from the Web Content process, because it is *not* just a trivial shared memory buffer.
<rdar://problem/71617360>