Closed Bug 1477369 Opened Last year Closed 2 months ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: jrmuizel, Assigned: jrmuizel)

References

(Blocks 2 open bugs)

Details

Blocks: wr-perf
Priority: -- → P2
This is mostly just animated transforms so we should be able to run the page very well.
For the record these animations are built using http://animejs.com
Depends on: blob-recoord
Depends on: 1494408
No longer depends on: blob-recoord
Priority: P2 → P3
Assignee: nobody → jmuizelaar
Priority: P3 → P2
Depends on: blob-recoord
Assignee: jmuizelaar → a.beingessner
Assignee: a.beingessner → nical.bugzilla
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.
There's a large amount of invalidation caused by blob images changing size. Blob re-coordination is needed to let us resize blobs.
Should profile this to see if it's acceptible
Flags: needinfo?(jmuizelaar)

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

Depends on: 1513521
Flags: needinfo?(jmuizelaar)

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.

Assignee: nical.bugzilla → jmuizelaar

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

Priority: P2 → P3

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.

(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.

#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.

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

The clip patch landed.

Priority: P3 → P4
Blocks: wr-68
No longer blocks: stage-wr-trains
Priority: P4 → P2
Blocks: wr-69
No longer blocks: wr-68
Blocks: wr-70
No longer blocks: wr-69

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.

Blocks: wr-71
No longer blocks: wr-70

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.

Let's close it.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.