Hi Thinker Gal and I were discussing this same problem last week, and decided on the same solution.
The main problem is that display item positions are relative to the screen (or the nearest transformed ancestor) so they change when we scroll. This means we'd have to invalidate the cache for all scrolled frames, or modify the cached items. What we decided on instead was to make the scroll root a 'reference frame' so that all display items below it have coordinates relative to that instead of the screen. This should mean that we no longer have to modify the display items when we scroll. I was planning on working on this in about 2 weeks, once I've finished up with my current set of graphics bugs. I'm happy to discuss this further though if you want to get started sooner than that. The rest of the proposal looks good, but you'll at least need to invalidate the cached items when we get a style change. Some items (like tables) will require special handling too. - Matt On Thursday, August 22, 2013 12:52:54 AM UTC+12, Thinker K.F. Li wrote: > I am doing profiling for several Apps on b2g, and have found near 1x% ~ > > 20% of CPU time when scrolling are spent on building display list. So, > > I think we can use cache for display lists to save time of creating the > > same display items repeatedly. > > > > I just have done some studies, and have a rough idea. My idea is > > attaching the caches with frames. When a frame is > > MarkIntrinsicWidthsDirty()ed, the attached cache is deleted if any. For > > the frames that their parents are MarkIntrinsicWidthsDirty()ed for last > > reflowing, but not themself, the results of their BuildDisplayList() are > > kept in the cache. I guess most animation will modify the same set of > > subtrees repeatedly. So, we can save time for building display lists. > > > > Feedback is welcomed! > > > > -- > > Sinker > > -- > > 天教懶漫帶疏狂 _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
