My system: Plasma 5.5 and Arch Linux, Intel HD4600 + Nvidia. On page https://userbase.kde.org/Desktop_Effects_Performance#Thumbnail_Scaling says what with Intel driver Accurate Smooth not working, and I need set enviroment variable to see this filter. I wrote in my ~/.profile next string ----------------- export KWIN_USE_INTEL_SWAP_EVENT=1 export KWIN_FORCE_LANCZOS=1 ----------------- After restart I have not seen this filter and my taskbar thumbnails it look very ugly Image: http://i.imgur.com/xnhW2Vq.png Reproducible: Always Expected Results: Accurate smoothing on taskbar thumbnails
> export KWIN_USE_INTEL_SWAP_EVENT=1 Don't do that - the function is rather untested and afawk completely broken > After restart I have not seen this filter and my taskbar thumbnails it look very ugly Yes, that's why it's disabled on your hardware - you even found the page that informs you about this - what did you expect?
I expect accurate filtering of my thumbnails( On page: ----------------------------- On Intel hardware Accurate is never used and cannot be enabled unless the environment variable KWIN_FORCE_LANCZOS is set to 1 ----------------------------- But KWIN_FORCE_LANCZOS set to 1 and filter doesnt work(
What does not magically enact your GPU to provide this feature. The environment is to check whether things in the driver may have changed and/or the GPU match is too wide (ie. a newer generation of chips is accidentally blacklisted)
actually it's irrelevant whether the GPU provides it or not. The thumbnail is nowadays rendered directly in the context of plasmashell without any support of KWin. Thus KWin's scale settings are rather irrelevant.
Ah, I thought this was about present windows etc. (but the screenshot is the taskbar thingy indeed) Meaning a) the environment is indeed irrelevant and b) this is not about "accurate" rendering (ie. the lanczos filter), but c) the entire thing looks a lot like GL_NEAREST is used to render the texture, despite WindowThumnail seems to set QSGTexture::Linear -> known caveat in QtQuick?
So, how can one enable Lanczos scaling for the taskbar window thumbnails? When choosing "Accurate" on KDE Neon running on an Intel Core i7-6700K, the ALT+TAB window thumbnails are being rendered using Lanczos, but the taskbar windows thumbnails are not. Why? How can one also enable it for the taskbar window thumbnails?
>How can one also enable it for the taskbar window thumbnails? You cannot.
(In reply to Martin Gräßlin from comment #7) > >How can one also enable it for the taskbar window thumbnails? > > You cannot. But why not? Could you please elaborate? Why does it work for the ALT+TAB thumbnails, but not for the task manager thumbnails? Could you please elaborate? It would be much appreciated, because the ALT+TAB thumbnails with Lanczos scaling look _much_ better than the task manager thumbnails with nearest neighbour scaling. I have recently switched to KDE because it's the only DE which has an icon-only task manager and task manager window thumbnails out of the box, just like Windows 7/8/8.1/10, which is a very good thing. However, on MS Windows, the thumbnails look nice (due to Lanczos scaling), whereas on KDE they look ugly and kinda unreadable (due to the absence of Lanczos scaling). It would be a huge improvement if the task manager thumbnails would also scale using Lanczos. And technically it should work, since it also works just fine for the ALT+TAB thumbnails, right?
> But why not? Could you please elaborate? Why does it work for the > ALT+TAB > thumbnails, but not for the task manager thumbnails? > > Could you please elaborate? Because in Alt+Tab it's provided by KWin, which has support for Lanczos and in the taskbar thumbnails it's Plasma which does not have support for Lanczos. I consider it as highly unlikely that someone will implement this. We are currently working on a technology to provide more meaningful thumbnails which are not based on a scaled down thumbnail, but on application defined content. For more information see https://community.kde.org/KWin/Window_Metadata
(In reply to Martin Gräßlin from comment #9) > I consider it as highly unlikely that someone will implement this. We > are currently working on a technology to provide more meaningful > thumbnails which are not based on a scaled down thumbnail, but on > application defined content. For more information see > https://community.kde.org/KWin/Window_Metadata I am not really seeing "more information" in there. You said "not based on a scaled down thumbnail", yet https://community.kde.org/KWin/Window_Metadata talks about window thumbnail previews (albeit not live updated previews)... And the other things there, like "Task Manager Progress", have nothing to do with the thumbnails. What's being described in "Task Manager Progress" over there is what MS Windows provides since Windows 7 and is also available in Canonical's Unity. But it's about the app icon in the task manager on the panel, not the thumbnail that appears when hovering over the icon. So, could you please elaborate what you mean with "not based on a scaled down thumbnail"? Because https://community.kde.org/KWin/Window_Metadata does not explain it.
The page says that the clent shall wire down a "mini-me" representation to the taskbar, could be a downscaled window or some specific information (like pressing dates from a calendar application) or a picture of a cat. You btw. likely don't even desire a lanczos filtered thumbnail. The OPs screenshot looks a hell lot like GL_NEAREST, ie. a more fundamental flaw in QtQuick, see comment #5
> So, could you please elaborate what you mean with "not based on a > scaled down > thumbnail"? Because https://community.kde.org/KWin/Window_Metadata > does not > explain it. Quoting our documentation: "When a thumbnail is required the window manager informs the application for which window and in which size a thumbnail is needed. In addition it passes a filedescriptor of a pipe to the application. The application renders the thumbnail and writes the rendering result into the pipe and closes the pipe once the rendering is finished." Which means: the application renders the thumbnail in the requested size. What that is: completely depends on application. E.g. a browser could just render a fav icon of open tab and the title. A contact application could render information about the selcted contact. A mail application could render a readable preview of the open mail. The important part is: the application is in control and it's not going to be scaled down. Readability is at the core. We are giving the thumbnail back to the application.
(In reply to Thomas Lübking from comment #11) > You btw. likely don't even desire a lanczos filtered thumbnail. The OPs > screenshot looks a hell lot like GL_NEAREST, ie. a more fundamental flaw in > QtQuick, see comment #5 Has this issue been submitted to the Qt devs? If not: Where would one report it? All I can say is that the task manager thumbnails always look pixelated on KDE Neon 5.8.5 running on an Intel Core i7-6700K. Oh, and by the way: The ALT+TAB thumbnails are also affected, even when setting KWin to "Accurate" scaling. Some ALT+TAB thumbnails are pixelated (like the task manager thumbnails) and some are smooth. Is this intentional?
*** Bug 353903 has been marked as a duplicate of this bug. ***
Any update?
*** Bug 391915 has been marked as a duplicate of this bug. ***
*** Bug 390457 has been marked as a duplicate of this bug. ***