WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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-
Details
Formatted Diff
Diff
Patch
(30.97 KB, patch)
2020-11-03 13:11 PST
,
Said Abou-Hallawa
no flags
Details
Formatted Diff
Diff
Patch
(27.94 KB, patch)
2020-11-03 14:48 PST
,
Said Abou-Hallawa
no flags
Details
Formatted Diff
Diff
Patch
(40.43 KB, patch)
2020-11-05 15:46 PST
,
Said Abou-Hallawa
no flags
Details
Formatted Diff
Diff
Patch
(44.91 KB, patch)
2020-11-05 20:20 PST
,
Said Abou-Hallawa
simon.fraser
: review+
Details
Formatted Diff
Diff
Patch
(46.20 KB, patch)
2020-11-05 22:41 PST
,
Said Abou-Hallawa
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Said Abou-Hallawa
Comment 1
2020-11-03 12:39:23 PST
Created
attachment 413092
[details]
Patch
Said Abou-Hallawa
Comment 2
2020-11-03 13:11:20 PST
Created
attachment 413100
[details]
Patch
Said Abou-Hallawa
Comment 3
2020-11-03 14:48:02 PST
Created
attachment 413108
[details]
Patch
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
Created
attachment 413361
[details]
Patch
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
Created
attachment 413391
[details]
Patch
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
Created
attachment 413406
[details]
Patch
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
<
rdar://problem/71109948
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug