Created attachment 403671 [details] test content [GTK][WinCairo] position:fixed layers are unnecessarily repainted by scrolling main content layer 1. Start MiniBrowser 2. Enable repainting counter [WinCairo] Menu → Debug → Show Compositing Borders [GTK] prefereces... → Draw compositing indicaters 3. Open the test content 4. Scroll down by mouse wheel Actual: The repainting counter of position:fixed layer is rapidly increasing. Expected: No such repainting
I confirmed Mac port MiniBrowser doesn't have this issue.
Created attachment 403672 [details] [Screenshot] GTK port
DrawingAreaCoordinatedGraphics::updatePreferences is enabling settings.setAcceleratedCompositingForFixedPositionEnabled if acceleratedCompositingEnabled. https://trac.webkit.org/browser/webkit/trunk/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp?rev=263259#L251 > // Fixed position elements need to be composited and create stacking contexts > // in order to be scrolled by the ScrollingCoordinator. > settings.setAcceleratedCompositingForFixedPositionEnabled(settings.acceleratedCompositingEnabled()); This code was added by Bug 154100 – [ThreadedCompositor] position:fixed elements do not have their own layers when threaded compositor is enabled.
WebChromeClient::createScrollingCoordinator always returns nullptr in GTK port. Is ScrollingCoordinator really used?
(In reply to Fujii Hironori from comment #4) > WebChromeClient::createScrollingCoordinator always returns nullptr in GTK > port. > Is ScrollingCoordinator really used? I think tt's used when AC mode is forced, try with WEBKIT_FORCE_COMPOSITING_MODE.
Good to know. Thank you for letting me know that. I confirmed GTK port doesn't exhibits this issue if WEBKIT_FORCE_COMPOSITING_MODE=1.
Created attachment 403750 [details] Patch
This is the simplest solution 😅
Created attachment 403752 [details] test content 2 position:fixed doesn't work fine in this test case with the proposed patch. This seems a regression of the patch.
By testing the patch with WinCairo, I found more problems for it: https://www.youtube.com/ The side menu isn't solidly fixed while scrolling the main part. https://www.yomiuri.co.jp/ It still exhibits the unnecessary repainting issue for position:fixed elements.
Created attachment 403755 [details] test content (position:fixed element on other layer) (In reply to Fujii Hironori from comment #10) > https://www.yomiuri.co.jp/ > It still exhibits the unnecessary repainting issue for position:fixed > elements. If a position:fixed element is placed on other layer, it has own layer even if setAcceleratedCompositingForFixedPositionEnabled is off.
Created attachment 403761 [details] WIP patch If acceleratedCompositingForFixedPositionEnabled is on, it's simple because all position:fixed elements are compositing. However, if acceleratedCompositingForFixedPositionEnabled is off, only some position:fixed elements are compositing. It makes things complicated. This WIP patch works fine for WinCairo WK2 because its acceleratedCompositingForFixedPositionEnabled is on. But, WinCairo WK1 still exhibits the issue for Comment 11 test case.