1509604 - Google user experience page uses 80% CPU without any interaction

Status: ASSIGNED

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

Description

[Mayank Bansal]

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

Steps to reproduce:

enable WR
go to https://userresearch.google.com/index.html



Actual results:

Page uses high amount of CPU

https://perfht.ml/2RbFWtO



Expected results:

not so?
Page also uses CPU with non-WR, but in that case its typically 15-20%

Comment 1

[Jeff Muizelaar [:jrmuizel]]

A big chunk of this time is spent in vector image drawing. Let's see what Andrew thinks.

Comment 2

[Andrew Osmond [:aosmond] (he/him)]

There is a CSS animation inside the SVG, so we don't rasterize it in the content process and it uses the blob image path. This gets very expensive. After discussing with jrmuizel, if it worked like an inline SVG, we could get the benefit async animations. nsImageFrame::BuildDisplayLayer would need to peek into the image / SVG document and create something like an nsDisplaySVGWrapper instead, and then in theory it would like an inline SVG image. Investigation continues.

Comment 3

[Bobby Holley (:bholley)]

From triage: P2 for investigation, but check back in with a time estimate before implementing.

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

(Note the page has morphed and the SVG was replaced.)

Discussed with jrmuizel. This was already bad with Gecko, as the animated SVG story isn't the best, so this can be de-prioritized. I have written up some design notes on this that I need to tidy up before attaching, but suffice to say, this is not a trivial task and we can (probably) move this to wr-next. In a nutshell we would like to uplift the display items from the child SVG document directly into the parent document (there are also some similar alternatives I've explored, which have their own pros/cons). This would allow the CSS animations optimizations to apply and avoid the display list regeneration / scene rebuilding. Said alternative path for animations should also (in addition) take into account our own internal animated SVG requirements; we use -moz-context-properties to vary the colour of the SVGs.