Since commit 24157 Terminal has started working very slow when moving it, even without composite. And I get some several warnings that I didn't get with rc2: (Terminal:9187): Gtk-CRITICAL **: gtk_style_detach: assertion `style->attach_count > 0' failed
David and I just had a chat with Olivier in #xfce, and he advised that this is essentially a user configuration problem. If the Composite extension is enabled in xorg.conf, then Terminal will use ARGB32 window even if the compositor is disabled in Xfce, moving or resizing ARGB32 is slow if you don't have hardware accelerated rendering. (this is a paraphrase of Olivier's comments) Solution is to disable the composite extension in xorg.conf or set XLIB_SKIP_ARGB_VISUALS=1 I guess this one can be closed?
Jap, resolving to INVALID.
May I humbly suggest that having an option to disable composite that doesn't actually disable composite is not an invalid bug?
Shouldn't having the compositor turned off in Xfce result in the same behavior as if XLIB_SKIP_ARGB_VISUALS was set to 1? I would agree with comment #3 -- compositing behavior should be triggered by menu option, not by an environment variable that a user needs to find in bugzilla. :)
(In reply to comment #4) > Shouldn't having the compositor turned off in Xfce result in the same behavior > as if XLIB_SKIP_ARGB_VISUALS was set to 1? > > I would agree with comment #3 -- compositing behavior should be triggered by > menu option, not by an environment variable that a user needs to find in > bugzilla. :) > Actually, these are different things. XLIB_SKIP_ARGB_VISUALS=1 instructs Xlib not to advertise ARGB visuals. A compositor can be used even when without ARGB (ie when XLIB_SKIP_ARGB_VISUALS is set), and (technically) nothing would prevent an application from using ARGB visuals without a compositor (although the use of ARGB visuals without a compositor will unlikely produce the expected result, ie transparency :) Let's not forget that the embedded compositor in xfwm4 can be enabled/disabled on the fly without restarting, but the visual use by applications cannot be changed that easily. It would be better IMHO not to use ARGB in that case anyway.