Yes I know it's beta and hard masked. But it appears to be a problem with the source build as another user doesn't report it with the bin. Just trying to pin it down. I'm attaching a screen shot to demo issue http://omnisio.com/startupschool08/mike-arrington is one of the pages that I noticed it on. Reproducible: Always
Created attachment 150703 [details] screenshot showing rendering problem
Created attachment 150705 [details] emerge --info
I've got the same problem, it seems to be a bug in the XAA-Code of the radeon and flgrx driver. You might set your render method to exa. The people from ubuntu have this problem too, but they worked around it by a patch against cairo. Please have a look here: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/186186
Created attachment 151345 [details, diff] turn_on_buggy-repead_handling This is the work-around used in ubuntu, seems to apply fine to cairo-1.6.4
Okay, this patch seems to resolve the issue for me, tested with the cairo-1.6.4 ebuild, just add the following line to the src_unpack function: epatch ${FILESDIR}/03-turn_on_buggy-repeat_handling.dpatch As the patch to the ebuild is trivial and the patch (when it goes to portage) will probably be rennamed I won't add a new ebuild...
has it been added or do I need to patch manually? I re-installed ff3 and rebuilt cairo. I still see the problem on various sites.
You need to manually add this patch to the cairo ebuild in portage - it's not in, yet.
although technically this isn't resolved until the patch is in cairo, X or at least in portage (I'd be satisfied with any of them). I've tested it and at first glance it appears to have fixed my problem.
can this patch get pushed before firefox-3 final comes out. I've been testing it through rc2 now no problems.
*** Bug 228251 has been marked as a duplicate of this bug. ***
@ Raúl Porcel you should check out bug #221141 it's the black img bug which is separate from this and has an easy work around.
updating title to be more accurate
shouldn't the x11 herd be cc-ed on this since the patch applies to cairo?
Sorry, wrong bug :P cairo is maintained by cardoe
This is an X server bug with XAA using some pre-EXA accleration hacks that were determined to be flawed. As a result, cairo had to hack around it. This patch is merely an extension of that hack and does not fix the underlying issue. It merely forces on an unaccelerated software rendering approach to always be on. Hardly an ideal solution. This patch is akin to saying the truck is out of gas so let's carry the boxes by hand instead of refilling gas tank of the truck. If you want to use XAA over EXA (or your driver is a XAA only driver), it's important you configure your X.org server properly. XaaNoOffscreenPixmaps "true"
is this bug then a dupe or directly related to bug #221141 ? I've been under the impression that they are different problems. But the fix you are suggesting is the same.
Correct. xorg-server upstream has stated a few times that they know XAA is hosed with a few configurations. The reason this crops up in cairo apps is that cairo makes heavy use of the RENDER extension, which is where XAA screws up the most. The situation has become so problematic that upstream has decided for xorg-server 1.5, XAA OffScreen Pixmaps are going to be disabled by default as Donnie noted in bug 221141#c6. You can see all the issues with XAA and Off Screen Pixmaps here: http://tinyurl.com/5qrr7g
Additionally, some discussion about why cairo isn't going to work around every single user configuration, driver, and driver acceleration combination is available here: http://thread.gmane.org/gmane.comp.freedesktop.xorg/26437 You can also see that Ubuntu maintainers have had the same rational here: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/186186 Fedora did the same thing however I can't remember the Gentoo bug number that I referred to it and I can't find it on Fedora's site right now.
(In reply to comment #15) > > XaaNoOffscreenPixmaps "true" > Right, tell it to my "sis" fdriver ;( : (WW) SIS(0): Option "XAANoOffscreenBitmaps" is not used
Take it upstream. Or get new hardware. If your graphics card driver can't do the right thing that it claims it supports, your driver needs to be fixed.
You didn't specify the configuration option correctly, these are not the same: XAANoOffscreenBitmaps XaaNoOffscreenPixmaps
I confirm this bug on my system (Radeon 9200SE, xorg-server-1.4.2, xf86-video-ati-6.9.0). Option "XaaNoOffscreenPixmaps" or switching to EXA (which has other flaws) solves the problem.
(In reply to comment #22) > I confirm this bug on my system (Radeon 9200SE, xorg-server-1.4.2, > xf86-video-ati-6.9.0). Option "XaaNoOffscreenPixmaps" or switching to EXA > (which has other flaws) solves the problem. VGA compatible controller: ATI Technologies Inc M11 NV [FireGL Mobility T2e] (rev 80) With the latest Xorg has the same issues. And can be solved also with the XaaNoOffscreenPixmaps.
*** Bug 236289 has been marked as a duplicate of this bug. ***
This issue can be worked around also with changing environment, according to https://bugzilla.mozilla.org/show_bug.cgi?id=404557 : export MOZ_DISABLE_IMAGE_OPTIMIZE=1 When Fx starts with this env, the issue does not occur (I tested it, and there are another confirmation reports in mentioned mozilla bug).
Xorg-server 1.5.3-r5 now being stable, the server no longer uses offscreen pixmaps by default. Given all the trouble caused by XAA, I strongly suggest the mozilla herd didn't try to work around this particular bug. Closing fixed Thanks
