[taskmanager]: icon quality degrades to be blurry or pixelated if task is active

[star-buck]

most visibly example here seems firefox

[eikehein]

• Which system (KCI iso?)
• Screenshot would be great

Most likely reason this happens: The launcher icon gets replaced with the icon the application is setting for its window, and the app sets a low-res one.

The old ITM implementation had a "Always use launcher icons" options to ignore the icons apps set. The downside of that is that the app can't change the icon at runtime anymore (which e.g. breaks favicons as window icons, or gimp's image preview -- but Wayland is going to disallow this anyway as it stands right now). Aside from this workaround the way to go is probably to fix the app. Doesn't happen with Firefox Nightly on my Fedora here though.

[star-buck]

Looking closely, several apps seem to be affected, so a plasma fix seems appropriate?:

Firefox seems to still degrade too, its just less visible than I remembered compared to the more obvious examples above.

[eikehein]

I cannot reproduce this here (using Dolphin as a testcase), could you add which system this happens on exactly?

[star-buck]

plasma5.3+git fixes. I can also check latest kci from friday, but this doesnt look like a kubuntu/distro-related issue or would it have been fixed with some update in plasma/frameowkrs/qt? I tested with latest EITM, but will test again with normal one too now.

[eikehein]

I'm not saying it's necessarily kubuntu/distro-related, I just need to be able to reproduce it to investigate it, that's all :). But if it doesn't happen here but does happen elsewhere, there needs to be a difference to account for it.

On the tech level, things work like this:

• Simplified, there are two ways app windows can set icons for themselves: An icon name (which allows us to load the best version available) or a set of icon pixmaps (can be a single, small one and then we're in trouble)
• For a launcher, the icon may be taken from the app's .desktop file the launcher is referencing, or the icon bitmap if we can't map the window to an app known by its .desktop file - the bitmap is then written to the TM's config in base64 encoding and restored from there
• For a running task, the icon is taken from the window

IOW, a low-res icon can e.g. happen when going from a hi-res theme backed launcher icon to a low-res bitmap-only window icon. Now, obviously this shouldn't be happening for Dolphin because it's a typically well-behaved app (we can map it to a .desktop file; it also properly specifies its icon). So we're left with a mystery which needs investigation.

[star-buck]

still the same with TM and IOTM. For dolphin it also depends on the height of the panel, so with some increased height than my default example, the effect seems to not happen with some icons (or rather at some optimal height). The synaptic one still gets worse though, so if having a suboptimal height, the effect is visible again for all icons.

[star-buck]

of course since themeing also varies launcher height independent of panel height, this is still another factor that on default breeze, it might not be visible for dolphin. So if you check synaptic, you may (or may not) then know if its happening on your system and could test further.

[eikehein]

There shouldn't be any difference between the TMs there, the icon-related code is in KWindowSystem (KF5) and libtaskmanager (plasma-workspace).

On the screenshot it looks like the Dolphin icon may not actually be pixelated but just inbetween scaling steps. But that's bizarre in itself since IconItem should have enough size versions to step inbetween, and I can't get it into that mode here by resizing the panel. Synaptic looks (from the screenshot) like a case where a 16px window bitmap gets scaled up badly.

Where can I download that theme currently?

[eikehein]

Good news: I can reproduce the Dolphin icon tweening to a lower-res version on the latest KCI ISO. Now to find out why ...

[eikehein]

Synaptic is definitely the app misbehaving - you'll notice the icon is also very blurry in the window title bar. It's pixelated in TM because IconItem uses different scaling from the code in the window title bar, but the underlying issue (app setting low-res icon bitmap and no icon name on its window) is the same.

This could be addressed by a "Always use launcher icon" option feature, but that would be wrong to enable by default since it breaks other apps.

[eikehein]

I'm closing in on the Dolphin issue. For some reason KWindowSystem::icon hands over 32x32 icon for Dolphin when the 22x22 size is requested, so the 22x22 icon isn't made available to the Task Manager. But the 22x22 icon file is installed on the system, so now it's a question of why it doesn't like it.

[eikehein]

OK, it looks like the underlying issue is that KDE 4 apps never set the 22x22 version of the icon on the window. KWindowSystem::icon tries to use the NetWM way of getting the icon from the window first and the the closest it can find is the 32x32 which it then returns. IconItem then scales this down and it looks blurry. This doesn't affect launchers because launchers do an icon theme lookup by the name in the .desktop file and QIcon::fromTheme loads 22x22 icons nicely.

Possible ways to fix this:

• Changing kdelibs4 / Qt 4 to support 22x22 icons as the 5 stack does
• Adding a workaround to KWindowSystem::icon that goes something like this: If we can't get a 22x22 icon via NetWM, assume that this is because of this situation and fall through to the ClassHint method which will usually succeed in getting it from the icon theme by name (similar to what launchers do)

I don't like (2) much because it's magic, but it'd probably be OK. That needs Martin's opinion as maintainer.

[eikehein]

Asked Martin to weigh in via mail.

[star-buck]

its not that important to fix for netrunner, so whenever there is a solution, we can wait for 5.3.x or 5.4.

[mgraesslin]

I'm absolutely against option 2. This would add magic to the API (why only such a fallback for size 22?) and the behavior can be emulated in the user of API (try getting icon one way, if there is none, fallback to class hint).

[eikehein]

why only such a fallback for size 22?

I guess I was thinking of the 24-vs-22 mess, which already has magic hacks in the lib code.

I agree though, and I don't really want to be doing this in libtaskmanager either. Mixing sizes from different sources is just going to lead to problems, and 22-is-missing is not a good enough reason to always fall through to ClassHint. I think the best way to address this is just to port KDE 4 apps to KF5. (Why does Netrunner still ship Dolphin 4?)

[davidedmundson]

I think this has been fixed by Eike here http://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=fbd4a876f32f402ae240450c4c7d8575391637b9

[star-buck]

@eikehein : can this be closed?

[eikehein]

Yep.

[star-buck]

done :)