Bug#390271: Resizing and scrolling very slow with r200
On Sat, 2006-10-14 at 19:55 +0200, Thierry Reding wrote: > > I have set compiz to startup when the GNOME session is loaded, and when > compiz replaces metacity, there's a short period where the windows (there's > an annoying error message that keeps popping up, but unreleted to compiz or > AIGLX) and the desktop are different shades of gray That's how compiz marks 'inactive' windows (that haven't reacted to expose events in a while or something along those lines) I think. > and the window with the error message is first positioned in the > top-left corner, then suddenly moves up and to the left. But then, > after compiz has loaded and starts updating the > window decorations and contents all is back to normal. > > That is if I comment out the XAANoOffscreenPixmaps option. If it is > uncommented, the above "transition" doesn't happen. Could indicate it actually makes a difference in performance for you. > I'm not sure how helpful this is. After compiz is loaded I don't see any > strange behaviour or bad performance with or without XAANoOffscreenPixmaps. Again, I do see incorrect rendering without it. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#390271: Resizing and scrolling very slow with r200
* Michel Dänzer wrote: > On Mon, 2006-10-09 at 17:20 +0200, Thierry Reding wrote: > > * Michel Dänzer wrote: > > > On Sun, 2006-10-08 at 18:18 +0200, Michel Dänzer wrote: > > > > On Sat, 2006-10-07 at 21:35 -0400, David Nusinow wrote: > > > > > > > > > Ideally though, just editing currently broken-for-EXA patch so > > > > > that it's only on when XAA is enabled is probably a better hack. > > > > > > > > Indeed. > > > > > > Actually, it should also be verified that disabling offscreen pixmaps is > > > even necessary or a good idea with XAA on integrated chipsets, in > > > particular i[89]xx. > > > > It seems to me that enabling offscreen pixmaps on my 852GM/855GM chipset > > doesn't make a difference, apart from X behaving slightly "different" when > > starting up compiz. It seems like up until compiz starts rendering, the > > windows are offset a little more than with offscreen pixmaps disabled. > > Define 'offset'. I finally got around to trying this myself, and window > updates were regularly missed. So it seems the problem with XAA > offscreen pixmaps for GLX_EXT_tfp is not just about performance but > correctness. I have set compiz to startup when the GNOME session is loaded, and when compiz replaces metacity, there's a short period where the windows (there's an annoying error message that keeps popping up, but unreleted to compiz or AIGLX) and the desktop are different shades of gray and the window with the error message is first positioned in the top-left corner, then suddenly moves up and to the left. But then, after compiz has loaded and starts updating the window decorations and contents all is back to normal. That is if I comment out the XAANoOffscreenPixmaps option. If it is uncommented, the above "transition" doesn't happen. I'm not sure how helpful this is. After compiz is loaded I don't see any strange behaviour or bad performance with or without XAANoOffscreenPixmaps. - Thierry signature.asc Description: Digital signature
Bug#390271: Resizing and scrolling very slow with r200
On Mon, 2006-10-09 at 17:20 +0200, Thierry Reding wrote: > * Michel Dänzer wrote: > > On Sun, 2006-10-08 at 18:18 +0200, Michel Dänzer wrote: > > > On Sat, 2006-10-07 at 21:35 -0400, David Nusinow wrote: > > > > > > > Ideally though, just editing currently broken-for-EXA patch so > > > > that it's only on when XAA is enabled is probably a better hack. > > > > > > Indeed. > > > > Actually, it should also be verified that disabling offscreen pixmaps is > > even necessary or a good idea with XAA on integrated chipsets, in > > particular i[89]xx. > > It seems to me that enabling offscreen pixmaps on my 852GM/855GM chipset > doesn't make a difference, apart from X behaving slightly "different" when > starting up compiz. It seems like up until compiz starts rendering, the > windows are offset a little more than with offscreen pixmaps disabled. Define 'offset'. I finally got around to trying this myself, and window updates were regularly missed. So it seems the problem with XAA offscreen pixmaps for GLX_EXT_tfp is not just about performance but correctness. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#390271: Resizing and scrolling very slow with r200
* Michel Dänzer wrote: > On Sun, 2006-10-08 at 18:18 +0200, Michel Dänzer wrote: > > On Sat, 2006-10-07 at 21:35 -0400, David Nusinow wrote: > > > > > Ideally though, just editing currently broken-for-EXA patch so > > > that it's only on when XAA is enabled is probably a better hack. > > > > Indeed. > > Actually, it should also be verified that disabling offscreen pixmaps is > even necessary or a good idea with XAA on integrated chipsets, in > particular i[89]xx. It seems to me that enabling offscreen pixmaps on my 852GM/855GM chipset doesn't make a difference, apart from X behaving slightly "different" when starting up compiz. It seems like up until compiz starts rendering, the windows are offset a little more than with offscreen pixmaps disabled. After compiz has loaded, everything is working as normal again, and the performance seems the same. - Thierry signature.asc Description: Digital signature
Bug#390271: Resizing and scrolling very slow with r200
On Sun, 2006-10-08 at 18:18 +0200, Michel Dänzer wrote: > On Sat, 2006-10-07 at 21:35 -0400, David Nusinow wrote: > > > Ideally though, just editing currently broken-for-EXA patch so > > that it's only on when XAA is enabled is probably a better hack. > > Indeed. Actually, it should also be verified that disabling offscreen pixmaps is even necessary or a good idea with XAA on integrated chipsets, in particular i[89]xx. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#390271: Resizing and scrolling very slow with r200
On Sat, 2006-10-07 at 21:35 -0400, David Nusinow wrote: > On Fri, Oct 06, 2006 at 09:21:29AM +0200, Michel Dänzer wrote: > > On Thu, 2006-10-05 at 19:33 -0400, David Nusinow wrote: > > > > > > I wonder if patching the server to automatically enable this when radeon > > > is > > > loaded until we have a good fix is worthwhile... > > > > It would be a big performance penalty for people using XAA but not a > > compositing manager, i.e. probably the majority for some time to come. > > We could check for this too, right? Check for what? Again, the driver doesn't have the necessary information. > Ideally though, just editing currently broken-for-EXA patch so > that it's only on when XAA is enabled is probably a better hack. Indeed. > Fixing it so it actually worked with EXA would be even better, [...] Not really, there shouldn't be any problem with offscreen pixmaps with EXA. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#390271: Resizing and scrolling very slow with r200
On Fri, Oct 06, 2006 at 09:21:29AM +0200, Michel Dänzer wrote: > On Thu, 2006-10-05 at 19:33 -0400, David Nusinow wrote: > > On Wed, Oct 04, 2006 at 10:30:43AM +0200, Michel Dänzer wrote: > > > On Tue, 2006-10-03 at 20:15 -0400, David Nusinow wrote: > > > > On Tue, Oct 03, 2006 at 02:23:33PM +0200, Xavier Bestel wrote: > > > > > On Tue, 2006-10-03 at 13:53 +0200, Michel Dänzer wrote: > > > > > > Assuming you're using XAA with Option "XaaNoOffscreenPixmaps", that > > > > > > effectively disables acceleration for anything but the actual > > > > > > compositing done by compiz. > > > > > > > > > > Yet Another Option I have to remember to prune when it's no more > > > > > useful... > > > > > > > > Unfortunately, this is an issue with the ati driver, but one best solved > > > > upstream. It's really an issue with all drivers, but the ati one has a > > > > ton > > > > of options. It'd be nice if it was more clever about using those options > > > > when necessary. I currently have no idea how feasible this is in > > > > reality > > > > though. > > > > > > Note that this is an XAA option, not a driver option. The driver doesn't > > > have the information to decide when to disable offscreen pixmaps with > > > XAA. > > > > I wonder if patching the server to automatically enable this when radeon is > > loaded until we have a good fix is worthwhile... > > It would be a big performance penalty for people using XAA but not a > compositing manager, i.e. probably the majority for some time to come. We could check for this too, right? Ideally though, just editing currently broken-for-EXA patch so that it's only on when XAA is enabled is probably a better hack. Fixing it so it actually worked with EXA would be even better, but I don't think I'm up to that one :-) If Shawn doesn't get it done soon I'll try and tackle it myself. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390271: Resizing and scrolling very slow with r200
On Thu, 2006-10-05 at 19:33 -0400, David Nusinow wrote: > On Wed, Oct 04, 2006 at 10:30:43AM +0200, Michel Dänzer wrote: > > On Tue, 2006-10-03 at 20:15 -0400, David Nusinow wrote: > > > On Tue, Oct 03, 2006 at 02:23:33PM +0200, Xavier Bestel wrote: > > > > On Tue, 2006-10-03 at 13:53 +0200, Michel Dänzer wrote: > > > > > Assuming you're using XAA with Option "XaaNoOffscreenPixmaps", that > > > > > effectively disables acceleration for anything but the actual > > > > > compositing done by compiz. > > > > > > > > Yet Another Option I have to remember to prune when it's no more > > > > useful... > > > > > > Unfortunately, this is an issue with the ati driver, but one best solved > > > upstream. It's really an issue with all drivers, but the ati one has a ton > > > of options. It'd be nice if it was more clever about using those options > > > when necessary. I currently have no idea how feasible this is in reality > > > though. > > > > Note that this is an XAA option, not a driver option. The driver doesn't > > have the information to decide when to disable offscreen pixmaps with > > XAA. > > I wonder if patching the server to automatically enable this when radeon is > loaded until we have a good fix is worthwhile... It would be a big performance penalty for people using XAA but not a compositing manager, i.e. probably the majority for some time to come. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#390271: Resizing and scrolling very slow with r200
On Wed, Oct 04, 2006 at 10:30:43AM +0200, Michel Dänzer wrote: > On Tue, 2006-10-03 at 20:15 -0400, David Nusinow wrote: > > On Tue, Oct 03, 2006 at 02:23:33PM +0200, Xavier Bestel wrote: > > > On Tue, 2006-10-03 at 13:53 +0200, Michel Dänzer wrote: > > > > Assuming you're using XAA with Option "XaaNoOffscreenPixmaps", that > > > > effectively disables acceleration for anything but the actual > > > > compositing done by compiz. > > > > > > Yet Another Option I have to remember to prune when it's no more > > > useful... > > > > Unfortunately, this is an issue with the ati driver, but one best solved > > upstream. It's really an issue with all drivers, but the ati one has a ton > > of options. It'd be nice if it was more clever about using those options > > when necessary. I currently have no idea how feasible this is in reality > > though. > > Note that this is an XAA option, not a driver option. The driver doesn't > have the information to decide when to disable offscreen pixmaps with > XAA. I wonder if patching the server to automatically enable this when radeon is loaded until we have a good fix is worthwhile... > In general, there are only driver options for things that can't be > determined automatically in all cases, and even then the default value > should work in the majority of cases. If you're aware of radeon driver > options that violate these principles and have ideas how to improve > them, your upstream bug reports will be much appreciated. I don't, but I'm glad to hear this. I know admittedly far less about the radeon driver than I'd like, so I can't recommend anything meaningful. It's more of a general gripe about the number of options available in all drivers (as well as the server) that could use some extra code to do things automagically. Hopefully I'll be able to begin addressing this as needed in the etch+1/7.3/7.4 release cycles. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390271: Resizing and scrolling very slow with r200
On Tue, 2006-10-03 at 20:15 -0400, David Nusinow wrote: > On Tue, Oct 03, 2006 at 02:23:33PM +0200, Xavier Bestel wrote: > > On Tue, 2006-10-03 at 13:53 +0200, Michel Dänzer wrote: > > > Assuming you're using XAA with Option "XaaNoOffscreenPixmaps", that > > > effectively disables acceleration for anything but the actual > > > compositing done by compiz. > > > > Yet Another Option I have to remember to prune when it's no more > > useful... > > Unfortunately, this is an issue with the ati driver, but one best solved > upstream. It's really an issue with all drivers, but the ati one has a ton > of options. It'd be nice if it was more clever about using those options > when necessary. I currently have no idea how feasible this is in reality > though. Note that this is an XAA option, not a driver option. The driver doesn't have the information to decide when to disable offscreen pixmaps with XAA. In general, there are only driver options for things that can't be determined automatically in all cases, and even then the default value should work in the majority of cases. If you're aware of radeon driver options that violate these principles and have ideas how to improve them, your upstream bug reports will be much appreciated. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#390271: Resizing and scrolling very slow with r200
On Tue, Oct 03, 2006 at 02:23:33PM +0200, Xavier Bestel wrote: > On Tue, 2006-10-03 at 13:53 +0200, Michel Dänzer wrote: > > Assuming you're using XAA with Option "XaaNoOffscreenPixmaps", that > > effectively disables acceleration for anything but the actual > > compositing done by compiz. > > Yet Another Option I have to remember to prune when it's no more > useful... Unfortunately, this is an issue with the ati driver, but one best solved upstream. It's really an issue with all drivers, but the ati one has a ton of options. It'd be nice if it was more clever about using those options when necessary. I currently have no idea how feasible this is in reality though. Until I get my ati-running laptop working again I won't even be able to think about looking at this seriously. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390271: Resizing and scrolling very slow with r200
Michel Dänzer wrote: > On Tue, 2006-10-03 at 14:18 +0200, Michael Biebl wrote: >> Michel Dänzer wrote: >>> On Tue, 2006-10-03 at 12:55 +0200, Michael Biebl wrote: Also scrolling is much slower than without compiz. >>> Assuming you're using XAA with Option "XaaNoOffscreenPixmaps", that >>> effectively disables acceleration for anything but the actual >>> compositing done by compiz. >> I haven't set this option explicitly. > > Maybe you should then. :) > ;-) Unfortunately setting this option does not improve the situation. Scrolling is about the same speed as without "XaaNoOffscreenPixmaps". Scrolling under compiz remains noticeably slower than e.g. under metacity or kwin. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#390271: Resizing and scrolling very slow with r200
On Tue, 2006-10-03 at 13:53 +0200, Michel Dänzer wrote: > Assuming you're using XAA with Option "XaaNoOffscreenPixmaps", that > effectively disables acceleration for anything but the actual > compositing done by compiz. Yet Another Option I have to remember to prune when it's no more useful...
Bug#390271: Resizing and scrolling very slow with r200
On Tue, 2006-10-03 at 14:18 +0200, Michael Biebl wrote: > Michel Dänzer wrote: > > On Tue, 2006-10-03 at 12:55 +0200, Michael Biebl wrote: > > >> Also scrolling is much slower than without compiz. > > > > Assuming you're using XAA with Option "XaaNoOffscreenPixmaps", that > > effectively disables acceleration for anything but the actual > > compositing done by compiz. > > I haven't set this option explicitly. Maybe you should then. :) -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#390271: Resizing and scrolling very slow with r200
On Tue, 2006-10-03 at 12:55 +0200, Michael Biebl wrote: > As a followup to this bug report: > With my Radeon Mobility 9200 (r200) using the free xorg driver, > operations like moving, rotating etc. are really smooth and fast. > But resizing windows (especially for more complex applications like > firefox) is unbearable slow. One of the X server patches currently under discussion for inclusion into xserver-xorg-core might help with this. > Also scrolling is much slower than without compiz. Assuming you're using XAA with Option "XaaNoOffscreenPixmaps", that effectively disables acceleration for anything but the actual compositing done by compiz. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#390271: Resizing and scrolling very slow with r200
Michel Dänzer wrote: > On Tue, 2006-10-03 at 12:55 +0200, Michael Biebl wrote: >> As a followup to this bug report: >> With my Radeon Mobility 9200 (r200) using the free xorg driver, >> operations like moving, rotating etc. are really smooth and fast. >> But resizing windows (especially for more complex applications like >> firefox) is unbearable slow. > > One of the X server patches currently under discussion for inclusion > into xserver-xorg-core might help with this. Sounds great. >> Also scrolling is much slower than without compiz. > > Assuming you're using XAA with Option "XaaNoOffscreenPixmaps", that > effectively disables acceleration for anything but the actual > compositing done by compiz. I haven't set this option explicitly. This is all I have in my xorg.conf: Section "Device" Option "DPMS" Identifier "Card0" Driver "radeon" VendorName "ATI" BoardName "ATI Radeon" BusID "PCI:1:0:0" Option "AGPMode" "4" EndSection Is there an option I can enable to speed up scrolling? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#390271: Resizing and scrolling very slow with r200
As a followup to this bug report: With my Radeon Mobility 9200 (r200) using the free xorg driver, operations like moving, rotating etc. are really smooth and fast. But resizing windows (especially for more complex applications like firefox) is unbearable slow. Also scrolling is much slower than without compiz. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
