Compiz uses low-resolution, non-power-of-2 icon texture sizes
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Compiz |
Fix Released
|
Medium
|
MC Return | ||
| compiz (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
1. Texture sizes should *always* be power-of-2, otherwise they will be internally upscaled to the next higher power-of-2 resolution, which means this comes with a loss of quality (with all the known scaling issues).
Non-power-of-2 resolutions should *never* be used for textures.
Example: 96x96 becomes 128x128 internally, so the 96 pixels have to be upscaled to 128, which creates scaling artifacts.
2. 96x96 or even lower sizes are not good sizes for icons, especially if they get upscaled to 50% of the screen width in the
case of "Big" overlay icon modes of our Switchers (Shift, Stack, Ring) - please see bug #1173694 for details on this issue.
[Solution]
We should increase the icon texture sizes to at least 256x256, which is quite the standard in 2013.
We should investigate if we could force Compiz to load the .svg version of the icon, if available, because vectorgraphics could be scaled without any artifacts.
Related branches
- PS Jenkins bot (community): Approve (continuous-integration)
- Sam Spilsbury: Approve
- MC Return: Needs Information
-
Diff: 135 lines (+13/-11) 9 files modifiedapiplugins/compiztoolbox/include/compiztoolbox/compiztoolbox.h (+1/-1)
plugins/compiztoolbox/src/compiztoolbox.cpp (+2/-2)
plugins/kdecompat/src/kdecompat.cpp (+1/-1)
plugins/ring/src/ring.cpp (+2/-2)
plugins/scale/src/scale.cpp (+1/-1)
plugins/shift/src/shift.cpp (+1/-1)
plugins/stackswitch/src/stackswitch.cpp (+2/-2)
plugins/staticswitcher/src/staticswitcher.cpp (+2/-0)
plugins/staticswitcher/src/staticswitcher.h (+1/-1)
Fix committed into lp:compiz at revision None, scheduled for release in compiz, milestone 0.9.10.0
It looks like that in addition to regression described in LP #1186426 fix to has been committed there is very similar regression in switcher plugin - icons are very-very large. I would guess that cause is the same, but I'm not exactly sure how this should be fixed though, since 'switcher' plugin doesn't have its own icon size definition.
Fix Released in Compiz Compiz 0.9.10.0.
This bug was fixed in the package compiz - 1:0.9.10+
---------------
compiz (1:0.9.
[ Sam Spilsbury ]
* Bump version to 0.9.10
[ Łukasz 'sil2100' Zemczak ]
* Remove debian/
- Running the support test from compiz has bad side effects, from now
on we run it from Xsession.d
* Automatic snapshot from revision 3644
[ Iven Hsu ]
* Opacify: Only dim the windows above the active window.(LP:
#1189374). (LP: #1189374)
* KWD: Fix compile errors with KDE 4.11. The KWin developers made
kdecoration
http://
(LP: #1193792). (LP: #1193792)
[ Nikolay Martynov ]
* When static switcher is enabled and has an option to show
application icon turned on the icons are expected to be ~1/3 of a
thumbnail (48px). Instead they are displayed in 512px size and
completely cover everything. This change addresses this issue. See
LP #1173914. (LP: #1173914, #1186426)
[ BryanFRitt ]
* Fixed the non-working Annotate 'Clear' Button. Moved this option's
CCSM position upwards to keep the button shortcuts together. (LP:
#1202907). (LP: #1202907)
[ Mehrdad Afshari ]
* Added "move window to previous monitor" feature to compiz Put
plugin. (LP: #1178581)
[ Hu Kang ]
* gtk-window-
min, max) buttons on the title bar is pressed. (LP: #1101648)
* Remove redundant src/logmessage/
#1067246). (LP: #1067246)
[ Steve Langasek ]
* Fix for bug #763148 (with added test cases): when the desktop is
resized, windows should stay on their original workspace. (LP:
#763148)
[ Brandon Schaefer ]
* Unrevert 3728, fix failing tests. Change the behaviour of
undecorating windows. Previously when a window was undecorated, we
would shift it back to an appropriate position according to its
gravity member. That behaviour was problematic because in the
StaticGravity case the window has to just stay in the same place.
But then if you had a window with StaticGravity which then did get a
decoration and later removed it, it would be placed as though it was
decorated and appear to be in the wrong place. The correct behaviour
is to place all windows as though they have decorations, and then
when decorations are removed, to move the window back to the corner
as indicated in its gravity and then expand its size to cover the
obscured regions no longer hidden because the decorations went away.
(LP: #1165343). 1. Completely remove decorOffsetMove and other
related code from decor.cpp. Put the logic to handle the
window->input () - window->border () placement offset inside of
setWindowFr
offset from its original non-decorated position to the new
decorated position, rather than having to guess between
decoration sizes. 2. Make saveGeometry and restoreGeometry work
relative to window->border () a...