User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

1. Set up clean profile
2. Change "gfx.webrender.all" to "true"
3. Disable Enhanced Tracking Protection
4. Visit https://f1sport.auto.cz/clanek/ztracime-hodnoti-binotto-ktery-neni-tak-optimisticky-jako-vloni

Actual results:

CPU and GPU usage is much higher using WebRender than with Open GL compositing. Please check following numbers.

Compositing OpenGL:
WebContent process 30% CPU 0% GPU
Main Process 10% CPU 2% GPU

Compositing WebRender:
WebContent Process 30% CPU 0% GPU
Main Process 30% CPU 40% GPU

Expected results:

CPU and GPU usage should be similar to Open GL compositing.

I'm using 27" 5K iMac (late 2015) with window's size 1900x1400 scale 2.0.

If I made comparison with latest Safari, it's able to manage it with these numbers:
Web Content Process 10% CPU 1% GPU
Main Process 1% CPU 0% GPU

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Something on this page is causing us to continuously re-build the display list and the scene, even though nothing visibly changes.

This causes the render backend, renderer and GPU to do some work but picture caching is working well here, so it's not much (it should be zero of course and would be if the content process wasn't continuously re-building the DL).

There's a setTimeout in the page's scripts that is continuously fired, which looks related to ads. Without webrender I suspect the invalidation code in layout figures out that nothing changed earlier while it happens later down the pipeline for webrender (and even if picture cache slices don't change we still recomposite them continuously, generating some gpu work).

I'm going to track this one under wr-displaylist-perf but it's more over-invalidation than DL building perf per-se

I enabled the log that comes with the CRR_DEBUG debug macro in RetainedDisplayListBuilder.cpp, but we get many new displaylists continously without this log showing up.
I also logged when a dom animation ticks (dom/animation/Animation.cpp) and these don't show up either.
There are still the setTimeout and setInterval handlers firing in JS land, but I don't know yet how to see what they are changing.

This page seems to run well now.

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

This page seems to run well now.

Hi Glenn, thank you for your efforts. You're right. I got these numbers in Firefox Nightly:

Compositing WebRender:

• Main Process 18% CPU 2% GPU
• WebContent Process 8% CPU 0% GPU

Somehow Safari 15.6.1 is able to manage it with unbelievable low resources:

• Main Process 1% CPU 0% GPU
• WebContent Process 7% CPU 0% GPU