2012/8/21 James Robinson <[email protected]>: > > - James > After reading your writing, I could understand why Chromium team is implementing deferred image decoder. I definitely agree on your opinion that we cannot accept the implementation which worsens user experience.
As mentioned above, we have two approaches to buy more time to decode an image off the main thread. We prototyped the approach which moves the start line forward. We had to change CachedImage, RenderImage, RenderObject and so on, so that parallel image decoder has the information to decide which image should be decoded prior to other images. However, we finally gave up this approach because it caused tight coupling among many modules and could not ensure enough time to decode images off the main thread. Consequently, deferred image decoder seems to be the best approach to decode an image off the main thread. However, Google's deferred image decoder seems to depend on SkPicture, so other ports can not reuse it. My company, Company100 has focused on WebKit parallelization to improve performance. We have a plan to implement recording and replaying of GraphicsContext, which is similar to SkPicture of Skia or recording surface of Cairo. Buffering GraphicsContext commands could allow us a number of serial optimizations such as collapsing draws, dropping fully obscured draw calls as you mentioned as well as parallel optimizations such as parallel painting of each layer of GraphicsLayer tree and off the main thread canvas rendering. For now, we suggest that each platform decides whether to enable parallel image decoder or not at the compile time using ENABLE(PARALLEL_IMAGE_DECODER) guard. Parallel image decoder can be removed from WebKit once we have a platform independent deferred image decoder. Regards, DS Huang _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
