Title: [290542] trunk/Source
- Revision
- 290542
- Author
- [email protected]
- Date
- 2022-02-25 21:05:55 -0800 (Fri, 25 Feb 2022)
Log Message
[GPU Process] Implement RemoteImageBufferProxy::drawConsuming()
https://bugs.webkit.org/show_bug.cgi?id=236685
rdar://89007426
Reviewed by Simon Fraser.
Source/WebCore:
Assert ImageBuffer::drawConsuming() does not draw into its backend before
it is destroyed.
* platform/graphics/ConcreteImageBuffer.h:
Source/WebKit:
RemoteImageBufferProxy::drawConsuming() should call drawImageBuffer() of
the destination GraphicsContext. No recursion will happen and the expected
behavior will be achieved by this change.
This is the sequence of calls when the Destination GraphicsContext is
local and when it is remote:
-- Destination GraphicsContext is local:
In this case, the backend of the RemoteImageBufferProxy can be mapped
in WebProcess; i.e. we do have access to its memory.
ConcreteImageBuffer::draw() will be called eventually. This function
will call its backend->draw() which will get a NativeImage by calling
backend->copyNativeImage(). There is no difference between draw() and
drawConsuming() in this case because the backend is still owned by
GPUProcess. So it will not be released immediately. We do not copy the
pixels since we have to pass DontCopyBackingStore to copyNativeImage().
-- Destination GraphicsContext is remote:
In this case, Recorder::drawImageBuffer() will be called which will
call RemoteDisplayListRecorderProxy::recordDrawImageBuffer(). This
will send a message to GPUProcess and hence all the drawing will
happen in GPUProcess. Similar to the case of the local GraphicsContext,
no pixels will be copied from the RemoteImageBuffer backend to the
NativeImage in all cases. The assumption is the backend will be destroyed
automatically after calling drawConsuming().
* WebProcess/GPU/graphics/RemoteImageBufferProxy.h:
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (290541 => 290542)
--- trunk/Source/WebCore/ChangeLog 2022-02-26 03:59:24 UTC (rev 290541)
+++ trunk/Source/WebCore/ChangeLog 2022-02-26 05:05:55 UTC (rev 290542)
@@ -1,3 +1,16 @@
+2022-02-25 Said Abou-Hallawa <[email protected]>
+
+ [GPU Process] Implement RemoteImageBufferProxy::drawConsuming()
+ https://bugs.webkit.org/show_bug.cgi?id=236685
+ rdar://89007426
+
+ Reviewed by Simon Fraser.
+
+ Assert ImageBuffer::drawConsuming() does not draw into its backend before
+ it is destroyed.
+
+ * platform/graphics/ConcreteImageBuffer.h:
+
2022-02-25 Alejandro G. Castro <[email protected]> and Fujii Hironori <[email protected]>
[GTK][WPE][WC] Move ANGLE context initialisation to GraphicsContextGLTextureMapper::initialize
Modified: trunk/Source/WebCore/platform/graphics/ConcreteImageBuffer.h (290541 => 290542)
--- trunk/Source/WebCore/platform/graphics/ConcreteImageBuffer.h 2022-02-26 03:59:24 UTC (rev 290541)
+++ trunk/Source/WebCore/platform/graphics/ConcreteImageBuffer.h 2022-02-26 05:05:55 UTC (rev 290542)
@@ -196,6 +196,7 @@
void drawConsuming(GraphicsContext& destContext, const FloatRect& destRect, const FloatRect& srcRect, const ImagePaintingOptions& options) override
{
+ ASSERT(&destContext != &context());
if (auto* backend = ensureBackendCreated()) {
flushDrawingContext();
backend->drawConsuming(destContext, destRect, srcRect, options);
Modified: trunk/Source/WebKit/ChangeLog (290541 => 290542)
--- trunk/Source/WebKit/ChangeLog 2022-02-26 03:59:24 UTC (rev 290541)
+++ trunk/Source/WebKit/ChangeLog 2022-02-26 05:05:55 UTC (rev 290542)
@@ -1,3 +1,39 @@
+2022-02-25 Said Abou-Hallawa <[email protected]>
+
+ [GPU Process] Implement RemoteImageBufferProxy::drawConsuming()
+ https://bugs.webkit.org/show_bug.cgi?id=236685
+ rdar://89007426
+
+ Reviewed by Simon Fraser.
+
+ RemoteImageBufferProxy::drawConsuming() should call drawImageBuffer() of
+ the destination GraphicsContext. No recursion will happen and the expected
+ behavior will be achieved by this change.
+
+ This is the sequence of calls when the Destination GraphicsContext is
+ local and when it is remote:
+
+ -- Destination GraphicsContext is local:
+ In this case, the backend of the RemoteImageBufferProxy can be mapped
+ in WebProcess; i.e. we do have access to its memory.
+ ConcreteImageBuffer::draw() will be called eventually. This function
+ will call its backend->draw() which will get a NativeImage by calling
+ backend->copyNativeImage(). There is no difference between draw() and
+ drawConsuming() in this case because the backend is still owned by
+ GPUProcess. So it will not be released immediately. We do not copy the
+ pixels since we have to pass DontCopyBackingStore to copyNativeImage().
+
+ -- Destination GraphicsContext is remote:
+ In this case, Recorder::drawImageBuffer() will be called which will
+ call RemoteDisplayListRecorderProxy::recordDrawImageBuffer(). This
+ will send a message to GPUProcess and hence all the drawing will
+ happen in GPUProcess. Similar to the case of the local GraphicsContext,
+ no pixels will be copied from the RemoteImageBuffer backend to the
+ NativeImage in all cases. The assumption is the backend will be destroyed
+ automatically after calling drawConsuming().
+
+ * WebProcess/GPU/graphics/RemoteImageBufferProxy.h:
+
2022-02-25 J Pascoe <[email protected]>
[WebAuthn] Fallback to attestation=none whenever attestation fails
Modified: trunk/Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.h (290541 => 290542)
--- trunk/Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.h 2022-02-26 03:59:24 UTC (rev 290541)
+++ trunk/Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.h 2022-02-26 05:05:55 UTC (rev 290542)
@@ -191,6 +191,12 @@
return bitmap->createImage();
}
+ void drawConsuming(WebCore::GraphicsContext& destContext, const WebCore::FloatRect& destRect, const WebCore::FloatRect& srcRect, const WebCore::ImagePaintingOptions& options) final
+ {
+ ASSERT(&destContext != &context());
+ destContext.drawImageBuffer(*this, destRect, srcRect, options);
+ }
+
RefPtr<WebCore::NativeImage> sinkIntoNativeImage() final
{
return copyNativeImage();
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
