web page background render errors

Bug #186186 reported by Adi Roiban
126
This bug affects 1 person
Affects Status Importance Assigned to Milestone
XULRunner
Fix Released
High
cairo (Ubuntu)
Fix Released
Medium
Unassigned
epiphany-browser (Ubuntu)
Invalid
High
Ubuntu Desktop Bugs
firefox-3.0 (Ubuntu)
Fix Released
High
Alexander Sack
xorg-server (Ubuntu)
Fix Released
Medium
Bryce Harrington
xulrunner-1.9 (Ubuntu)
Fix Released
High
Alexander Sack

Bug Description

WORKAROUND: use EXA if your xorg driver supports this.

Binary package hint: epiphany-browser

i'm using ubuntu hardy and epiphany 2.21.4 is displaying the background of some pages in a messed way.

for example http://balsa.gnome.org, see the attachment

Related branches

Revision history for this message
In , Bugs-zzxc (bugs-zzxc) wrote :

Created attachment 298629
Screenshot of page in URL

Adding screenshot of URL

Revision history for this message
In , L. David Baron (dbaron) wrote :

I see this as well. I'm using the radeon driver (that's the free one) on Fedora 8.

Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

Matthew says he's using the 'ati' driver (which I assume is 'radeon' by another name?).

What changed in cairo is that the X server started reporting a different version number, without changing the vendor string -- so for a while there it was reporting version 1.x and cairo was setting buggy_repeat on for all servers under 6.8; this was recently fixed to only look at servers > 6.0.

So we have a problem; this may be driver-specific. I have a radeon machine at work now with ubuntu on it, i'll check this tomorrow.

If this -is- driver specific, I have no idea what to do. The buggy_repeat path is slow.

Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

Note that we have an easy workaround, if necessary, for the beta: we go back to the old 'broken' variant and unconditionally set broken_repeat to TRUE.

I don't think we have a good way of detecting which driver is in use at runtime (maybe we can fudge it if GLX is enabled and getting the OpenGL renderer string?).

Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

Yeah, I can reproduce this with the ati/radeon driver. Ugh.

Revision history for this message
Adi Roiban (adiroiban) wrote :

Binary package hint: epiphany-browser

i'm using ubuntu hardy and epiphany 2.21.4 is displaying the background of some pages in a messed way.

for example http://balsa.gnome.org, see the attachment

Revision history for this message
Adi Roiban (adiroiban) wrote :
Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

*** Bug 414139 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

*** Bug 414107 has been marked as a duplicate of this bug. ***

Revision history for this message
In , jkloosterman (yemenim) wrote :

I was asked to describe my configuration: I run X.org 7.2 with the sis display
driver, version 0.9.3.

Revision history for this message
In , jkloosterman (yemenim) wrote :

Sorry, that should be X.org 1.3.0, X11R7.2.

Revision history for this message
In , Ajschult (ajschult) wrote :

I'm also using the radeon driver with xorg 1.3.0.0

Revision history for this message
In , Ajschult (ajschult) wrote :

Oh, and the radeon driver is apparently version 6.7.196

Revision history for this message
In , Bugzilla-dolphinling (bugzilla-dolphinling) wrote :

I get this with xorg 1.3.0.0 and the intel i810 driver.

Revision history for this message
Dean Sas (dsas) wrote :

I can confirm this, it's not as simple as it happening on some pages and not on others though. Sometimes a webpage goes crazy, and then seconds later it's completely normal. I haven't yet noticed a pattern.

Changed in epiphany-browser:
assignee: nobody → ubuntu-desktop
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

Created attachment 299854
beta bandaid

Okay; I do not want to ship a beta with this bug, because in the worst case it can cause X server crashes or other massive system instability. Instead, this patch enabled the old workaround at the cost of some performance.

Revision history for this message
Tony Yarusso (tonyyarusso) wrote :

I can also confirm this - see the screenshot at http://www.flickr.com/photos/tonyyarusso/2219270945/.
Like Dean, I have not been able to establish a pattern, but it has happened multiple times. I have actually had the same problem in both Epiphany and Firefox 3.0, both of which I believe use Gecko 1.9.

Revision history for this message
Dean Sas (dsas) wrote :

Apologies to all of those people receiving this who shouldn't be - I assigned the wrong desktop team to the bug. Sorry.

Changed in epiphany-browser:
assignee: ubuntu-desktop → desktop-bugs
Revision history for this message
Alexander Sack (asac) wrote :

reassigning to xulrunner-1.9. Maybe its system-cairo?

Changed in firefox-3.0:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Alexander Sack (asac) wrote :

not an epiphany bug from what i can tell.

Changed in epiphany-browser:
status: Confirmed → Invalid
Revision history for this message
In , Sylvain Pasche (sylvain-pasche) wrote :

*** Bug 415067 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Mozilla-behdad (mozilla-behdad) wrote :

We're working on fixing this in cairo very soon.

Revision history for this message
In , Matěj Cepl (mcepl) wrote :

This is on Fedora/Rawhide with the latest xorg-x11-drv-ati and firefox3
packages (upgraded daily)

Revision history for this message
Alexander Jones (alex-weej) wrote :

I notice that when you open a new tab, or while a page is loading, you often get some random rendering in the page area. Looks like the left-overs from an earlier window rendering (GTK) or something.

This also happens on http://fretsonfire.sourceforge.net/

And it doesn't affect Firefox, only Epiphany.

Revision history for this message
Fabien Tassin (fta) wrote :

This seems to be related to cairo (used by xulrunner-1.9), or more precisely, to one of the patch used by Ubuntu (as the embedded cairo shipped by Mozilla is not affected). Most probably the lcd subpixel filter patch.

Strangely, those rendering errors seem to occur only on ATI when using XAA (confirmed on fglrx and radeon X drivers).

Revision history for this message
Tony Yarusso (tonyyarusso) wrote :

To add information, my experience of this bug was while using an ATI Radeon Mobility X300, with the radeon driver, for whatever that's worth.

Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

*** Bug 409162 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Yesilikeyou (yesilikeyou) wrote :

Created attachment 302403
Example page: teletext.ch (correct display with FF2)

Revision history for this message
In , Yesilikeyou (yesilikeyou) wrote :
Revision history for this message
In , Yesilikeyou (yesilikeyou) wrote :
Revision history for this message
Kai Schroeder (kai-schroeder) wrote :

I can't reproduce this bug using beta 3 - anyone else?

Revision history for this message
Fabien Tassin (fta) wrote :

I do: http://www.topachat.com/ (fglrx and XAA)

Revision history for this message
Luca Carrogu (motoplux) wrote :

I can reproduce this bug with both provided link.
I have:
dpkg -l | grep firefox
ii firefox 3.0~b3+nobinonly-0ubuntu1 meta package for the popular mozilla web browser
ii firefox-3.0 3.0~b3+nobinonly-0ubuntu1 lightweight web browser based on Mozilla
ii firefox-3.0-gnome-support 3.0~b3+nobinonly-0ubuntu1 Support for Gnome in Mozilla Firefox

dpkg -l | grep fglrx
ii fglrx-control 1:8-01+2.6.24.8-7.19 Control panel for the ATI graphics accelerators
ii xorg-driver-fglrx 1:7.1.0-8-01+2.6.24.8-7.19 Video driver for ATI graphics accelerators
ii xorg-driver-fglrx-dev 1:7.1.0-8-01+2.6.24.8-7.19 Video driver for ATI graphics accelerators (devel files)

dpkg -l | grep xulrunner
ii xulrunner-1.9 1.9~b3+nobinonly-0ubuntu2 XUL + XPCOM application runner
ii xulrunner-1.9-gnome-support 1.9~b3+nobinonly-0ubuntu2 Support for Gnome in xulrunner-1.9 applications

Revision history for this message
stefanlew (stefan-lew) wrote :

Happens for me on http://venezialibera.altervista.org/acqualta/acqualta.htm with

firefox Version: 3.0~b3+nobinonly-0ubuntu1
xulrunner-1.9 Version: 1.9~b3+nobinonly-0ubuntu2

Revision history for this message
Alexander Sack (asac) wrote :

this definitly is cairo related. though the main cause is probably an xorg bug.

Changed in cairo:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Alexander Sack (asac) wrote :

high impact bug for xulrunner and blocks ubuntu beta for now.

Changed in xulrunner-1.9:
importance: Medium → High
milestone: none → ubuntu-8.04-beta
Revision history for this message
Fabien Tassin (fta) wrote :

Here is a workaround (also used by Mozilla) while waiting for cairo or X.org devs to fix it properly.

Changed in xulrunner:
status: Unknown → In Progress
Revision history for this message
Sebastien Bacher (seb128) wrote :

Is there a libcairo bug opened upstream about that? I'm not wanting to include workarounds for things which are not being discussed there

Revision history for this message
In , Fta+bugzilla (fta+bugzilla) wrote :

vlad, is there a bug opened on the cairo and/or X.org side ?

Revision history for this message
Alexander Sack (asac) wrote :

I don't think we want to apply this workaround until it becomes obvious that we won't get a real fix for this in this cycle (e.g. apply for beta).

Revision history for this message
Alexander Sack (asac) wrote :

confirming xorg source package for now (not sure if the XAA code to allocate/create pictures with REPEAT_NORMAL resides in that source package) Bryce, any info on where that code is would be appreciated.

Thanks,
 - Alexander

Changed in xorg:
assignee: nobody → bryceharrington
importance: Undecided → Medium
milestone: none → ubuntu-8.04-beta
status: New → Confirmed
Revision history for this message
Klaus Heinrich Kiwi (klauskiwi) wrote :

I can confirm the bug using either Epiphany or Firefox3 beta 3 (Ubuntu Hardy, current). Another (interesting) testcase:
1. Go to http://moinmo.in/WikiSandBox
2. Hit the Edit(text) button
3. Edit something
4. Hit the 'Preview' button

Revision history for this message
In , Klaus Heinrich Kiwi (klauskiwi) wrote :

*** Bug 418632 has been marked as a duplicate of this bug. ***

Revision history for this message
Vytas (vytas) wrote :

I can confirm this in firefox 3 beta 3 on up-to-date Ubuntu Hardy, reproducible with the testcase from Klaus Heinrich and some other pages.

Tthis started affecting me only after Feb 20 or Feb 19 updates, earlier it was fine with the same ff 3 beta 3.

Revision history for this message
Martin Gustafsson (martin-gustafsson) wrote :

Experience the same bug (I think) in firefox3beta3 for the following sites.
www.vasttrafik.se/sv
www.fritidsresor.se

Revision history for this message
Vytas (vytas) wrote :

I reproduced the same bug with midori, which has nothing to do with firefox/XUL/Gecko, so cairo is definitely to be blamed here

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

I can confirm it but not with all of the provided websites.
One that has the bug all the time is: http://users.snip.net/~gbooker/

Revision history for this message
Vytas (vytas) wrote :

Strange, I cannot reproduce it anymore

Revision history for this message
TundraMan (asselsm) wrote :

Similar issue can be seen on iGoogle. I have the planet theme for iGoogle and the top banner image shows part of the firefox window, make sure your browser window is wide enough as it happens on the right.

Youtube is another place, the search and upload buttons have the window frame titlebar as the background.

Revision history for this message
Stephen Cradock (s-cradock) wrote :

This bug makes it difficult for me (and others, I'm sure) to use Firefox 3.0 beta 3 in Hardy. But there seems to be no acknowledgment that it affects Firefox 3 - can that be added to the list of affected packages? I confirmed a report of the bug as affecting Firefox, but it was marked a duplicate of this bug and doesn't seem to connect from "bugs affecting Firefox".

Revision history for this message
Paul Lambert (p-lambert) wrote :

for me this occurs when compiz is disabled, but not when it is enabled.

using open ATi drivers.

Revision history for this message
Stephen Cradock (s-cradock) wrote :

for me it occurs in Hardy 32-bit or Hardy 64-bit with Firefox 3.0 beta 3, but not in Gutsy 32-bit with Firefox 3.0 b3pre. It's interesting that Paul mentions Compiz - I have Compiz enabled in Gutsy 32-bit, using fglrx and xgl, but not in hardy. Compiz won't run for me in Hardy either with open-source or proprietary drivers for my ATI Radeon Xpress 200M (5955) card.

Revision history for this message
ubeuther (ubeuther) wrote :

Yes, I'm also using a Radeon card. relevant /var/Xorg.log snippets:

X.Org X Server 1.4.0.90
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu4)
Current Operating System: Linux feh 2.6.24-8-generic #1 SMP Thu Feb 14 20:40:45 UTC 2008 i686
Build Date: 20 February 2008 11:54:41AM

(II) LoadModule: "ati"
(II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so
(II) Module ati: vendor="X.Org Foundation"
 compiled for 1.4.0.90, module version = 6.8.0 [wasn't this just released??]

(II) LoadModule: "radeon"
(II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so
(II) Module radeon: vendor="X.Org Foundation"
 compiled for 1.4.0.90, module version = 4.3.0
 Module class: X.Org Video Driver
 ABI class: X.Org Video Driver, version 2.0

(II) Primary Device is: PCI 01:00:0
(--) Assigning device section with no busID to primary device
(WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found
(--) Chipset ATI Radeon 9200 5961 (AGP) found

(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.28.0
(==) RADEON(0): Page Flipping disabled
(II) RADEON(0): Will try to use DMA for Xv image transfers
(II) RADEON(0): Generation 2 PCI interface, using max accessible memory
(II) RADEON(0): Detected total video RAM=262144K, accessible=131072K (PCI BAR=131072K)
(--) RADEON(0): Mapped VideoRAM: 131072 kByte (128 bit DDR SDRAM)
(II) RADEON(0): Color tiling enabled by default

(==) RADEON(0): Using XAA acceleration architecture
(II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Loading /usr/lib/xorg/modules//libxaa.so

(II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message.

(II) AIGLX: Loaded and initialized /usr/lib/dri/r200_dri.so

-------------------------------------------------------------------------------

LCD Samsung monitor at "native" resolution of 1280x1240@60
according to the "Screen Resolution" app, but the xorg.conf file generated
on this fresh installation of Hardy alpha 5 is disturbingly bare:

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "us"
EndSection

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
EndSection

Section "Device"
 Identifier "Configured Video Device"
EndSection

Section "Monitor"
 Identifier "Configured Monitor"
EndSection

Section "Screen"
 Identifier "Default Screen"
 Monitor "Configured Monitor"
 Device "Configured Video Device"
EndSection

Shouldn't there be a section for DRI as well ?
(saw nothing relevant to GLX accel in "xdpyinfo" output)

On the plus side, the keyboard settings issue seems resolved.

Revision history for this message
stefanlew (stefan-lew) wrote :

I just wanted to add that I'm NOT using an ATI card.

stefan@stefan-laptop:~$ lspci -nn | grep VGA
01:00.0 VGA compatible controller [0300]: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter [1039:6325]

Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

As is, this bug is fixed (AFAIK); there is still an underlying issue here, but we can't fix that on the mozilla side.

Changed in xulrunner:
status: In Progress → Fix Released
Revision history for this message
Alexander Sack (asac) wrote :

ok i confirm this for firefox-3.0 even though the bug is further down the software stack (e.g. cairo + xorg).

Changed in firefox-3.0:
importance: Undecided → High
milestone: none → ubuntu-8.04-beta
status: New → Confirmed
Changed in epiphany-browser:
importance: Medium → High
description: updated
Revision history for this message
laltopi (gdghare) wrote :

Also observed when rendering the default youtube page.

Revision history for this message
Stephen Cradock (s-cradock) wrote :

as of March 3rd firefox 3.0 beta 3 on Hardy 64-bit no longer shows this bug.

Don't know if it was a libcairo2 update that fixed it - I have 1.5.8-0ubuntu1, I believe.

I have checked with the msnbc news page and several of the pages others have reported as showing errors. Still using fglrx and an ATI Radeon Xpress 200M card. There was also an xorg-xserver-fglrx update recently, so it could be that fixed it.

Anyway, thanks for the fix - now I can use firefox 3 as my default browser.

Revision history for this message
drewcoll (drewcoll) wrote :

I have gotten overlays of windows/panels etc. earlier, but it seems that is fixed. Now, when scrolling the images on the page seem to overlap on themselves and streak. When highlighted they return to normal.

Should this be the same bug?

Revision history for this message
Stephen Cradock (s-cradock) wrote :

(furthur to my report that it is no longer apparent in Hardy 64-bit)

but in Hardy 32-bit, upgrading Firefox to Firefox 3 beta 3 still gives me the incorrect rendering on the msnbc news page. The libcairo2 version is the new one, updated and re-installed today. The major difference is that this install is using the open-source radeon driver instead of fglrx...... Same ATI Radeon Xpress 200M card, with drivers from the DRI 300 Project.

So, still not fixed for the open-source driver package.......back to Firefox 2 for the 32-bit Hardy.....

Revision history for this message
Michael Losonsky (michl) wrote :

Still a problem in Hardy Alpha 5 and Firefox Beta 3

Revision history for this message
U. B. (u710bts) wrote :

I confirm this.

Website atilf.atilf.fr does it too (Procedure: Connexion rapide > Entrez dans le TLF > Correcteur d'erreurs: bonjour > Valider1).

Probably relevant packages:
xserver-xorg 1:7.3+10ubuntu6
xserver-xorg-core 2:1.4.1~git20080131-1ubuntu4
xserver-xorg-video-nv 1:2.1.7-1
firefox 3.0~b3+nobinonly-0ubuntu4

Revision history for this message
TundraMan (asselsm) wrote :

Seems to be fixed in the latest firefox update.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cairo - 1.5.12-0ubuntu1

---------------
cairo (1.5.12-0ubuntu1) hardy; urgency=low

  * New upstream version: 1.5.12
  * Drop patch applied upstream
    - drop debian/patches/01-fixed_point_24.8_precision.dpatch
    - update debian/patches/00list
  * Refresh diverged debian/patches/02-lcd_filter_freedesktop_bug10301.dpatch
  * Update shlibs version
    - update debian/rules
  * Add workaround for background corruption in firefox 3 by
    setting buggy_repeat inconditionally (LP: #186186)
    - add debian/patches/03-turn_on_buggy-repeat_handling.dpatch
    - update debian/patches/00list

 -- Fabien Tassin <email address hidden> Fri, 29 Feb 2008 22:54:20 +0100

Changed in cairo:
status: Confirmed → Fix Released
Revision history for this message
Fabien Tassin (fta) wrote :

For the records, here is my view of the situation:

it's a compositing bug (at least) in ATI drivers which are not able to use either an untransformed repeating source pattern with a source in off-screen video memory, or, a repeated transformed images using a general transform matrix (or both).

Cairo has 3 fallback mechanisms when 'XRenderComposite' is not usable:
- XCopyArea (not usable with alpha compositing)
- XSetTile (for the repeat patterns with general transform bug, also not usable with alpha, and not with 1x1 surfaces)
- or software rendering (slower)

Problem with our background rendering bug is that it seems it's always with alpha so we end-up with either XRenderComposite or software rendering. To detect if XRenderComposite has a bug, Cairo devs used the X *server* version with known-buggy versions but it doesn't tell which X *driver* it is so we cannot say we want the software workaround for ATI only, hence the unconditional patch above.

An improved patch could try to figure out at runtime what the X driver name & version are, and maybe the Acceleration method too, then trigger software rendering only for the known buggy drivers. AFAIK, there's no way to get those information except by parsing /var/log/Xorg.0.log

Revision history for this message
Alexander Sack (asac) wrote :

here a bit more context ...

a post from cworth:

http://article.gmane.org/gmane.comp.freedesktop.xorg/26437

the bug is expected manifests itself in failed extend-reflect and extend-reflect-similar testcases. Some users even reported crashes for those testcases.

cworth is currently working on improving the testcase in aboves code to trigger this bug.

Revision history for this message
Alexander Sack (asac) wrote :

TESTING extend-reflect-similar
Test CAIRO_EXTEND_REFLECT for surface patterns
extend-reflect-similar-image-argb32 [0]: PASS
extend-reflect-similar-image-argb32 [25]: PASS
extend-reflect-similar-image-rgb24 [0]: PASS
extend-reflect-similar-image-rgb24 [25]: PASS
extend-reflect-similar-xlib-argb32 [0]: FAIL
extend-reflect-similar-xlib-argb32 [0] (similar): FAIL
extend-reflect-similar-xlib-argb32 [25]: FAIL
extend-reflect-similar-xlib-argb32 [25] (similar): FAIL
extend-reflect-similar-xlib-rgb24 [0]: FAIL
extend-reflect-similar-xlib-rgb24 [0] (similar): FAIL
extend-reflect-similar-xlib-rgb24 [25]: FAIL
extend-reflect-similar-xlib-rgb24 [25] (similar): FAIL
extend-reflect-similar-xlib-fallback-rgb24 [0]: PASS
extend-reflect-similar-xlib-fallback-rgb24 [0] (similar): FAIL
extend-reflect-similar-xlib-fallback-rgb24 [25]: PASS
extend-reflect-similar-xlib-fallback-rgb24 [25] (similar): FAIL
extend-reflect-similar-ps-argb32 [0]: PASS
extend-reflect-similar-ps-argb32 [25]: PASS
extend-reflect-similar-ps-rgb24 [0]: PASS
extend-reflect-similar-ps-rgb24 [0] (similar): PASS
extend-reflect-similar-ps-rgb24 [25]: PASS
extend-reflect-similar-ps-rgb24 [25] (similar): PASS

Revision history for this message
Alexander Sack (asac) wrote :

$ make test TESTS=extend-reflect
make[1]: Entering directory `/home/asac/gnome/cairo/test'
Making check in pdiff
make[2]: Entering directory `/home/asac/gnome/cairo/test/pdiff'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory `/home/asac/gnome/cairo/test/pdiff'
Making check in .
make[2]: Entering directory `/home/asac/gnome/cairo/test'
make imagediff png-flatten
make[3]: Entering directory `/home/asac/gnome/cairo/test'
make[3]: `imagediff' is up to date.
make[3]: `png-flatten' is up to date.
make[3]: Leaving directory `/home/asac/gnome/cairo/test'
make check-TESTS check-local
make[3]: Entering directory `/home/asac/gnome/cairo/test'

TESTING extend-reflect
Test CAIRO_EXTEND_REFLECT for surface patterns
extend-reflect-image-argb32 [0]: PASS
extend-reflect-image-argb32 [25]: PASS
extend-reflect-image-rgb24 [0]: PASS
extend-reflect-image-rgb24 [25]: PASS
extend-reflect-xlib-argb32 [0]: FAIL
extend-reflect-xlib-argb32 [0] (similar): FAIL
extend-reflect-xlib-argb32 [25]: FAIL
extend-reflect-xlib-argb32 [25] (similar): FAIL
extend-reflect-xlib-rgb24 [0]: FAIL
extend-reflect-xlib-rgb24 [0] (similar): FAIL
extend-reflect-xlib-rgb24 [25]: FAIL
extend-reflect-xlib-rgb24 [25] (similar): FAIL
extend-reflect-xlib-fallback-rgb24 [0]: PASS
extend-reflect-xlib-fallback-rgb24 [0] (similar): FAIL
extend-reflect-xlib-fallback-rgb24 [25]: PASS
extend-reflect-xlib-fallback-rgb24 [25] (similar): FAIL
extend-reflect-ps-argb32 [0]: PASS
extend-reflect-ps-argb32 [25]: PASS
extend-reflect-ps-rgb24 [0]: PASS
extend-reflect-ps-rgb24 [0] (similar): PASS
extend-reflect-ps-rgb24 [25]: PASS
extend-reflect-ps-rgb24 [25] (similar): PASS
Check extend-reflect.log out for more information.
FAIL: extend-reflect
========================================================================
1 of 1 tests failed
Please report to http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
========================================================================
make[3]: *** [check-TESTS] Error 1
Failed tests:
     extend-reflect: xlib xlib-fallback
Failures per surface - xlib: 1, xlib-fallback: 1.

Revision history for this message
Nanley Chery (nanoman) wrote :

Do you still have this problem in firefox? It seems to be fixed in Firefox 3 Beta 4.

Changed in firefox-3.0:
assignee: nobody → nanoman
status: Confirmed → Incomplete
Revision history for this message
Steve Langasek (vorlon) wrote :

This bug should not be marked 'incomplete' when it's already been confirmed. Either the bug is confirmed or the fix is released, the bug shouldn't be put in a position where it can expire out.

Nanley, were you able to reproduce this bug with earlier versions of firefox 3.0? The bug is specific to a particular combination of hardware and X settings, so it's not reproducible for all users; and I don't see mention of changes to any of the affected packages that would resolve this.

Changed in firefox-3.0:
status: Incomplete → Confirmed
Revision history for this message
drewcoll (drewcoll) wrote :

I still have the streaking image problem. My updates are current. FF3.0 B4.

Is this the same bug? I don't think so. Even after reinstalling Hardy, it renders this way until the images are highlighted.

Revision history for this message
Nanley Chery (nanoman) wrote :

@Steve:
Sorry about that. I thought this bug was an obvious problem that would be solved in beta4. I did have this error in Firefox3b3 (when visiting sites like youtube and wiki.ubuntu.com) and now with b4 it is gone. I am on an SIS chip.

Bryce Harrington (bryce)
Changed in xorg-server:
assignee: bryceharrington → nobody
Steve Langasek (vorlon)
Changed in firefox-3.0:
milestone: ubuntu-8.04-beta → ubuntu-8.04
Changed in xorg-server:
milestone: ubuntu-8.04-beta → ubuntu-8.04
Steve Langasek (vorlon)
Changed in xulrunner-1.9:
milestone: ubuntu-8.04-beta → ubuntu-8.04
Revision history for this message
Bryce Harrington (bryce) wrote :

Alexander, I see that this has a component filed against xorg-server; could you explain what is needed to be done at the xorg-server level?

If it is just the question about the XAA code, I'm not sure I follow the question, could you ask the question again in more detail?

In general, XAA is in the process of being deprecated in favor of EXA. In some drivers like -intel we've already mostly switched over to EXA, and won't be investigating XAA bugs. If the issue is particular to an XAA-using driver that won't be switched over to EXA, we could look into that but would need to know more details (like which driver and card pci id are involved).

Alexander Sack (asac)
Changed in xulrunner-1.9:
assignee: nobody → asac
Changed in firefox-3.0:
assignee: nanoman → asac
Revision history for this message
Alexander Sack (asac) wrote :

we already workaround this issue in xulrunner. Since its not a real fix i keep it open, but move the milestone to later.

Changed in xulrunner-1.9:
milestone: ubuntu-8.04 → later
Revision history for this message
Alexander Sack (asac) wrote :

same for firefox target ... which only was kept open to catch duplicate reports against firefox-3.0

Changed in firefox-3.0:
milestone: ubuntu-8.04 → later
Colin Watson (cjwatson)
Changed in xorg-server:
assignee: nobody → bryceharrington
Revision history for this message
Bryce Harrington (bryce) wrote :

Ah, okay; postponing xorg milestone as well.

Changed in xorg-server:
milestone: ubuntu-8.04 → none
Revision history for this message
Shirish Agarwal (shirishag75) wrote :

HI all,
 I had filed Bug 202748 which is supposed to be duplicate of this bug. I'm on I845G chipset. What's happening at my end is many a times if I click on the webpage a little fast the content which is on right hand side goes to left-hand side & vice-versa. Kinda like for somebody who may be writing urdu or something like that. An example would be this page itself where the box for adding comments is on the right hand side while its blank on the left-hand side. Sometimes it would become reverse with the box for comments appearing on the left and the blank space on the right. And this convention would follow throughout the page. I don't have any screenshot atm but can do the same if required.

Reproducibility :- Sometimes and randomly.
Steps to reproduce :- click fast on the webpage just after you have switched on the webpage or it has been refreshed just then.
It doesn't happen if you are slow or have been on the same page for a long time .

Revision history for this message
Shirish Agarwal (shirishag75) wrote :

I'm on updated 3.0b4

Revision history for this message
Pavel Rojtberg (rojtberg) wrote :

as far as I can see there is a patch to the radeon driver in git to fix this:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c40a7aa3989576a8144213e2f31b892d21df8686

Revision history for this message
Bryce Harrington (bryce) wrote :

@Pavel, how did you arrive at that patch as a fix for this bug? (Not arguing against the patch, just curious). I note that the patch affects the EXA code in the -ati driver, where I understood this particular render bug only occurs in XAA, and goes away when using EXA.

(Are multiple bugs being globbed together here by chance?)

Revision history for this message
Pavel Rojtberg (rojtberg) wrote :

I might be as well wrong. I just saw that the patch fixed something related to repeat textures and recalled that the bug is caused by buggy_repeat. So I thought this might fix it. Though I did not try it myself yet...

Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

*** Bug 428505 has been marked as a duplicate of this bug. ***

Revision history for this message
Alexander Sack (asac) wrote :

fedora ships with XaaNoOffscreenPixmaps "true" for _all_ drivers by default.

Revision history for this message
ojab (ojab) wrote :
Revision history for this message
Bryce Harrington (bryce) wrote :

This bug was fixed in the package xorg-server - 2:1.4.1~git20080131-1ubuntu8

---------------
xorg-server (2:1.4.1~git20080131-1ubuntu8) hardy; urgency=low

  * debian/patches/165_fedora_xserver-1.5.0-xaa-option-inversion.patch:
    - Turn XAA Offscreen Pixmaps off by default, and use
      XaaOffscreenPixmaps "true" to turn them on. This setting was an
      early pre-EXA HW optimization attempt that didn't pan out; upstream is
      deprecating XAA in favor of EXA generally, and for situations where
      XAA is still in use recommends NOT using this optimization hack, since
      they found it often just made performance worse, and sometimes created
      visualization bugs. People wishing to gain added performance should be
      experimenting with EXA anyway, not this setting. (closes LP: #182038)

 -- Bryce Harrington <email address hidden> Mon, 14 Apr 2008 12:34:54 -0700

Changed in xorg-server:
status: Confirmed → Fix Released
Revision history for this message
Alexander Sack (asac) wrote :

reopening cairo part of this bug. we should backout the beta band-aid patch in intrepid given that this is now fixed by xserver. Doing so will increase performance for EXA again.

I verified that the xserver fix alone is enough.

Milestoning as later (intrepid) accordingly.

Changed in cairo:
milestone: none → later
status: Fix Released → Triaged
Revision history for this message
Alexander Sack (asac) wrote :

the xserver fix will ship for real in 2:1.4.1~git20080131-1ubuntu9

Revision history for this message
Alexander Sack (asac) wrote :

the real fix landed in xorg-server update. closing xulrunner.

Changed in xulrunner-1.9:
status: Confirmed → Fix Released
Revision history for this message
Alexander Sack (asac) wrote :

the real fix landed in xorg-server update. closing firefox task accordingly.

Changed in firefox-3.0:
status: Confirmed → Fix Released
Bryce Harrington (bryce)
Changed in cairo:
milestone: later → intrepid-alpha-1
Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 186186] Re: web page background render errors

On Wed, May 14, 2008 at 02:13:42AM -0000, Bryce Harrington wrote:
> ** Changed in: cairo (Ubuntu)
> Target: later => intrepid-alpha-1
>

this was fixed by switching default to no offscreen pixmaps in
hardy. as long as we keep this we won't need a fix for this. in any
case its a xserver issue ...

 - Alexander

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cairo - 1.6.4-1ubuntu1

---------------
cairo (1.6.4-1ubuntu1) intrepid; urgency=low

  * Drop buggy_repeat band-aid now that xorg-server fixes the issue
    directly (LP: #186186)
  * Merge from debian unstable (1.6.4-1). Remaining ubuntu changes:
    - debian/control:
      - Maintainer: Ubuntu Core Developers <email address hidden>
      - Build-depends and Depends: libfontconfig1-dev >= 2.5.0-2ubuntu2 and
        libfreetype6-dev >= 2.3.5-1ubuntu4
    - debian/rules:
      - Pass -c4 to dpkg-gensymbols
    - debian/patches/02-lcd_filter_freedesktop_bug10301.dpatch

 -- Fabien Tassin <email address hidden> Fri, 09 May 2008 15:02:48 +0200

Changed in cairo:
status: Triaged → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote :

Hello,

As you can see from the last comment on this bug, the change to cairo has now been reverted on the grounds that a more correct fix has been applied to the X server.

The same fix is present in the X server in Ubuntu 8.04, and a stable release update for cairo has been proposed to revert this patch in 8.04 as well due to some performance problems that it introduced.

Can the folks who originally encountered the web page background errors in hardy please test the cairo 1.6.0-0ubuntu2 package from hardy-proposed, and follow up with their experiences to bug #219587, so that we can be sure this bug is really fixed before pushing it out to all users of 8.04?

Revision history for this message
Martin Pitt (pitti) wrote :

Hello all,

none of this bug's subscribers has reported back on bug 219587 so far, thus we cannot move the proposed cairo version to hardy-updates. Can you please enable hardy-proposed and use the new cairo version for a while? Please particularly test it for the rendering errors you experienced when reporting this bug.

Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to use the -proposed repository. Thank you!

Revision history for this message
Martin Pool (mbp) wrote :

I have hardy-proposed installed, and have not encountered this bug again for a long time. I don't use evolution though...

I'm not completely sure what you want us to test.

Revision history for this message
Felix Crux (felixc) wrote :

Hello,
This issue appears to have resurfaced in the jaunty alpha version of Firefox. As most of the above, I have an ATi card, and have reproduced the issue under both the closed and open source drivers. Please let me know if I can provide any further information.

Running: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121711 Ubuntu/9.04 (jaunty) Firefox/3.0.5

Revision history for this message
Matteo Settenvini (tchernobog) wrote :

Confirming this happens also for me in Jaunty on two PCs: a laptop using the "intel" driver, and a powerpc64 using a nVidia card. In both cases lesser artifacts are seen in *every* page you visit.

I have to add that other problems have arisen also for other parts of the desktop using gtk+ & cairo for rendering (icons in gnome-panel, toolbars in applications, widgets, etc.), so it's not related to firefox imo. Mostly the problem seems to arise when using pixbufs (?).

Revision history for this message
Alexander Sack (asac) wrote :

On Thu, Dec 18, 2008 at 02:31:25AM -0000, Felix Crux wrote:
> Hello,
> This issue appears to have resurfaced in the jaunty alpha version of Firefox. As most of the above, I have an ATi card, and have reproduced the issue under both the closed and open source drivers. Please let me know if I can provide any further information.

is that fglrx or ati driver?

 - Alexander

Changed in xulrunner:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.