Clips, clip chains, AGR and ASR are built or computed every time building display list. They can be saved by retaining these information on the frame tree, and it also makes retaining display items easier. The basic idea is as following: - Keep them in one struct, and keep the struct in an arena with a free list. The free list is used to collect released struct and reuse them later. - The struct is owned by the frame that is AGR or ASR, or with clips. - Set the struct as a property of the frames. - The struct is built during building display list, but is retained and reused. - The struct is invalidated for the changes of clips, AGR, and ASR. - Once a frame is changed for the reasons mentioned above, the structs on the subtree are all invalidated. - Mark the frame has an invalid state. - Rebuild all structs for the subtree during building display list.

Thanks, Thinker. Per talk today, CJ will be doing initial analysis on bug 1356519 and bug 1356573 and see how much perf gain we can get from these 2 approaches. For bug 1357010, as you mentioned, it's probably easier and could be a good first bug to start off. I'll look for someone from my team to work on it. Thanks.

I'm having to do some similar work as part of retained display lists. I wrote up some prototype code that (I think) solves my problems, see commits 7accc52d7d8e -> 0b368eb8e0a5 on https://hg.mozilla.org/users/mwoodrow_mozilla.com/retained-dl. AGRs and ASRs are retained, but we recompute the ancestors each time, so we don't need to do any invalidation of these. Any used AGR/ASR gets cleaned up with refcounting. I currently have them stored on the heap, but we could put them into an arena if necessary. Clips are also retained on the heap, but we don't attempt to re-use them for following paints (again, no invalidation needed). If you just want clips to stay alive so we can retain display items, then this may be sufficient. If you actually want to cache clips to avoid the cost of building them again on future paints, then we need something more advanced.