WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 212269
Make WebPage::ForceRepaint use CompletionHandler instead of VoidCallback
https://bugs.webkit.org/show_bug.cgi?id=212269
Summary
Make WebPage::ForceRepaint use CompletionHandler instead of VoidCallback
Alex Christensen
Reported
2020-05-22 11:08:16 PDT
Make WebPage::ForceRepaint use CompletionHandler instead of VoidCallback
Attachments
Patch
(24.37 KB, patch)
2020-05-22 11:09 PDT
,
Alex Christensen
no flags
Details
Formatted Diff
Diff
Patch
(26.94 KB, patch)
2020-12-23 12:25 PST
,
Alex Christensen
ews-feeder
: commit-queue-
Details
Formatted Diff
Diff
Patch
(27.00 KB, patch)
2020-12-23 12:32 PST
,
Alex Christensen
no flags
Details
Formatted Diff
Diff
Patch
(28.62 KB, patch)
2020-12-23 15:22 PST
,
Alex Christensen
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Alex Christensen
Comment 1
2020-05-22 11:09:21 PDT
Created
attachment 400060
[details]
Patch
youenn fablet
Comment 2
2020-05-25 01:19:17 PDT
Comment on
attachment 400060
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=400060&action=review
> Source/WebKit/UIProcess/WebPageProxy.cpp:4270 > + callAfterNextPresentationUpdate([completionHandler = WTFMove(completionHandler)] (auto) mutable {
We could probably take the background activity here since sendWithAsyncReply should take a background activity anyway.
> Source/WebKit/WebProcess/WebPage/DrawingArea.h:86 > + virtual bool forceRepaintAsync(CompletionHandler<void()>&) { return false; }
Seems strange to pass a CompletionHandler<void()>&, CompletionHandler<void()>&& os probably more appropriate. Also we should probably call the completion handler here or make it virtual pure.
> Source/WebKit/WebProcess/WebPage/WebPage.cpp:3611 > + if (m_drawingArea->forceRepaintAsync(completionHandler)) {
This API seems a bit weird. I guess sometimes we move the completionHandler and we return true and sometimes we do not move completionHandler and we return false. It seem we could move the completionHandler and check whether null afterwards here. forceRepaintAsync would then return void. Or we could split it in two APIs: bool canForceRepaint() and void forceRepainAsync(CompletionHandler<void()>&&). Or we could have m_drawingArea::forceRepaintAsync try to force repaint async and do the fallback itself of forRepaint(). This way, we could write it here as: m_drawingArea->forceRepaintAsync(WTFMove(completionHandler)) Last approach seems best to me.
Alex Christensen
Comment 3
2020-12-23 12:02:26 PST
Comment on
attachment 400060
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=400060&action=review
>> Source/WebKit/UIProcess/WebPageProxy.cpp:4270 >> + callAfterNextPresentationUpdate([completionHandler = WTFMove(completionHandler)] (auto) mutable { > > We could probably take the background activity here since sendWithAsyncReply should take a background activity anyway.
callAfterNextPresentationUpdate takes a background activity, so both are unnecessary now.
Alex Christensen
Comment 4
2020-12-23 12:25:14 PST
Created
attachment 416723
[details]
Patch
Alex Christensen
Comment 5
2020-12-23 12:32:48 PST
Created
attachment 416724
[details]
Patch
Alex Christensen
Comment 6
2020-12-23 15:22:52 PST
Created
attachment 416726
[details]
Patch
EWS
Comment 7
2021-01-05 12:38:03 PST
Committed
r271171
: <
https://trac.webkit.org/changeset/271171
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 416726
[details]
.
Radar WebKit Bug Importer
Comment 8
2021-01-05 12:39:17 PST
<
rdar://problem/72824993
>
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