1477369 - http://kasko.arsenal-ic.ua is slow because of blob image

Status: RESOLVED FIXED

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

Description

[Jeff Muizelaar [:jrmuizel]]

https://perfht.ml/2LlkT8L

Comment 1

[Jeff Muizelaar [:jrmuizel]]

This is mostly just animated transforms so we should be able to run the page very well.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

For the record these animations are built using http://animejs.com

Comment 3

[Nicolas Silva [:nical]]

I am not sure this depends on blob image re-coordination. I could be wrong but It looks like many of the animated transforms are not layerized and we end up invalidating a lot when things move.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

There's a large amount of invalidation caused by blob images changing size. Blob re-coordination is needed to let us resize blobs.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Should profile this to see if it's acceptible

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Blob image performance is bad because of bug 1513521. Let's profile again after that's fixed.

Comment 7

[Nicolas Silva [:nical]]

The performance is still pretty bad without double-rasterization. By the look of the blob paint flashing the layerization looks kind of crazy. Among other things it looks like we have a mostly transparent blob of the size of the whole thing on top of the rest. I want to check with renderdoc but I'm having issues getting it to work with Firefox right now.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

I took a look at this again today. I think we can do better by just layerizing more aggressively.

Comment 9

[Matt Woodrow (:mattwoodrow)]

Having a look into some of the invalidations (mainly #screen4 thus far):

• We often resize the blob image, due to changes that are offscreen. The transform outside the SVG is clipped (SVGs are always overflow:hidden), so we can take this into account.

• New content appearing (like a moving car on #screen4) can split the blob into multiple blobs, which triggers large invalidations.

• WebRenderCommandBuilder tracks invalidation using a single rectangle, but the WebRender rust side treats invalidation as a per-tile boolean. This mismatch causes us to frequently invalidate a lot more pixels than we need.

Comment 10

[Matt Woodrow (:mattwoodrow)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #9)

• New content appearing (like a moving car on #screen4) can split the blob into multiple blobs, which triggers large invalidations.

Disabling active transforms stops us from getting splits that invalidate the whole blob, but instead we repaint the changing transform area more.

• WebRenderCommandBuilder tracks invalidation using a single rectangle, but the WebRender rust side treats invalidation as a per-tile boolean. This mismatch causes us to frequently invalidate a lot more pixels than we need.

The blob in question frequently has multiple things moving, and the combined rect covers a lot of tiles. Tracking dirty tiles instead of rects would bring this down somewhat.

Comment 11

[Matt Woodrow (:mattwoodrow)]

#screen5 has similar problems, constant re-layerization cause us to repaint the world all the time. If I disable active layers, then it looks better, but multiple invalidations across the diagonal bridge result in a very large combined invalid rect.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

Matt has a patch that lets us apply the clip on the svg element, that should be enough to make this drop to P4

Comment 13

[Jeff Muizelaar [:jrmuizel]]

The clip patch landed.

Comment 14

[Nicolas Silva [:nical]]

This page (while still tickling the slow frame indicator), has improved a lot since the last time I checked, presumably thanks to the blob clipping changes.

Comment 15

[Nicolas Silva [:nical]]

After Jeff's blob splitting patch, a most of the animations on this pages are running fairly OK. It's still a pretty demanding set of animations so we are not getting a solid 60fps. I don't see outrageous over-invalidation nor insane amounts of layers and rasterization isn't a bottleneck anymore 🎉.

The content main thread is 100% busy (94% in PaintFrame).
I see a lot of "getter" functions showing up in the profile such as:

• mozilla::layers::GetBlobItemData 7.2%
• mozilla::layers::IsItemProbablyActive 7.2%
• nsDisplayItem::GetClippedBounds 8.7%

I haven't looked at the implementation of these but there might be some low hanging fruits to pick.

There are also a number of slowish frames on the renderer thread when there are texture uploads on the computer I'm using to measure which I think can be considered independent from the blobs work.

We could probably close these bug or keep it open refocused around the performance of the layerization code.

Comment 16

[Jeff Muizelaar [:jrmuizel]]

Let's close it.