pix = iconLoader.loadIcon("icon-name", KIconLoader::NoGroup, 1600); Lets assume, Largest icon size available for icon-name is 32x32 then iconLoader returns scaled up pixmap to 1600. This should never return scaled up icons, and even if it returns scaled up icon there should be limit on which ratio icon can be scaled up. I have fix for this problem but makes this test case fail in tests pix = iconLoader.loadIcon("#crazyname", KIconLoader::NoGroup, 1600); QVERIFY(!pix.isNull()); QCOMPARE(pix.size(), QSize(1600, 1600)); Default QIconEngine never returns the scaled up pixmap but instead it returns largest available pixmap. Scaling down is good idea but scaling up is bad one. Reproducible: Always
> Default QIconEngine never returns the scaled up pixmap but instead it returns largest available pixmap So if I request size 1600x1600 for an icon of 32x32, the default QIconEngine will return just 32x32? How do you test that? Note that the code of QIconEngine indicates that if you request pixmap from the icon (which is what the views do) in any size, it will just paint that size regardless as it uses simple QPainter.
This pixmap generation happens in a QIconEngineV2. The default engine scales pixmaps down if required, but never up http://qt-project.org/doc/qt-5/qicon.html and, For sizes up to 16 x 16, QIcon uses qt_extended_16x16.png and scales it down if necessary. For sizes between 17 x 17 and 32 x 32, it uses qt_extended_32x32.png. For sizes above 32 x 32, it uses qt_extended_48x48.png. http://qt-project.org/doc/qt-5/qtwidgets-widgets-icons-example.html
That doesn't really answer the question though --> So if I request size 1600x1600 for an icon of 32x32, the default QIconEngine will return just 32x32? How do you test that? Or what do you mean by the "Default QIconEngine never returns the scaled up pixmap but instead it returns largest available pixmap."? Also, QIconEngineV2 is just QIconEngine in Qt5, see gui/image/qiconengine.h:86:typedef QIconEngine QIconEngineV2;
The icon search algorithm (which stayed the same as in kde4 times) is correct, it finds the closest size possible; paint is performed to whatever size the view/consumer requests. Which is the same with QIconEngine (I've tested), it also scales the smallest found icon up to the requested size, except it does not use smoothing, so it looks even worse. The way icon painting work is simple - the view says "give me this big pixmap for this icon", the icon engine looks up the closest size possible and then performs painting on the pixmap with the requested size and returns that pixmap to the view. It /always/ scales up. --- We can indeed opt for not scaling up the icon and returning pixmap with the requested size but with the icon only as big as the file itself is, but I would personally advise against that. It's better to have ugly icons when they are used in enormous sizes (ones that were not meant to be used) than having lots of empty space and a tiny icon in the middle, breaking other things like alignment etc. I'll leave up to Christoph what to do with the bug though.
> It /always/ scales up. ...if needed, obviously.
(In reply to comment #5) > > It /always/ scales up. *never* scales up in qt.. what you showed on IRC is using PlasmaCore.IconItem which scales up returned pixmap anyway and is very bad but thats other issue. here is testcase, QIcon icon = QIcon::fromTheme("preferences-activities"); //Lets ask for pixmap of 1600x1600 QPixmap pix = icon.pixmap(QSize(1600,1600)); /* * if using, * frameworkintegration - kiconloader : 1600x1600 (originally largest available but scaled) * plain qt - qpixmapiconengine : 48x48 (largest available and not scaled) */ qDebug() << pix.size(); w.show(); you can put any fixed size icon name instead of preferences-activities as no icon with 1600x1600 is available.. ;)
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!