User-Agent: Opera/9.24 (X11; Linux i686; U; en) Build Identifier: If the compositor is enabled via Window Manager Tweaks, programs that use various colors (such as the Jed editor) show the colors wrong, sporatically. When scrolling through a file, the colors flip from regular to bright. If another Terminal window is placed behind this window, the contents of that window affect the brightness on the colors of this window. Using Xorg intel driver. Reproducible: Always Steps to Reproduce: 1. Enable compositor 2. Open Terminal and display something with colors 3. Try placing an empty (black) terminal window behind the window from #2 and re-display something with colors Actual Results: Colors are not displayed properly at step #2. They are displayed properly at step #3. Expected Results: All colors should be displayed with proper intensity.
Hm, either a bug in VTE or the compositor or something in Xorg. Dunno. Ideas?
(In reply to comment #1) > Hm, either a bug in VTE or the compositor or something in Xorg. Dunno. Ideas? > Hi, I suspected a compositor bug for two reasons: the bug is only active when the compositor is enabled, and the specific way in which the colors of the letters are drawn incorrectly often resembles the background image. Dragging a window full of text across the background will cause the scrambled colors to change according to the light and dark areas of the background image. Thanks, Steve
I believe this is a known problem, however I tend to believe this is a bug with the Xserver and ARGB windows because 1) it shows with other compositors, 2) it doesn't show with proprietary drivers such as NVidia and 3) switching to 16bpp fixes the issue. BTW, the use of ARGB window with terminal a big problem and cause a lot of issues for people w/out hardware accelerated render (ppl just say Xfce is dead slow just because Terminal is using ARBG and that makes moving/resizing unusable)
Hm, never noticed a slowdown in terminal performance.
(In reply to comment #4) > Hm, never noticed a slowdown in terminal performance. I see it here using 'nv' (nvidia on ppc linux = no accel). I have a wrapper script for Terminal that sets XLIB_SKIP_ARGB_VISUALS; without it, dragging terminals across the screen is jerky and eats CPU. Ditto for fast-scrolling text.
Stupid question maybe, but why does the Xserver provide ARGB visuals if Composite is disabled?
Benny, if you have not noticed a slow down, then you are using a using a driver that implements xrender in hardware (NVidia closed source driver maybe?). Anyway, back on topic, the problem is not with xfwm4 compositor and this is easy to verify: 1) kill xfwm4 2) run xcompmgr The same problem shows even when xfwm4 is not running.
(In reply to comment #6) > Stupid question maybe, but why does the Xserver provide ARGB visuals if > Composite is disabled? Composite != Compositor The Xserver does not advertise ARGB visual if Composite is disabled. However, the problem arises when Composite is Enabled (by default in Xorg 7.x) because the Xserver cannot tell whther or not a _Compositor_ is or will be running at some point.
Right, but if Composite is enabled, I have to request ARGB windows, otherwise Terminal would have to be restarted completely after turning on the compositor. So, the question is basicly, why is composite is enabled for not-hardware accelerated setups? BTW: I use nvidia/ati binary drivers. And I always disable Composite, so that's probably the reason why I do not notice any slow downs.
(In reply to comment #9) > So, the question is basicly, why is composite is enabled for not-hardware > accelerated setups? Because this is the default setup...
> So, the question is basicly, why is composite is enabled for not-hardware > accelerated setups? Because it has the potential to be very useful even when it's not being used for compositing your desktop. For example, it's almost essential for doing a good screen magnifier implementation, or for making out-of-process browser plugins able to merge into the browser window with transparency and/or shaping. The question is why painting ARGB is so slow when you're not compositing, I think.
So is this a VTE bug? If so, then I'll go file a bug report with them. Is there a workaround that XFCE can use to fix it? This is surely one I'd like to see fixed... thanks! Steve
Dunno, as said, may also be a bug in Xorg.
(In reply to comment #13) > Dunno, as said, may also be a bug in Xorg. Yes, I know, but using ARGB by default in Terminal causes a lot of problems, including people claiming that "xfce" is slow because ARBG move/resize is sloooow *even* when the compositor is not activated.
*** This bug has been marked as a duplicate of bug 5529 ***