1612133 - Lots of time spent display list building for hit testing on engadget.com on android

Status: NEW

(Core :: Web Painting, defect, P3)

Description

[Jamie Nicol [:jnicol]]

Profile: https://profiler.firefox.com/public/b78769586ba448fb097eb18e5d11b76ae5020b85/calltree/?globalTrackOrder=0-1-2&hiddenGlobalTracks=1&hiddenLocalTracksByPid=21629-0&localTrackOrderByPid=21629-3-0-1-2~21797-0~21769-0~&thread=5&v=4

Comment 1

[Kris Taeleman (:ktaeleman)]

Non-webrender profile: https://perfht.ml/2RBWhL5

Comment 2

[Jamie Nicol [:jnicol]]

For context, Kris noticed this as some jankiness whilst scrolling engadget on fenix with webrender enabled, and wasn't sure he saw it with webrender disabed. Looking at the profiles I'm assuming the display building is the problem. The renderer thread appears to be doing okay, but perhaps is more likely to jank when the content process main thread is so busy, whereas in layers the compositor thread has less work to do so handles it slightly better.

Comment 3

[Miko Mynttinen]

This is quite unfortunate: the website has an advertisement that sets a timer calling Document.elementFromPoint(), which will build a display list as part of nsLayoutUtils::GetFramesForArea(). This will be slow because main thread hit testing does not use retained display lists. Long term solution would be to figure out a way to use retained display lists for hit testing (bug 1288096).

I think we can also speed up the current non-retained hit testing by reducing the overhead of creating the hit test items (bug 1612318).