|
Bugzilla – Full Text Bug Listing |
| Summary: | Checkerboard-like artifacts in Qt/GTK widgets | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | Jiri Dluhos <jdluhos> |
| Component: | X.Org | Assignee: | Stefan Dirsch <sndirsch> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Major | ||
| Priority: | P1 - Urgent | CC: | bitdealer, eich, jnelson-suse, locilka, sndirsch, snwint, tgoettlicher |
| Version: | Beta 1 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Screenshot of the artifacts.
Test case exposing the opacity/alpha channel bug Workaround patch Updated testcase |
||
|
Description
Jiri Dluhos
2008-09-15 16:18:50 UTC
Created attachment 239618 [details]
Screenshot of the artifacts.
Note: the screenshot shows a Firefox window, but the problem is not specific to Firefox; it seems to occur in any GTK-based application. Note 2: It seems that this occurs where a color gradient would normally be; it does not occur on plain lines, nor on contiguous single-colored regions. Stefan, do you think it might be a bug in X.org? Try with "noaccel" to verify. The "noaccel" option does not affect this bug; the artifacts are exactly the same. Ok. Then I don't think it's a bug in X.Org. OK, thanks - in this case I'd guess at GTK gradient drawing. Gnome team, please? I could see this until updating to about the beta 1 packages, but now its gone. Do you see it still? In openSUSE 11, the problem disappeared with the most recent updates; I will test with SLES11 beta1 and inform you. I've seen this with Beta 1, and also noticed it in the installer which is using QT. It seemed x.org/driver related. On an ATI card, but not sure what model right now (machine is not in my reach). Also noticed it in the installer; now I'm waiting if it occurs in the installed system as well. Unfortunately, it still occurs in Beta 1 for me, although the patterns may be are a bit different (less noticeable perhaps, but still there) :-( Yes, got it doing a b1 install as well (was just zyppering up before). Moving back to the X team, appears to affect QT and GTK as well as be limited to ATI. The installer runs on a fbdev driven Xserver. Therefore I rule out a driver bug here. Must be bug in the toolkits. Let's try it with KDE now. This seems to happen in any graphics path where alpha blending occurs. For instance, in the installer it is most notable where the box to display the license is rendered, it's very evident when drawing the selection box in Nautilus on the desktop, and when dragging columns in Banshee. In Banshee this is done in Cairo - the column is rendered "live" when dragging, and is rendered with some level of transparency on top of the existing columns. I suspect it's something in the ATI driver, not the toolkit as the path in Banshee really has nothing to do with GTK (we do direct rendering with Cairo onto a GDK-bound context/surface). I am almost sure that ATI driver is not the culprit here; I have experienced this problem on two machines, neither of which have an ATI card (one Intel, one nVidia). it happens with many toolkits, something has regressed or drastically changed behaviour in our X.org packages. How can I easily reproduce this on an installed system (11.1 Beta1)? No, I don't want to test this during installation. Stefan: in GNOME, try dragging on the desktop to cause Nautilus to render its selection rectangle - it's semi-transparent, and exhibits this issue. You can also run Banshee and rearrange columns in the track list. Stefan: you should be able to see the pattern on most color gradients in GTK - I routinely see them on Firefox, as shown on the attached screenshot snippet. However: on my workstation, where I first seen the problem in GTK, it somehow disappeared after last automatic update. I now have: xorg-x11 7.4-5.1, xorg-x11-driver-video 7.4-5.3. My guess is that those aren't actually gradients, but applied alpha blending of elements. I see gradients all over the place without any issues - it's just when something is alpha blended. Matthias, could you have a look at this issue? Thanks. Would it be possible to test this on an older Xserver (ie. remotely)? If the problem goes away it would indicate an issue on the server side. One would also be able to obtain a screen shot of how these parts of the widget are supposed to look like. It looks like the depth of the alpha channel is reported wrong and only the lowest bit is used. *** Bug 427936 has been marked as a duplicate of this bug. *** The bug #427936 (marked as duplicate of this one) is at least major for installation. *** Bug 429831 has been marked as a duplicate of this bug. *** (In reply to comment #25 from Dirk Mueller) > *** Bug 427936 has been marked as a duplicate of this bug. *** So the original reporter became the assignee? Wow! Yes :-/ Does anybody have a simple reproduction case? Read: code. Created attachment 241788 [details]
Test case exposing the opacity/alpha channel bug
If you compile and run this test case you'll be presented with a window and a black rectangle. Adjusting the opacity will yield this bug immediately. What I found interesting is that running the sample multiple times often leads to different "checker board" patterns, suggesting that there might be some corrupt memory regarding the alpha channel in XRender or something.
It's a C# test case, meaning "Mono/Gtk#/Cairo".
"zypper in mono-core gtk-sharp2" should pull the deps needed to reproduce this on openSUSE 11.1 Beta 1. Compilation and execution instructions are at the top of the source file.
Probable culprit: pixman_rasterize_trapezoid Had some issues with gdb, breakpoint in libpixman only work if X is started within gdb, not attached afterwards. No, it's not pixman_rasterize_trapezoid, it's pixman_image_composite / fbCompositeSolid_nx8888sse2, called via miCompositeRects/CompositePicture/fbComposite. The results are only drawn to the visible area with fbCopyRegion (fbCopyNtoN) later on, but are already broken. The pixman_rasterize_trapezoid were from GTK toolkit widgets. -> remember: never create graphics glitch reproduction testcase that renders more than absolutely necessary! The MMX accelerated function fbCompositeSolid_nx8888mmx does work correctly. Created attachment 242324 [details]
Workaround patch
This patch for pixman disables the sse2 paths for compositing solid pixels w/o mask.
Dunno whether the other paths work correctly.
This is not a real fix, but the MMX paths are reasonably fast enough.
Wrote mail for upstream to be aware of this issue. Stefan, please package. Created attachment 242325 [details]
Updated testcase
For completeness - the updated test case that doesn't do any spurious GTK rendering.
*** Bug 429070 has been marked as a duplicate of this bug. *** Indeed this issue is fixed with the update to pixman 0.12.0 on Beta2. Matthias verified this now. So there's no need for his patch. *** Bug 429640 has been marked as a duplicate of this bug. *** *** Bug 426566 has been marked as a duplicate of this bug. *** |