[Webkit-unassigned] [Bug 28076] fast/images/icon-decoding.html needs results for Qt

[bugzilla-daemon at webkit.org]

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





--- Comment #7 from Peter Kasting <pkasting at google.com>  2009-08-12 10:58:19 PDT ---
(In reply to comment #6)
> According to that the behaviour of the Qt infrastructure is totally wrong,
> because only the 1st element in the ico file is handed upward to create a QIcon
> or QPixmap or QImage, and no feature is considered.

If you're only going to select one image, it should probably be the largest
(and highest bit depth).

> In my
> opinion at least QIcon sould automatically fill himself with all the icons
> contained in the ico file, and then select which to retunrt on
> QIcon::pixmap(...) calls, according to the features and the given arguments. Do
> you agree?

I am not familiar with the Qt API, so I can't comment usefully.  In the
abstract, that sounds correct :)

> WebKit converts the images to NativeImagePtr, which is QPixmap* in case of
> QtWebKit if I am not mistaken, so the information that it was an ico and had
> more entries is lost.

Things are only converted to a NativeImagePtr at the time when a client
requests a frame at a particular index.  But an outside client can query
ImageSource::frameCount() for the number of frames in an image, and then use
ImageSource::frameSizeAtIndex() to determine which frame it wants before
requesting the actual frame data.

Making this work depends on having your ImageDecoder return the right values
for these calls.  If your icon decoder sorts the directory entries by size, and
bit depth within size, with the highest quality image first, then callers who
blindly grab the first frame will get the highest-quality icon (which is what
this layout test is testing), and callers who want to pick an icon can use the
functions described above.

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