Version: (using KDE 4.0.2) Installed from: Ubuntu Packages OS: Linux With no compositing or any such enabled*, if I rotate a plasmoid, it shows some decay in quality. Not just the internal rendering, but the handles and so forth are rendered without any anti-aliasing, so that everything looks blocky and uncertain. When the plasmoid loses focus, it renders properly again; when it regains focus, it looks ugly once more. * My card is a poorly-supported ATI radeon, running OS drivers, no render acceleration.
Created attachment 24018 [details] no rotation Here is some plasmoids with no rotation applied. Notice how wonderful my grandma looks.
Created attachment 24020 [details] with rotation Here is the same plasmoids with rotation - we can already see that the 'Abc' in the dictionary icon is rendering incorrectly.
Created attachment 24021 [details] with rotation and focus Here are the same plasmoids with rotation and focus applied. The lack of anti-aliasing is now obscuring my grandma's natural beauty.
*** Bug 160315 has been marked as a duplicate of this bug. ***
Which Radeon (board or chip) and which driver are you using. I have a 9200 which is the highest number (maybe the 9250 is OK) that is fully supported by the X "radeon" driver. There doesn't appear to be a problem with 24020 -- the antialiasing of the edges is correct. However, there is an issue with 24021 which is a BUG, not a WISH. See my XMag screen shots.
Created attachment 24177 [details] Correctly rendered rotated digital clock This appears to be correct antialiasing and rendering. This type is heaver than the ABC in the icon in 24020 so it is readable. Perhaps because it is rendered as type rather than an image, it is rendered better. IIUC, we currently can not render type linked in an SVG which might result in better rendering.
Created attachment 24178 [details] Incorrectly rendered rotated digital clock Sometimes when changing from not focused to focused and back, the rendering changes to this incorrect rendering. The problem is not antialiasing but rather with the line drawing algorithm.
This should be changed to a bug. However, I don't know if it is KDE, Qt, or X.org that is causing the problem.
i consider this a wishlist item, and here's why: a) it does not interfere with functionality b) it's a property of the fact that we do rotation post-painting with a transformation matrix c) we don't have a way currently to do post-transform effects such as edge smoothing which would ease this it's an interesting detail item, one that may be improved on by changing it such that the painter context itself gets rotated (but there are several issues even there that would need to get worked out) as such, this is not something that we can realistically fix in plasma right now and it doesn't interfere with interaction. it's just a property of the feature as implemented. yes, it could be improved (which is why it's still open: the request it valid), and i've marked it with the priority it has within the project. the status of bugs is not actually for the users, it's for the developers. otherwise there's really zero point in developers using b.k.o as a development tool.
Note: attachments 24177 & 24178 are from TRUNK. I am unable to reproduce the line drawing errors in BRANCH. The fuzzy rendering of "ABC" in 24020 remains an issue in BRANCH.
*** Bug 184991 has been marked as a duplicate of this bug. ***
Hello! This feature request was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this feature request is already implemented in Plasma 5, or is no longer applicable. Accordingly, we hope you understand why we must close this feature request. If the requested feature is still desired but not implemented in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham