1732594 - Browser freezes. 2.0s BHR detected hang

Status: NEW

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

Description

[Karl Dubost💡 :karlcow]

Basic information

Steps to Reproduce:

1. Go to https://freeyourmusic.com/
2. Scroll to the bottom

Expected Results:
Be able to interact with the site

Actual Results:
Everything is frozen, any actions take a long time to execute.

---

More information

Profile URL: https://share.firefox.dev/2XUU6bG

Basic systems configuration:

OS version: macOS 11.6 (20G165)

GPU model: Intel Iris Plus Graphics 1536 Mo

Number of cores: 2 GHz Intel Core i5 4 core

Amount of memory (RAM): 16 Go 3733 MHz LPDDR4X

Comment 1

[Markus Stange [:mstange]]

There's a "slot machine wheel" with 3d transforms at the bottom. My guess is that we're creating too large intermediate surfaces, or too many.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Nicolas Silva [:nical]]

That slot machine wheel thing at the bottom of the page causes us to produce about three thousand draw calls and render into a bit under 200 alpha targets and 60-ish color targets.

Kvark looked at another css 3d transform issue recently-ish.

Comment 4

[Nicolas Silva [:nical]]

Here is anoter profile with samples (I had to switch to software webrender to not bring the window manager to its knees). https://share.firefox.dev/2Z8FOVu

Comment 5

[Dzmitry Malyshau [:kvark]]

There appears to be a few things in play, some independent of the 3D transforms.

One thing is - all of the alpha passes there (could reach a hundred) are for rendering box shadows and clips. Maybe we can reduce the size of those targets if we see that the result is very low-frequency (in terms of gradients).

Another thing - there is a lot of 8K color render targets. I'm seeing the following on one of them:

composite_mode: webrender::picture::PictureCompositeMode::Filter(webrender::internal_types::Filter::Opacity(webrender_api::PropertyBinding<f32>::Value(0.200000003), 0.200000003)),

So at least some of them are due to opacity filters. Maybe we can optimize those to be pass-through?

Finally, I see that the world-screen bounding rect of those render tasks (that need 8K targets) are quite small:

  clipped_bounding_rect: euclid::box2d::Box2D<f32, webrender_api::units::WorldPixel> {
    min: euclid::point::Point2D<f32, webrender_api::units::WorldPixel> {
      x: 214.919266,
      y: 1392.61389,
      _unit: core::marker::PhantomData<webrender_api::units::WorldPixel>
    },
    max: euclid::point::Point2D<f32, webrender_api::units::WorldPixel> {
      x: 709.08075,
      y: 1447,
      _unit: core::marker::PhantomData<webrender_api::units::WorldPixel>
    }
  }

This is roughly 500x50.
So one idea I'm going to try out is more aggressively scaling down the tasks if we see that the local size is much bigger than the screen size.

Assigning on myself for now to continue investigation, but may re-assign later.

Comment 6

[Dzmitry Malyshau [:kvark]]

nical, please check out this RD capture - https://drive.google.com/file/d/1RSHY8gCUgznqhSIUg3zvLFb-vXl7pXn9/view?usp=sharing
Here is a text dump in case the capture can't be replayed - https://pastebin.mozilla.org/bA62sEe7
Notice there 232 alpha targets, many (if not most) are 2K x 2K. Roughly look like this - https://imgur.com/a/JJUTnGH

Comment 7

[Dzmitry Malyshau [:kvark]]

Attachment: WIP: Bug 1732594 - Reduce WR render task sizes if they are much bigger than needed

Comment 8

[Dzmitry Malyshau [:kvark]]

Glenn, based on this test, looks like the render target scaling doesn't work for text specifically. Is this known? Sounds like it would be an issue today without my PR.
This is from the try push of my change.

Comment 9

[Glenn Watson [:gw]]

It's not known specifically, but also not surprising to me, given the mess that is all the target scaling code has become.

I'm currently working on refactoring how we handle bounding rects of pictures, shadows/offsets, raster roots, target scaling. It's a big task, and it won't be done for a while yet, but I expect that to resolve a lot of the correctness issues we have related to bounding rect inflation, scaling factors etc (or at least, make it more tractable to fix bugs such as text scaling).

Comment 10

[Dzmitry Malyshau [:kvark]]

Ok, that's good to know! I'm hoping this isn't going to take many months to land, since I was quite excited about this simple fix (for this bug) that would universally make us faster in a lot of hard cases.
Do you have a bug number describing that work? Could you block this one on that bug? Thanks!

Comment 11

[Glenn Watson [:gw]]

I've created a bug for this, and marked it as blocking this. My rough estimate for that work is ~1 month, but there are some unknown unknowns to be worked through yet.

Comment 12

[Glenn Watson [:gw]]

This appears to be working well for me on nightly now, the allocated render target count is 3x color and 2x alpha, which is reasonable for the number of surfaces and effects this page requires. Are you able to confirm?

Comment 13

[Markus Stange [:mstange]]

The bottom of the page still makes my browser jank a lot.

Comment 14

[Dennis Schubert [:denschub]]

The site is no longer completely unusable. This is still a valid perf issue, but probably not a WebCompat priority.

Comment 15

[Bob Hood [:bhood]]

Since this an S2, I've re-assigned to somebody who actually works at Mozilla.

Comment 16

[Glenn Watson [:gw]]

The GPU usage looks really good to me now, it's < 3 ms at the bottom of the page. I do see some slow frame builds (~12 ms some cases) but overall the performance seems good to me without noticeable jank. Markus, could you get a profile or try to identify what's causing the jank on your machine?

Comment 17

[Markus Stange [:mstange]]

It seems much better now that when I tried it in comment 13. Here's a profile: https://share.firefox.dev/3807OPn
It shows a fair amount of CPU usage both inside frame building and in the renderer.

Comment 18

[Gregory Pappas [:gregp]]

Profile from a low end machine https://share.firefox.dev/37b1sMz