Bug 212269 - Make WebPage::ForceRepaint use CompletionHandler instead of VoidCallback
Summary: Make WebPage::ForceRepaint use CompletionHandler instead of VoidCallback
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alex Christensen
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-05-22 11:08 PDT by Alex Christensen
Modified: 2021-01-05 12:39 PST (History)
11 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Christensen 2020-05-22 11:08:16 PDT
Make WebPage::ForceRepaint use CompletionHandler instead of VoidCallback
Comment 1 Alex Christensen 2020-05-22 11:09:21 PDT
Created attachment 400060 [details]
Patch
Comment 2 youenn fablet 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.
Comment 3 Alex Christensen 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.
Comment 4 Alex Christensen 2020-12-23 12:25:14 PST
Created attachment 416723 [details]
Patch
Comment 5 Alex Christensen 2020-12-23 12:32:48 PST
Created attachment 416724 [details]
Patch
Comment 6 Alex Christensen 2020-12-23 15:22:52 PST
Created attachment 416726 [details]
Patch
Comment 7 EWS 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].
Comment 8 Radar WebKit Bug Importer 2021-01-05 12:39:17 PST
<rdar://problem/72824993>