Do you have statistics on how much total time rendering flickr.com is in CSS/Style code at all? I believe it to be very low.
-eric On Mon, Jun 6, 2011 at 1:16 PM, Kulanthaivel Palanichamy <kulanthai...@codeaurora.org> wrote: > Hi All, > > At Qualcomm Innovation Center we have been working on a parallel algorithm > for CSS styling and wanted to see if there is any interest in the > community to see it implemented in WebKit. The overall idea is that we > replace CSS matching and styling with a parallel implementation assuming > there is a barrier before and after the computation. CSS style application > will be performed by the main thread, such that we avoid the need to make > thread safe data structures accessed in other passes. The algorithm is > task-based, so we would need to implement a thread pool and a simple task > scheduler (or maybe use an existing one). > > In particular, our algorithm requires modifying Element::recalcStyle() and > some of the methods it invokes. Code that calls Element::recalcStyle() > will not have to be changed. By the time Element::recalStyle() returns, > all threads involved on the parallel CSS styling have completed their > execution. Effectively, there is a barrier when Element::recalcStyle() > begins and another before it returns. > > Our experiments show that our CSS computation for complex websites scales > rather well. For example, we observed that, for flickr.com, Webkit spends > 75% of its time in CSS doing CSS matching. Thus, our algorithm would give > a maximum speedup of 1.6X on 2 cores and 2.3X on 4 cores. > > Please let us know whether this would be of interest to the community. > > > -Kulanthaivel > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev