Bug 141924 – Use accelerated drawing to generate snapshots.

• Status: NEW
• Component: WebKit2

[Jeremy Jones]

Use accelerated drawing to generate snapshots.

[Jeremy Jones]

Created attachment 247147 [details]
Patch

[Jeremy Jones]

rdar://problem/18072471

[Tim Horton]

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.

[Jon Lee]

Is there a way we could restrict this snapshotting path to only when a video is presented fullscreen?

[Brady Eidson]

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.