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

Steps to reproduce:

1.enable WR. Enable picture caching
2.Go to https://codepen.io/ivorjetski/pen/xMJoYO
3. Click the cursor inside the CSS panel/column
4. Scroll with the mousewheel

Actual results:

scrolling lags like crazy. Lag means that after you stop scrolling, the panel/column will continue to scroll.

Expected results:

not so

https://perfht.ml/2NaxOsA

It looks like the RenderBackend thread is really struggling (no markers unfortunately), and that's slowing everything down.

Scene building is pretty slow (frequently 30ms+), but looks like half of that time is waiting on the lock to scene swap.

The main thread of the GPU process is super busy too, spending more than 50% of it's time waiting in wr_api_hit_test.

Content process side actually looks pretty reasonable (not fast, but ok).

Next step would be to investigate the display lists being created, and figure out why the render backend is so slow on it.

So this has something to do with the glass/lemon image being rendered. I took another profile, where i deleted the HTML code,and the JS code, leaving only the CSS code. This effectively means no actual image is being rendered on the screen.

The profiles are when i scroll the CSS pane with the mouse wheel

Profile with the image: https://perfht.ml/2N8XPZ5
Profile without the image: https://perfht.ml/2N861sK

meant to add: Without the image, the scrolling is very smooth. Its like if the image is there, it will repaint on every mouse wheel scroll.

The render backend is saturated with work but there' isn't much that stand out. Looks like general cache-misses and vector allocations spread through the profiles making everything kinda slow without having one particular culprit.

Among other things, we spend an unusually high amount of time (13%) in <webrender_bindings::bindings::APZCallbacks as webrender::renderer::SceneBuilderHooks>::pre_scene_swap on the scene builder thread.

picture caching doesn't help when scrolling the middle or right panels (the area of the complicated CSS thing gets invalidated).
This is the kind of complicated for which we either need to imporve the speed of every part of webrender, or get better at caching to the point that scrolling the source panels never invalidates the complicated demo part.

(In reply to Nicolas Silva [:nical] from comment #4)

Among other things, we spend an unusually high amount of time (13%) in <webrender_bindings::bindings::APZCallbacks as webrender::renderer::SceneBuilderHooks>::pre_scene_swap on the scene builder thread.

All this does is basically acquire the APZ tree lock, so if it's spending a lot of time there, I guess that indicates there is contention for that lock.

It would be interesting to know what the other threads that use the APZ tree lock (the RenderBackend thread and the GPU process main thread, as per the table here) are doing while the scene builder is in pre_scene_swap.

(And if it's the render backend thread that we're waiting on, then bug 1542056 / bug 1580178 might help.)

latest profile: https://perfht.ml/3dkLbD1
And here I scroll really fast : https://perfht.ml/2ws5HkB

This is much better now.
:Nical, should this bug be closed, or do you see scope of more wins here?

Picture caching much better handles this page now. Let's close.

Closing per comment #8