Closed Bug 1552318 Opened 5 years ago Closed 2 years ago

Categories

(Core :: Graphics: WebRender, defect, P3)

68 Branch
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: sunnyt7, Unassigned)

References

Details

(Keywords: nightly-community, perf)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Just started using Nightly with WebRender enabled. I'm using a 2018 Matebook X Pro i7, with a 27" 4K monitor. I've noticed that page scrolling is a lot more smooth compared to the beta or stable versions. However, I've come across some pages that are laggier than normal. Here is an example of one: https://templates.cartflows.com/ebook-landing/

Component: Untriaged → Graphics: WebRender
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86_64
Blocks: wr-perf
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
OS: Windows 10 → All
Hardware: x86_64 → All
Summary: Web page super laggy → Scrolling is super laggy on https://templates.cartflows.com/ebook-landing/

Thanks for the report. It looks like this page has really high GPU times and picture caching is not working.

Flags: needinfo?(gwatson)

No problem. In case it helps at all, here are a couple more of their example pages that are laggy:

https://templates.cartflows.com/product01-landing/
https://templates.cartflows.com/organic-tea-landing/

Will see if I came across any other websites as well.

Getting a good amount of lag at the top section of https://basicscroll.electerious.com/ (though not as bad as the pages listed above)

Priority: -- → P3

I checked these pages with my current local patches that improve picture caching. They still seem to be slow (nothing is being successfully cached, and there are a lot of blend layers). There's no obvious reason for these pages not to cache correctly, so I'll take this bug and work out why they aren't caching correctly with the new picture caching work.

Flags: needinfo?(gwatson)
Assignee: nobody → gwatson

I tested this again on a recent nightly - it's still really laggy and failing to cache tiles correctly. I'll try to investigate this week or next to determine what's causing the surface caching to fail in this case.

In case its helpfull... please find perf profiles for the first page mentione in this bug (it doesnt really feel laggy on my workstation though)

https://templates.cartflows.com/ebook-landing/

Scroll using page-up/down keys
https://perfht.ml/34Av279

Scolled using the mouse-wheel
https://perfht.ml/36tKC6B

The main elements on the page have a long chain of CSS filters (brightness, contrast, saturate, blur, hue-rotate) and also a mix-blend-mode with overlay enabled.

The spatial ID of the stacking context that declares the mix-blend-mode is attached to the root spatial node of the content iframe (rather than the main scroll root). I think this is probably not right in the display list, since it doesn't appear that this picture should be fixed - it should be attached to the scroll root.

Having said that, the overlay mix-blend-mode operates on top of a fixed position linear gradient background, so even if the above was fixed I think this would still fail, since we can't apply mix-blend-mode during the composition of picture cache slices.

I'm still not sure of the exact cause or correct way to handle this case - but it does seem to be quite an edge case with interactions between filters, mix-blend-mode and a fixed position background. I'll try to reduce it to a smaller repro that is more understandable.

Minimal repro case:

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8">
        <style type="text/css">
            .e3 {
                background: blue;
                mix-blend-mode: overlay;
                position: absolute;
                width: 100%;
                height: 100%;
            }
        </style>
    </head>
    <body>
        <div class="e3"></div>
        <h2 style="height: 5000px;">45 days course</h2>
    </body>
</html>

Un-assigning for now, since I won't be working on this in the immediate future. However, I'll pick this up again when working on the wr-caching metabug.

Assignee: gwatson → nobody
No longer blocks: wr-perf

(In reply to Glenn Watson [:gw] from comment #8)

Minimal repro case:

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8">
        <style type="text/css">
            .e3 {
                background: blue;
                mix-blend-mode: overlay;
                position: absolute;
                width: 100%;
                height: 100%;
            }
        </style>
    </head>
    <body>
        <div class="e3"></div>
        <h2 style="height: 5000px;">45 days course</h2>
    </body>
</html>

This scrolls pretty good for me.
Should we RESOLVED WORKSFORME this bug?

Flags: needinfo?(gwatson)

Yep, it runs well for me now too. We did some work to support mix-blend-mode on the root scroll layer some time ago, which is likely what fixed the performance of this case.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(gwatson)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.