Created attachment 306569 [details] cairo-font-corruption.png After upgrading to cairo-1.12.0, some websites show font corruption in seamonkey. Downgrading to 1.10.2-r2 fixes the issue. Attached screenshot shows http://www.youtube.com/watch?v=6XbEJoR-ypo where the font corruption appears or disappears depending on where you more the mouse. # emerge --info cairo Portage 2.1.10.49 (default/linux/amd64/10.0/desktop/kde, gcc-4.5.3, glibc-2.13-r4, 3.2.1-gentoo-r2 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.2.1-gentoo-r2-x86_64-AMD_Phenom-tm-_II_X4_B50_Processor-with-gentoo-2.0.3 Timestamp of tree: Sat, 24 Mar 2012 15:15:01 +0000 app-shells/bash: 4.2_p20 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.2-r3, 3.1.4-r3, 3.2.2 dev-util/cmake: 2.8.6-r4 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc: 4.5.3-r2 sys-devel/gcc-config: 1.5-r2 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 3.1 (virtual/os-headers) sys-libs/glibc: 2.13-r4 Repositories: gentoo x11 sunrise spring local ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=amdfam10" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -march=amdfam10" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--autounmask=n" FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/" LANG="de_DE.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" LINGUAS="de en fa vi" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/x11 /var/lib/layman/sunrise /var/lib/layman/Spring /usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage/" USE="3dnow X a52 aac acl acpi alsa amd64 avahi berkdb bluetooth branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cups cxx dbus declarative dri dts dvb dvd dvdr emboss encode exif fam firefox flac fortran gcj gdbm gdu gif gnutls gpm gtk iconv ipv6 java jpeg kde kipi lcms ldap libnotify mad mmx mng modules mp3 mp4 mpeg mudflap multilib ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pango pcre pdf phonon plasma png policykit ppds pppd qt3support qt4 readline sdl semantic-desktop session spell sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype udev unicode usb v4l2 vorbis x264 xcb xcomposite xinerama xml xorg xscreensaver xulrunner xv xvid zeroconf zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DVB_CARDS="dibusb-usb1" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en fa vi" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= x11-libs/cairo-1.12.0 was built with the following: USE="X (consolekit) glib (multilib) opengl (policykit) qt4 svg xcb (-aqua) -debug -directfb -doc -drm (-gallium) -openvg -static-libs" CFLAGS="-O2 -pipe -march=amdfam10 -finline-limit=1200" CXXFLAGS="-O2 -pipe -march=amdfam10 -finline-limit=1200"
it must have been some of the changes that got introduced between cairo 1.11.2 and 1.11.4 1.11.2 worked fine for me now I get font-corruption, too at the top of the tab, in the address bar, and - of course - in the site's content a good example is the main page of youtube.com when keeping the left mouse button pressed and moving up and down the corruption is there sometimes but sometimes not - as you move up and down (similar to a rolling shzutter moving up and down) the corruption becomes pretty obvious when scrolling down frames & then hovering over text up & down corruption also appears in gnome-terminal, ... all this happened while using compiz-fusion (compiz 0.8.6*)/compositing with xfce
During the 1.11 development cairo started using xrender more completely, instead of doing some of the rendering itself and just blitting the results to the X server. That seems to be what triggers the bug. It seems to be dependent on memory pressure (perhaps just on the gpu) and transfers between gpu and cpu ram. Small pixmaps are most affected, hense the issues with text. A use after free may be involved. EXA (in the X server) also may be involved. There are several related bugs open on fdo, under cairo and xorg. (I don’t have the list of bz numbers, though.)
@comment 2: happens here on an old radeon (r200) with x11-drivers/xf86-video-ati-6.14.3 x11-base/xorg-server-1.12.0 media-libs/mesa-8.0 x11-misc/xcompmgr-1.1.5 atm. seems only in firefox-11.0 (I don't use anything other mozilla based). IIRC, KMS is no longer EXA, right ?
It might me of interest, that in firefox I sometimes see the coruption in addressbar or in tab titles. In such cases, often even as little as hovering the mouse over corruption is enough to trigger a redraw, that restores the proper state (I say "restores", as the corruption on tab titles seems to be triggered on randomly chosen inactive tabs upon a site's load).
...and it seems mozilla upstream sort of blames cairo for their own hack, if this bug (https://bugzilla.mozilla.org/show_bug.cgi?id=715658) and its followup (https://bugzilla.mozilla.org/show_bug.cgi?id=722975) are related.
CC:ing mozilla per comment 5.
Just my 5c, but that mozilla bug is about a different issue. When an image is loaded, gecko already shows part of the image before all of it loaded (you can see the image "loading"). So that mozilla bug is about an issue with images. This bug is about font corruption instead. Fonts aren't loaded and rendered progressively. :-P
@comment 7: while I haven't downgraded to 1.10 to test it, with 1.12 I do see the corruption described in the mozilla bug; if the image corruption didn't happen with 1.10, it would be a bit too much of coincidence IMHO
(In reply to comment #8) > @comment 7: > while I haven't downgraded to 1.10 to test it, with 1.12 I do see the > corruption described in the mozilla bug; if the image corruption didn't > happen with 1.10, it would be a bit too much of coincidence IMHO like I wrote the corruption starts with cairo 1.11.4 with 1.11.2 it isn't there for me, neither with firefox nor with any other app (chromium, gnome-terminal, seamonkey, etc.)
OK, after a little testing, some comments in regard of https://bugs.freedesktop.org/show_bug.cgi?id=38904: while the ebuild disables xlib-xcb backend, the hack described in the bug doesn't work; after enabling the backend and applying the hack things break completely across the board, not just in some parts of firefox GUI. However, if the hack is *not* applied, enabling the backend makes the bug a *bit* less pronounced. Also, it seems that it's not just mozilla based apps that are affected, even though it's most noticeable there, as I've noticed minor background color corruption (blue turning black) in mc running in a vte-based terminal. Again, it *seems* that xlib-xcb makes it *less* pronounced.
Indeed, for the moment it seems, that at least in regard of xf86-video-ati, as the recently added freedesktop bug suggests, 'Option "EXAPixmaps" "false"' workarounds the corruption (I'll give myself about an hour more to be sure).
...also it seems that the mozilla bug was indeed unrelated.
(In reply to comment #11) > Indeed, for the moment it seems, that at least in regard of xf86-video-ati, > as the recently added freedesktop bug suggests, 'Option "EXAPixmaps" > "false"' workarounds the corruption (I'll give myself about an hour more to > be sure). I can confirm that this workaround does the trick, not only with xf86-video-ati, but also with xf86-video-nouveau.
Both xf86-video-ati and xf86-video-nouveau fixed this problem in git already. For xf86-video-ati I added the patches to 6.14.4-r1. nouveau can't be easily patched, and a new snapshot is contingent on next libdrm release.
(In reply to comment #14) > Both xf86-video-ati and xf86-video-nouveau fixed this problem in git > already. For xf86-video-ati I added the patches to 6.14.4-r1. nouveau can't > be easily patched, and a new snapshot is contingent on next libdrm release. Did you add xorg-server fix too ? I don't see it in the tree.
(In reply to comment #15) Which fix? Do you have an upstream commit id?
I don't see the commit in the git, at least not on 1.12 branch. I'm talking about https://bugs.freedesktop.org/show_bug.cgi?id=47266#c66. On the other hand, https://bugs.freedesktop.org/show_bug.cgi?id=47266#c92 seems to suggest, that this patch may not be needed after all (I've kind of missed it, then again, it seems inconclusive)... Also, cairo 1.12.2 has been released, with a few fixes in regard of a different case of corruption (one present in LibreOffice).
Out of curiosity I just unmasked and emerged cairo-1.12.2 an hour ago and there's no corruption yet. used packages: firefox-12.0 xf86-video-intel-9999 mesa-9999
(In reply to comment #18) > Out of curiosity I just unmasked and emerged cairo-1.12.2 an hour ago and > there's no corruption yet. > > used packages: > firefox-12.0 > xf86-video-intel-9999 > mesa-9999 Well, there's a catch or two about this. Due to their internal policies, mozilla upstream decided to change API of their copy of cairo, therefore firefox 12.0 doesn't use system cairo. However... If you were to *revert* the change made in the libxul sources, that required the changed API, (as described here: https://bugzilla.mozilla.org/show_bug.cgi?id=722975#c22) *and* reverted the change in the ebuild, firefox 12.0 should work with cairo 1.12.2 just fine.
I'm going to try it out, actually I'm rebuilding firefox right now with system-cairo. Oh btw if someone cares, there's a spelling error in the ebuild ;) ` mozconfig_annotate 'Missing fetures' --disable-system-cairo`
(In reply to comment #20) > I'm going to try it out, actually I'm rebuilding firefox right now with > system-cairo. > > > Oh btw if someone cares, there's a spelling error in the ebuild ;) > > ` mozconfig_annotate 'Missing fetures' --disable-system-cairo` You will get no where with enable-system-cairo for fx-12. there are features that are not avaiable in system cairo that are used in firefox.
(In reply to comment #21) AFAICT, the only loss atm. is the fix that "required" that API change. Not that it's completely insignificant, but...
For whatever it's worth, I can't see no corruption so far after enabling system-cairo. Is there any specific test case that should not work?
The corruption issue does not affect current ~arch xf86-video-ati or xf86-video-intel. xf86-video-nouveau is fixed in git, but due to libdrm changes a newer snapshot cannot be added to the portage tree at this time.
re-add us if needed.
(In reply to comment #22) > (In reply to comment #21) > AFAICT, the only loss atm. is the fix that "required" that API change. > Not that it's completely insignificant, but... Mozilla based products are patched in gentoo to support system-cairo, if you are seeing corruption you need to update to latest ~arch video driver. Please do not get in a pushing match with upstream mozilla dev, they are correct when they say the patch works as expected as I am unable to duplicate any font corruption using cairo-1.12.2 with latest intel driver.
Yes, I've noticed the patch is one of the later firefox 12 tarballs and right from the start in 13. Actually, I've been arguing with the upstream about it yesterday (in 722975) (and yes, I probably shouldn't have turned '--with-xlib-xcb' on - I simply misread the comment in configure.ac).
What's the current status? Can we unmask cairo-1.12.2?
(In reply to comment #28) > What's the current status? Can we unmask cairo-1.12.2? Well, recent firefox uses system cairo and if the fixed xf86-video-ati are used it works just fine. xf86-video-intel doesn't use EXA, so chances are it wasn't affected, as for nouveau - no idea.
Before unmasking cairo-1.12.0, >=xf86-video-nouveau-0.0.16_pre20120508 needs to be unmasked. Older versions are affected by font corruption and backporting the patches appears unfeasible. But mesa-8.0.3[video_cards_nouveau] depends on <libdrm-2.4.34 while xf86-video-nouveau-0.0.16_pre20120508 depends on >=libdrm-2.4.34 (due to API break) Possible solutions: 1) Wait until mesa-8.1 release later this year 2) Package a git snapshot of mesa that works with >=libdrm-2.4.34 3) Package libdrm_nouveau-2.4.33 separately for mesa, and allow installing alongside newer libdrm Currently we are doing 1) because nobody has expressed interest in 2) or 3). But I have no strong opinions either way. I have written a proof of concept ebuild of libdrm_nouveau that I could provide to anyone who is interested in pursuing 3).
(In reply to comment #30) > 3) Package libdrm_nouveau-2.4.33 separately for mesa, and allow installing > alongside newer libdrm I don't understand this. Don't you mean: "package libdrm_nouveau-2.4.34 separately for mesa, and allow installing alongside *older* libdrm"? > Currently we are doing 1) because nobody has expressed interest in 2) or 3). > But I have no strong opinions either way. I have written a proof of concept > ebuild of libdrm_nouveau that I could provide to anyone who is interested in > pursuing 3). I think we should consider this option. Unless mesa-8.1 release is coming up soon...
(In reply to comment #31) > (In reply to comment #30) > > 3) Package libdrm_nouveau-2.4.33 separately for mesa, and allow installing > > alongside newer libdrm > > I don't understand this. Don't you mean: "package libdrm_nouveau-2.4.34 > separately for mesa, and allow installing alongside *older* libdrm"? I mean a legacy libdrm_nouveau-2.4.33.ebuild which mesa-8.0 will build against, and unmask >=libdrm-2.4.34 which >=xf86-video-nouveau-0.0.16_pre20120508 will build against. > I think we should consider this option. Unless mesa-8.1 release is coming up > soon... From what I have heard, releasing mesa-8.1 in August/September timeframe (rc1 a is the current plan.
We have mesa-8.0.4 now, and newer Firefox seems not to be affected. As far as I understand only nouveau users still have problems in some applications. Is there any progress on this? If not, then I would like to implement the proposed solution. I want to unmask cairo-1.12 this week.
The nouveau situation is unchanged: The font corruption bug is solved in >=xf86-video-nouveau-0.0.16_pre20120508 which requires new libdrm. Support for new libdrm is not in mesa-8.0 branch, only in git master.
I just removed the mask. This should be fixed with latest cairo-1.12.2, mesa-8.1 snapshot and related drivers.
(In reply to comment #35) > I just removed the mask. This should be fixed with latest cairo-1.12.2, > mesa-8.1 snapshot and related drivers. I am seeing corruption in firefox (and only in firefox) which started after the upgrade to cairo, mesa, libdrm and xf86-video-nouveau I have versions emerge -pv mesa cairo libdrm xf86-video-nouveau These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/libdrm-2.4.37 USE="libkms -static-libs" VIDEO_CARDS="nouveau (-exynos) -intel (-omap) -radeon -vmware" 0 kB [ebuild R ] media-libs/mesa-8.1_rc1_pre20120724 USE="classic egl gallium llvm nptl pax_kernel shared-glapi xorg -bindist -d3d -debug -g3dvl -gbm -gles1 -gles2 -openvg (-osmesa) -pic -r600-llvm-compiler (-selinux) -vdpau -wayland -xa -xvmc" VIDEO_CARDS="nouveau -i915 -i965 -intel -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware" 0 kB [ebuild R ] x11-drivers/xf86-video-nouveau-1.0.1 0 kB [ebuild R ] x11-libs/cairo-1.12.2-r2 USE="X doc glib opengl qt4 svg xcb (-aqua) -debug -directfb (-drm) (-gallium) -openvg -static-libs" 0 kB Total: 4 packages (4 reinstalls), Size of downloads: 0 kB
(In reply to comment #36) > I am seeing corruption in firefox (and only in firefox) which started after > the upgrade to cairo, mesa, libdrm and xf86-video-nouveau This is possibly a different bug then. See if the workaround from https://bugs.freedesktop.org/show_bug.cgi?id=47266#c37 works, and if not open a separate bug.
