Bug 40159 - [Qt] Decode images in a separate thread to improve UI responsiveness
Summary: [Qt] Decode images in a separate thread to improve UI responsiveness
Status: RESOLVED DUPLICATE of bug 69515
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Enhancement
Assignee: Nobody
URL:
Keywords: Performance, Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2010-06-04 00:08 PDT by Kevin Simons
Modified: 2012-06-14 02:45 PDT (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Simons 2010-06-04 00:08:58 PDT
Because QtWebKit current decodes images in the main thread, the UI performance suffers while images are being decoded. This is particularly noticeable when examining scrolling performance of image-heavy websites.

Additional details:
- Decoding images in a separate thread should work with the tile-based rendering in QtWebKit. Once images are decoded, tiles to which they belong should be updated.
- It is sufficient to only decode images for which the width/height attributes or CSS style properties are specified in a separate thread if that simplifies layout process.
Comment 1 Wellu Mäkinen 2010-06-04 00:34:08 PDT
Adding myself as CC.
Comment 2 Benjamin Poulain 2010-06-04 05:27:20 PDT
Please also investigate the use of the DSP.
Comment 3 Andreas Kling 2010-06-13 12:47:40 PDT
(In reply to comment #0)
> - It is sufficient to only decode images for which the width/height attributes or CSS style properties are specified in a separate thread if that simplifies layout process.

This should be fine. For most (all?) image formats, we get the geometry from reading the header which is done via separate API.
Comment 4 Benjamin Poulain 2010-06-13 14:17:52 PDT
Is somebody working on this? If yes, please put her/him as assigned.
Comment 5 Markus Goetz 2010-11-12 09:24:35 PST
I was given some thoughts about this some time ago.
Here's what I still remember:
We currently don't do progressive image decoding (AFAIK), so it should be fine to move the data to the other thread when the image has finished loading.
Also there is probably some file size minimum from that it makes sense to do the work in the thread, e.g. the thread overhead is unimportant for bigger images so for those it makes sense to use a thread.
Also I have this in my notes file:
virtual void RenderImage::imageChanged(WrappedImagePtr, const IntRect* = 0);
My thoughts were maybe that this could be called from the decoder thread or something. No idea :) Too long ago.
Comment 6 Zoltan Horvath 2012-06-14 02:45:51 PDT

*** This bug has been marked as a duplicate of bug 69515 ***