846520 - Brainstorming faster display-list processing

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Gecko can drive 60fps repainting of nontrivial UI on the lowest-end smartphone chipset available right now.  That's something to pat our backs about!

However, we have a fixed budget of 16ms to paint each frame.  After we get past speedbumps like sync reflows and excessive buffer churn, display list usually shows up pretty significantly in profiles, 20-25% or so.  Actual paint time is usually considerably lower.  It's awesome that our code is smart enough to avoid painting, but we sometimes have to give up gfx features like resampling images or effects to fit inside that 16ms.  Any "baseline" costs like display-list processing we can shave off leaves more room for fancier UI.

It would be nice if we could do this without trading off minimal repainting, but if we can dumb down invalidation and get the processing cost to say 5%, spending an additional say 5% time in repainting, we've got a net win.  So we should consider that.

Display list construction is pretty heavily micro-optimized, so I expect diminishing returns from more micro-optimization.  Still worth investigating though, especially through on-phone profiles where perf characteristics will be different.  I don't think anyone has gathered high-quality profiles of display-list processing on-phone yet.

Beyond that ... ???  I'm not an expert on the code, so just throwing out some things

Try building and optimizing the list in a single pass, instead of doing two passes?

Try retaining display lists between paints and incrementally rebuilding them?

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I should add that this is totally orthogonal to optimizations where we can skip display-list processing entirely, like empty transactions.  Even if display-list processing only costs 5%, say, it would be nice to skip it when we can.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm working on bug 841192 which should help a bit --- a lot, on pages with a lot of small overflow:hidden elements, like the email app's message list.

Comment 3

[Dietrich Ayala (:dietrich)]

Roc, what impact did bug 841192 have? Can this be closed, or are these optimizations worth pursuing?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Let's leave it open.

Comment 5

[Mayank Bansal]

bug 1404181 and the small-dl effort did majority of the work outlined in comment #0.
Closing this as there is no concrete way forward here.