RESOLVED FIXED 218529
[GPU Process] Use the Ref counting of ImageBuffer to control its life cycle in Web Process and GPU Process
https://bugs.webkit.org/show_bug.cgi?id=218529
Summary [GPU Process] Use the Ref counting of ImageBuffer to control its life cycle i...
Said Abou-Hallawa
Reported 2020-11-03 12:29:22 PST
DrawImageBuffer will hold a Variant<RefPtr<WebCore::ImageBuffer>, RenderingResourceIdentifier>. The RefPtr<WebCore::ImageBuffer> will be set in the Web Process when drawing an ImageBuffer to another ImageBuffer. The RenderingResourceIdentifier of ImageBuffer will be encoded when sending the DisplayList to the GPU Process. In the GPU process, a DrawImageBuffer will be decoded with RenderingResourceIdentifier. The RemoteRenderingBackend will search for the ImageBuffer in its RemoteResourceCache given the RenderingResourceIdentifier and will draw it to the GraphicsContext. This will remove the need to lock and unlock the remote resource in RemoteResourceCacheProxy.
Attachments
Patch (25.35 KB, patch)
2020-11-03 12:39 PST, Said Abou-Hallawa
ews-feeder: commit-queue-
Patch (30.97 KB, patch)
2020-11-03 13:11 PST, Said Abou-Hallawa
no flags
Patch (27.94 KB, patch)
2020-11-03 14:48 PST, Said Abou-Hallawa
no flags
Patch (40.43 KB, patch)
2020-11-05 15:46 PST, Said Abou-Hallawa
no flags
Patch (44.91 KB, patch)
2020-11-05 20:20 PST, Said Abou-Hallawa
simon.fraser: review+
Patch (46.20 KB, patch)
2020-11-05 22:41 PST, Said Abou-Hallawa
no flags
Said Abou-Hallawa
Comment 1 2020-11-03 12:39:23 PST
Said Abou-Hallawa
Comment 2 2020-11-03 13:11:20 PST
Said Abou-Hallawa
Comment 3 2020-11-03 14:48:02 PST
Simon Fraser (smfr)
Comment 4 2020-11-05 11:18:21 PST
Comment on attachment 413108 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=413108&action=review > Source/WebCore/platform/graphics/GraphicsContext.cpp:816 > + if (m_impl && image.renderingResourceIdentifier()) { > + m_impl->drawImageBuffer(image, destination, source, options); I think it's wrong to rely on the presence of a image.renderingResourceIdentifier to control behavior. What's the real question you're asking? > Source/WebCore/platform/graphics/displaylists/DisplayListRecorder.cpp:191 > + m_displayList.registerImageBuffer(makeRef(imageBuffer)); This seems like a use for willAppendItemOfType(). > Source/WebCore/platform/graphics/displaylists/DisplayListRecorder.cpp:192 > appendItemAndUpdateExtent(DrawImageBuffer::create(imageBuffer.renderingResourceIdentifier(), destRect, srcRect, options)); Should probably ASSERT(imageBuffer.renderingResourceIdentifier()) here.
Said Abou-Hallawa
Comment 5 2020-11-05 15:46:39 PST
Said Abou-Hallawa
Comment 6 2020-11-05 15:56:53 PST
Comment on attachment 413108 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=413108&action=review >> Source/WebCore/platform/graphics/GraphicsContext.cpp:816 >> + m_impl->drawImageBuffer(image, destination, source, options); > > I think it's wrong to rely on the presence of a image.renderingResourceIdentifier to control behavior. What's the real question you're asking? I changed the patch such that this question means what is written. The question here is "can we inline the DrawImageBuffer item?". The DisplayList will keep a HashSet which will be used to control the life cycle of the source ImageBuffers. And it can be used also to resolve the RenderingResourceIdentifier to an ImageBuffer if the display list is replayed back in WebP. if it is replayed In GPUP, we are going to pass the HashSet which is maintained by RemoteResourceCache. >> Source/WebCore/platform/graphics/displaylists/DisplayListRecorder.cpp:191 >> + m_displayList.registerImageBuffer(makeRef(imageBuffer)); > > This seems like a use for willAppendItemOfType(). I might be confused by your comment here. But I think willAppendItemOfType() work on the destination ImageBuffer but we want to cache the source ImageBuffer. >> Source/WebCore/platform/graphics/displaylists/DisplayListRecorder.cpp:192 >> appendItemAndUpdateExtent(DrawImageBuffer::create(imageBuffer.renderingResourceIdentifier(), destRect, srcRect, options)); > > Should probably ASSERT(imageBuffer.renderingResourceIdentifier()) here. Done.
Simon Fraser (smfr)
Comment 7 2020-11-05 17:46:10 PST
Comment on attachment 413361 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=413361&action=review > Source/WebCore/platform/graphics/GraphicsContext.cpp:815 > + if (m_impl && image.renderingResourceIdentifier()) { image.renderingResourceIdentifier should not change behavior.
Said Abou-Hallawa
Comment 8 2020-11-05 20:20:18 PST
Said Abou-Hallawa
Comment 9 2020-11-05 20:22:05 PST
Comment on attachment 413361 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=413361&action=review >> Source/WebCore/platform/graphics/GraphicsContext.cpp:815 >> + if (m_impl && image.renderingResourceIdentifier()) { > > image.renderingResourceIdentifier should not change behavior. Fixed. The new patch records an inline DrawImageBuffer item for both DL and GPUP cases.
Simon Fraser (smfr)
Comment 10 2020-11-05 20:36:11 PST
Comment on attachment 413391 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=413391&action=review > Source/WebCore/platform/graphics/displaylists/DisplayListRecorder.cpp:191 > + m_displayList.cacheImageBuffer(makeRef(imageBuffer)); Rather than this, you should the work in willAppendItemOfType(), because there are going to be other drawing commands that use ImageBuffers (e.g. clipToImageBuffer() which you did not fix in this patch). > Source/WebCore/platform/graphics/displaylists/DisplayListReplayer.cpp:54 > + if (item.type() == ItemType::DrawImageBuffer) { > + auto& drawItem = static_cast<DrawImageBuffer&>(item); > + if (auto* imageBuffer = m_imageBuffers.get(drawItem.renderingResourceIdentifier())) > + drawItem.apply(m_context, *imageBuffer); > + return; > + } Also needs to deal with clipToImageBuffer(). > Source/WebCore/platform/graphics/displaylists/DisplayListReplayer.cpp:57 > + if (m_delegate && m_delegate->apply(item, m_context)) > + return; It's unclear how someone reading this code would know whether it's correct for this to be after the ImageBuffer special-casing.
Said Abou-Hallawa
Comment 11 2020-11-05 22:41:45 PST
Said Abou-Hallawa
Comment 12 2020-11-05 22:43:56 PST
Comment on attachment 413391 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=413391&action=review >> Source/WebCore/platform/graphics/displaylists/DisplayListRecorder.cpp:191 >> + m_displayList.cacheImageBuffer(makeRef(imageBuffer)); > > Rather than this, you should the work in willAppendItemOfType(), because there are going to be other drawing commands that use ImageBuffers (e.g. clipToImageBuffer() which you did not fix in this patch). I will address fixing clipToImageBuffer in a separate patch. >> Source/WebCore/platform/graphics/displaylists/DisplayListReplayer.cpp:57 >> + return; > > It's unclear how someone reading this code would know whether it's correct for this to be after the ImageBuffer special-casing. I cleaned this function a little. I moved the call to delegate first, then I added DrawImageBuffer special-casing second.
EWS
Comment 13 2020-11-05 23:27:35 PST
Committed r269503: <https://trac.webkit.org/changeset/269503> All reviewed patches have been landed. Closing bug and clearing flags on attachment 413406 [details].
Radar WebKit Bug Importer
Comment 14 2020-11-05 23:28:19 PST
Note You need to log in before you can comment on or make changes to this bug.