[Webkit-unassigned] [Bug 90375] New: Parallel image decoders

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jul 2 05:35:08 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=90375

           Summary: Parallel image decoders
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Images
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: skyul at company100.net


This is an umbrella bug for our new parallel image decoders. Our team at Company 100 has worked on parallel image decoders and resolved several issues addressed in Bug 69515.

About our implementation:
- We parallelize WebCore's image decoders. Currently, only CG does not use WebCore's image decoders so many ports can get performance boosts from this work.
- We used a pool of worker threads (n = number of cores) instead of a single dedicated worker, so that we can decode multiple images simultaneously.
- We support incremental image decoding. It menas we can render images while images are being decoded.
- We avoid the locking overhead as much as possible by copying raw data to and from the decoder thread.
- If we decode image in the main thread (e.g., when the image size is small), we avoid the locking overhead entirely.
- We passed all the layout tests. We have no regression regarding image decoding.


We selectively use parallel image decoders:
- We chose to use parallel image decoders only when rendering HTML image, SVG image, CSS box model background, border and mask. Note that rendering HTML image element in canvas does not use parallel image decoders. Because some of image decoding in WebCore are inherently synchronous, it was not easy to paralleize all image decoding use cases.
- We’re doing the image decoding in the main thread until we have determined the size (w, h) of the image and then we choose to work either in the main thread or in the worker thread. We work in the main thread if the image size is smaller than 262144px (512x512) because the performance is not so good when the image size is small. The current limit is arbitrary, so we need to adjust the limit with more extensive experiments.
- ICO and GIF formats are not supported. These formats support multiple frames, which complciates the implementation of parallel image decoders. Because ICO and GIF images are usually very small, we don't get much performacne gain anyway by supporting these formats.


Results:

* Test Case: DOMContentLoaded (5 times)
 * http://ie.microsoft.com/testdrive/HTML5/DOMContentLoaded/Default.html
 * Reference: 850 ms (stddev: 97 ms)
 * Threaded: 817 ms (stddev: 90 ms)

 * Reference (page cached): 233 ms (stddev 0ms)
 * Threaded (page cached): 146 (stddev 4ms)

* Test Case: 35 Images (5 times)
 * http://www.dorothybrowser.com/test/webkitTest/imgdecode/bgimage-png/test.html
 * Reference: 3759 ms (stddev: 229 ms)
 * Threaded: 3652 ms (stddev: 117 ms)

 * Reference (page cached): 1204 ms (stddev: 11ms)
 * Threaded (page cached): 58 ms (stddev: 48ms)

We will update the result with Methanol test used in Bug 69515.

Dongsung Huang who is the primary of author of our parallel image decoder will upload patches for review in a couple of days once we finish our internal review process.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list