1091763 - BuildDisplayList takes 10ms when we need to repaint the status bar

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Benoit Girard (:BenWa)]

Profile:
http://people.mozilla.org/~bgirard/cleopatra/#report=709147a1e2f4774c05ebcfcd22808dc29105b8c7

The network indicator is an animated PNG but we're spending a considerable amount of resources just building a display list to update it.

Why is building a display list, a step we must do for every paint, take about 10% CPU time? This is for the system app which display very little content to the user.

Comment 1

[Benoit Girard (:BenWa)]

We're going to reduce the frame-rate for the network-activity widget so it wont be 10%. However each time a frame is required we're going to consume ~10ms building a display list for the system app. We should investigate why that's so high still.

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Gregor, this is a lot of time, and a lot of CPU.  Is it something that's worth looking at for 2.2 do you think?

Comment 3

[Benoit Girard (:BenWa)]

It’s worth noting that this is a very specific example of the ‘we spend to much time in the display list building code’ problem. Starting by optimizing this test case would be great particularly if we can speed up this step in general.

Comment 4

[Gregor Wagner [:gwagner]]

(In reply to Milan Sreckovic [:milan] from comment #2)
> Gregor, this is a lot of time, and a lot of CPU.  Is it something that's
> worth looking at for 2.2 do you think?

Yes, this issue came up multiple times now and we should fix it for good.

Comment 5

[Michael Henretty [:mikehenrty][:mhenretty]]

Benoit, could this slowness in building the display list have anything do with bug 1091777? Should we re-profile now that this has landed?

Comment 6

[Benoit Girard (:BenWa)]

It's unlikely, that bug changes what we do during the rasterization phase. This bug is about the display list phase being too slow.

Comment 7

[Michael Henretty [:mikehenrty][:mhenretty]]

Matt, could you help us investigate why building the display list with the animated gif in the statusbar takes 10ms? I am here to support, but sadly I don't know how to begin tracking this down.

Comment 8

[Matt Woodrow (:mattwoodrow)]

We build display lists for the entire (potentially) visible area, not just for changed things, so display list building time is generally proportional to the complex of the page.

It looks like NS_NewURI (from nsImageRenderer::PrepareImage when using -moz-element) accounts for almost 1/10th of this time, which is maybe something that could be fixed.

Nothing much really stands out from the rest, just processing a large frame tree looking for display items.

We have ideas to reduce display list building time, but these definitely aren't going to be suitable for 2.2.

We also have an optimization that would let us skip display list building entirely if an animated gif is the only change. You could look at why we're not hitting that to solve this specific bug.

For that (for an <img>), we're expecting the animated image frame notification to arrive at [1], and InvalidateLayer should request a SchedulePaint with PAINT_COMPOSITE_ONLY. We'd also need no other SchedulePaint requests to come in from other things. This only works (currently) with <img> and the xul imagebox, but we could support background images too if necessary.

Comment 9

[Matt Woodrow (:mattwoodrow)]

[1] http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsImageFrame.cpp#745

Comment 10

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #8)
> It looks like NS_NewURI (from nsImageRenderer::PrepareImage when using
> -moz-element) accounts for almost 1/10th of this time, which is maybe
> something that could be fixed.

I believe this is the problem was alluding to when filing this bug. Benoit, can you confirm?

Comment 11

[Benoit Girard (:BenWa)]

Not in particular. Just anything that speeds up updating the status bar by either avoiding the display list or making it cheaper. I imagine this would help but 1/10th speed improvement isn't really much.

Comment 12

[Gregor Wagner [:gwagner]]

Unblocking since its unclear what the user impact is.

Comment 13

[BMO Automation]

Firefox OS is not being worked on