[webkit-dev] Status of multithreaded image decoding

[Dong Seong Hwang]

2012/8/21 James Robinson <jamesr at google.com>:
>
> - 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