GNOME Bugzilla – Bug 628448
Unaccelerated X server should not have opaque window moving by default
Last modified: 2012-05-13 15:17:37 UTC
I have a HP dv5-1132la laptop with an ATI Radeon HD 3200 (RS780) graphics controller, which is either not detected correctly by the Live CD environment, or not supported at all -- more likely since it *is* supposed to be a minimal config to get gparted to start after all -- but this may apply to any unidentified/unsupported graphics terminal in general, at least on systems with slow unaccelerated framebuffer transfers. The default Fluxbox configuration on the live environment has Opaque Window Moving enabled by default, which causes unbearable lagging when dragging or resizing windows when using the standard vesa or fbdev graphics drivers, which don't provide hardware-driven 2D acceleration by design. Since I needed to work with more than just the gparted utility alone to prepare my disk for repartitioning, I had to first disable this Opaque[...] option in the desktop menu to be able to do anything with gparted and a couple of terminal sessions. It'd be nice if future versions had this arguably useless option disabled by default to avoid hurting performance on unaccelerated X server sessions for those who are either in a hurry, or can't figure out/find the menu option to disable this. Not sure if the environment configuration (other than the X server settings) is generated on the fly from scratch, or already provided and created from some minimal skeleton dir and files, which is what the desktop icons would suggest. In the latter case I guess it'd be possible to override the session.screen0.opaqueMove setting in ~/.fluxbox/init file or template and make 'false' the default value.
Ignacio, is this still a problem with the latest GParted Live 0.12.0-2 release?
Ignacio, did you try GParted Live 0.12.0-2 ? Is your problem resolved ?
Sorry for the long delay in answering. I just tried gparted live 0.12.0-2 and 0.12.1-1 on VirtualBox and the default configuration still enables opaque window movement. This does not affect performance visibly, but that could be a consequence of the virtualized environment. I will test later this week on the originally mentioned machine (which has sustained a lot of physical damage since the original report) and my current one to see if there's a difference when running on the actual hardware.
Thank you Ignacio for reporting back. I am curious what your testing reveals on the original hardware in which you encountered the problem.
I tried 0.12.1-1 on both machines using both their native X.org video drivers (radeon for the original, intel for the new machine), and vesa (with kernel modesetting disabled), and it was possible to move windows in all four configuration sets without the huge performance hit I originally found on 0.6.2-2.
Thank you Ignacio for reporting back with your findings. Based on your comments it sounds as if the performance problem is resolved with 0.12.1-1. Shall we close this bug report as resolved?
Sure.