Hi, thanks for all of your for your help.
> I would be worried about correctness - if painting is not complete by > the time the paint method returns, then you could get flashes of > intermediate states showing up onscreen. We plan to do the painting on a background image. When all the painting finished, the image appears on the screen. We don't need to duplicate the dom tree, only the painting commands should be sent to the thread. We could keep the changes below RenderContext level in this way. > I suspect resources like fonts or images *will* need to be duplicated, > either that or use thread-safe refcounting and copy-on-write. The > internal state of images can be mutated by progress in loading the > image, or by ongoing animation. No need thread safe refcounting, since when a request object is processed by the thread, the thread sends back the request object to the main thread, which can release the resources. It is necessary, since memory alloc / free pairs on a memory chunk must be executed by the same thread. We can post a series of commands to the thread message queues (including the main thread), which will processed later (no wait is necessary). > 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. 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev