[Webkit-unassigned] [Bug 69515] New: [Qt] Parallel imagedecoders

[bugzilla-daemon at webkit.org]

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

           Summary: [Qt] Parallel imagedecoders
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Images
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: zoltan at webkit.org
                CC: loki at webkit.org, kling at webkit.org


Created an attachment (id=109942)
 --> (https://bugs.webkit.org/attachment.cgi?id=109942&action=review)
aproach #1

Hey!

I made some investigations on how we can do imagedecoding on dedicated thread. I tried to use WebCore imagedecoders instead of current QImageDecoder implementation, because apparently it is the only way to a generic solution. 

I upload the patch for discussion and not for review, so please don't comment style issues and other violations. :)

About my current implementation:

* 1st I had to change to WebCore's imagedecoders, it was simple. QtWebKit is working well with WebCore's imagedecoders since both approach are using the same system libraries on my system.
* 2nd I had to change QPixmaps to QImages since unfortunately, QPixmap doesn't tolerate manipulating images from thread. (Unfortunately, this brings some performance loss, see below.)
* 3rd I added a dedicated worker thread with a queue for image decoding.
 * We're doing the imagedecoding in the mainthread until we have determined the size (w,h) of the image then we choose to work either in the mainthread or in the workerthread.
 * I tried to avoid copying the raw image data to the thread, but in this case I had to use locks (I didn't remove ReadWrite lock implementation from this patch, but it isn't used currently.) and it didn't show satisfying performance results. (e.g. mainthread had to wait for imgdecoding completion at a point)
 * In this patch I'm copying the raw data to the thread (memory consumption :( ), so I can avoid locks, which leads to performance gain in some cases.
 * We can render images (what has been decoded by worker thread) only when the whole image is decoded, so WK with this patch won't show the part of the image until decoding is fully finished. (This is a limitation of decoderlibs e.g. JPEG, we can't access decoded data during decoding.)

* Note: the patch doesn't work for cases that trigger decoding from main thread in case of big images (width||height > 2000px) e.g. drag and drop image with mouse
* Note: I chose 2000px for size limit, because I didn't measure performance gain for usual size (500px-100px) images.
* Note: I commented out GIF imagedecoding for the present.
* Note: WebCore.pri contains paths to my local png1.5.4 library because I had problems with png1.2 in threaded case.

Some numbers:

* Test case (goal to measure performance gain): 3 big (decoding on workerthread) and 3 small image (decoding on mainthread)
 * http://zoltan.sed.hu/WebKit/methanol_imgdecoder/sample/images.htm
 * Reference: avg 2770 ms +/-0.3% 
 * ThreadedImageDecoding: avg 1432 ms +/-4.4%
 * The results looks pretty cool!

* Test case (goal to measure overhead of the patch): simple Methanol run with 24 locally mirrored popular sites from Alexa top 100 (server: apache)
 * http://zoltan.sed.hu/WebKit/methanol_imgdecoder/fire.html?iter=1
 * Reference: avg 9180ms +/-3.3% 
 * Threaded: avg 12465ms +/-7.5%
 * In this case threaded version didn't run since Methanol doesn't contain big enough images.
 * The results looks woeful.
  * QPixmap -> QImage change
  * Conversions 
  * Data copying
  * Other?

I just want to talk about my approach... What could we do to decrease the overhead of the patch? Does it make sense to use QImage? etc...

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