Bug 225512 - [GTK] Use always async scrolling in accelerated compositing mode
Summary: [GTK] Use always async scrolling in accelerated compositing mode
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
: 221067 (view as bug list)
Depends on: 225740
Blocks: GLibPerformance
  Show dependency treegraph
 
Reported: 2021-05-07 07:48 PDT by Carlos Garcia Campos
Modified: 2022-09-28 08:19 PDT (History)
14 users (show)

See Also:


Attachments
Patch (7.61 KB, patch)
2021-05-07 07:53 PDT, Carlos Garcia Campos
Hironori.Fujii: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2021-05-07 07:48:27 PDT
We currently use async scrolling only when the hardware acceleration policy is set for always, but not when entering accelerating compositing mode in ondemand policy.
Comment 1 Carlos Garcia Campos 2021-05-07 07:53:18 PDT
Created attachment 427996 [details]
Patch
Comment 2 EWS Watchlist 2021-05-07 07:54:10 PDT
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See https://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment 3 Fujii Hironori 2021-05-09 19:12:45 PDT
Comment on attachment 427996 [details]
Patch

Honestly speaking I prefer the approach doing that in WebPage without platfrom #if (attachment#420247 [details]) rather than in DrawingAreaCoordinatedGraphics with #if PLATFORM(GTK).
But, I don't have time to Bug 225512 now. And, I admit it's a good idea not changing Cocoa-port code for this.
Comment 4 Fujii Hironori 2021-05-09 19:13:54 PDT
*** Bug 221067 has been marked as a duplicate of this bug. ***
Comment 5 Carlos Garcia Campos 2021-05-10 00:39:40 PDT
(In reply to Fujii Hironori from comment #3)
> Comment on attachment 427996 [details]
> Patch
> 
> Honestly speaking I prefer the approach doing that in WebPage without
> platfrom #if (attachment#420247 [details]) rather than in
> DrawingAreaCoordinatedGraphics with #if PLATFORM(GTK).
> But, I don't have time to Bug 225512 now. And, I admit it's a good idea not
> changing Cocoa-port code for this.

Problem is that enter/exit in WebPage doesn't seem to be balanced, enter can be called more than once, and I've seen also exit/enter calls that don't really exit and enter the AC mode. That doesn't happen with the enter/exit calls in DrawingArea.
Comment 6 Carlos Garcia Campos 2021-05-10 02:14:04 PDT
Committed r277258 (237527@main): <https://commits.webkit.org/237527@main>
Comment 7 WebKit Commit Bot 2021-05-13 02:47:20 PDT
Re-opened since this is blocked by bug 225740
Comment 8 Carlos Garcia Campos 2021-05-13 02:49:48 PDT
This is not so easy in the end. with the patch we are now causing that pages enter in Ac mode when there's an iframe, for example, because async frame scrolling is enabled. I need to investigate this further.
Comment 9 Alejandro G. Castro 2021-05-13 03:53:46 PDT
Chris and me are working in checking some regressions since I activated the async mode in WPE testing by default (bug 224596), the problem can be related. Can you send more information of the failures you are seeing?
Comment 10 Carlos Garcia Campos 2021-05-13 04:57:16 PDT
See https://bugs.webkit.org/show_bug.cgi?id=225644. But the test failure is not the only issue I've noticed, as I said before.