[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 #6 from Andras Becsi <becsi.andras at stud.u-szeged.hu>  2009-08-12 10:45:58 PDT ---
> The layout test is testing that the decoder selects the icon entries in order
> of largest first, then highest bit depth first after that.  This is similar to
> how Windows itself behaves, especially on newer versions like Vista and 7,
> where the "typical" icon size is significantly larger than 32x32.
> 
> Note that for some applications (e.g. displaying favicons in a tab or session
> history list), you probably want to be able to select a 16x16 icon.

Thank you very much for the information! I din't know which is the preferred
order of selecting the icons, how ico exactly has to be handled. I will look
into that and correct my patch.

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. The only way to handle ICO
files correctly is to use QImageLoader an specify how to select the icon. 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?

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. I could write a patch to work around the test in
QtWebKit, and to specifically handle ico files, but I think this is not a
QtWebKit bug.

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