Use accelerated drawing to generate snapshots.
Created attachment 247147 [details] Patch
rdar://problem/18072471
Comment on attachment 247147 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=247147&action=review > Source/WebKit2/WebProcess/WebPage/WebPage.cpp:1678 > + No trailing whitespace. > Source/WebKit2/WebProcess/WebPage/WebPage.cpp:1691 > + FloatPoint destination(0, 0); No need for the 0,0. Or the temporary; this can just be an inline FloatPoint() on the next line if you want. > Source/WebKit2/WebProcess/WebPage/WebPage.cpp:1692 > + snapshotGraphicsContext->drawImageBuffer(imageBuffer.get(), ColorSpaceDeviceRGB, destination); We should have a plan to go further and return accelerated image buffers (in the form of IOSurfaces probably) to clients, so that we can avoid this readback. But, I bet you've already learned that painting and then doing the readback is faster in a lot of important cases, and that's why you've posted this patch? Maybe we can make a parallel API (that hands back surfaces and paints acceleratedly) and have people start switching to it? Sadly for very simple cases this will reduce performance (because the win from accelerating painting will not be enough to offset the loss of the readback), so we should probably do that sooner rather than later.
Is there a way we could restrict this snapshotting path to only when a video is presented fullscreen?
Comment on attachment 247147 [details] Patch This patch has been pending review since 2015 with no recent activity. It seems unlikely that it would even still apply to trunk in its current form. Clearing from the review queue. Feel free to update and resubmit if the patch is still relevant.