---------------------------------------- > Date: Sat, 20 Feb 2010 12:22:02 +0100 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: [webkit-dev] parallel rendering in WebKit > > Hi, > > thanks for all of your for your help. >
>> I'm also curious how this will help overall rendering time. Embedded >> platforms would normally only be displaying one document at a time, so >> how will one thread per document help? > > Not anymore. The UI design of mobile or handheld devices use more and more > html-based content. It is easier for both UI designers (enough to know how > to create html pages) and developers (a browser is needed anyway, and not > need to maintain a separate UI rendering engine). Of course we need > reliable and fast brower engines to achive these features. ( again, with 1Gb of memory right now even iceweasel is lighting up my disk as i try to type in this simple form LOL but not nearly as bad as firefox on a 500M laptop). We have a phone app that has a bunch of pieces made from html with various fake links to point to internal resources and variables. It is easy to write the html but speed is certainly an issue. One part of this time delay seems to be start-up or initialization time and the few times I've profiled this ( java ) I usually end up looking at calls to script compilers and stuff like that but I'm not sure this unrelated thing would likely say much about webkit. You may alrady have to initialize a lot of "Stuff" just to render a simple form with a few buttons and you may be able to reduce that time to make it acceptable in more apps but it will always be slower than using more direct components. Keep in mind that random initialization code to setup parallelism could be much slower than predictable local access even if instruction counts ( and of course ignoring SIMD benefits ) are comparable due to memory architecture. If you only have one CPU the likely benefits would be in things that amount to IO- and I guess that includes use of GPU or scheduling use of contsrained resources or something. Threading of course creates a new class of resource, the lock or mutex, possibly leading to "lock starvation" as many workers compete for one resource. The extreme case being each launched thread holds the same lock for duration of execution thereby forcing them to execute serially and you may even find this improves performance over less synchronized case even when not needed for correctness. I guess offhand from what I've seen initialization and memory access patterns are often ignored components of performance and there is a tendency to think that launching a thread creates a new CPU. > > I can't promise any major gain at this momment, but it seems there is not > any design issue in WebKit, which makes this approach impossible. Wish us > luck :) > > Regards, > Zoltan > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/201469227/direct/01/ _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
