https://bugs.kde.org/show_bug.cgi?id=356581
--- Comment #6 from Thomas Lübking <thomas.luebk...@gmail.com> --- Will you please attach the informations I asked for? fglrx could simply perform lousy because one context is now on a core profile or it stumbles across the syncing between X11 and glx or you're on EGL and GLX at the same time or it doesn't like the swapcontrol or it now stumbles on the X11 v20 ABI or the combination of the plasmashell, kwin and game GL context or ... Comparing GL compositor #1 to GL compositor #2 doesn't work for that reason; fglrx may not fail with two 1.3 contexts at all but cannot handle two 2.0 contexts or whatever. The information "some months ago" bears exactly *zero* information, because it does not imply what's changed. > So I have to manually remove the compositor effects? As mentioned, there's a rule and a script for this and you desperately *want* to suspend the compositor (something that neither compiz nor mutter provides) since that allows the driver to focus on the single active context and doesn't have to switch around. (Though w/ all the GL contexts in QtQuick, you're rather lost anyway here) PS: There's btw. a reason why Arch doesn't officially support fglrx. -- You are receiving this mail because: You are watching all bug changes.
