[Webkit-unassigned] [Bug 29279] [Qt] Use rgb565 format for images on Symbian platform

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Oct 6 07:24:02 PDT 2009


--- Comment #16 from Chang Shu <Chang.Shu at nokia.com>  2009-10-06 07:24:02 PDT ---
(In reply to comment #14)

Thanks for the review. Please see my reply below.

>  Some more comments why I think it is bad:
> From webkit.org point of view:
>    - WebCore/* should not know about WebKit/*

I agree this is valid concern from design. However, the current
WebCore/platform/qt code already includes code from WebKit/qt/*, see for
WebCore/platform/graphics/qt/ImageQt.cpp:#include "qwebsettings.h". We can
probably improve the code some time later.

> From performance point of view:
>    - For certain things using 16bit per pixel is more than the original image
> used. This can be the case for indexed gifs, PNG that are only 8 bit.

The patch checks the original format of the image. The conversion makes sure it
converts 32-bit to 16-bit.

>    - There is certainly a speed benefit when the image is in the screen depth
> as it makes blitting them faster.

I totally agree. Fortunately, based on testing, the speed impact is much less
while the memory reduction is significant. Note this patch only provides the
API and implementation. It does not force the conversion by default.

> The problem is that the API user will not get this right. So in the worse case
> he increases memory usage and  reduces performance. A better API would say
> "optimize" for speed, "optimize" for memory. And in both cases  QImage reader
> should do the right thing for decoding.

We can say the default behavior is "optimized" for speed and if the setting is
changed to RGB16, it is "optimized" for memory. Any suggestion on naming the
API function is appreciated.

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