Ever since sometime Q4/2012, I've been fighting with font corruption in firefox and thunderbird (see attached pictures). Unfortunately I had no time until this weekend to further localize what's causing this.
Surfing the net with firefox, it happens quite often that one to several words or even several lines are corrupted. They look like a copy of the same area has been pasted over it but with a few pixel offset. Forcing a redraw will fix it. You can either click on the desktop and back into the window (focus), highlight/mark the affected area, close/open the window, ... etc.
In thunderbird, writing a mail and scrolling up or down, you usually end up with corrupted words. Fixing the corruption is the same as with firefox above, except for clicking on the desktop and back into the window (focus).
(1) This is absolutely limited to the non-bin packages. Taking the compiled releases from mozilla.org (through the appropriate ebuilds naturally), the bugs are not reproducible. Most likely since they do not use the system cairo.
(2) Disabling the jemalloc patchset directly in the ebuild, has no affect.
(3) This is _not_ caused by the nvidia blob. I tried with the nvidia driver 313.08 as well as nouveau 1.0.6, both show the same symptoms.
(4) Downgrading from pixman-0.28.2 to 0.26.2 (and thus recompiling cairo, firefox and thunderbird due to the API changes), does not fix it as well.
(5) Using either cairo 1.12.10, 1.10.2-r3 or current master (as of today) makes no difference at all.
(6) Disabling pango (via MOZ_DISABLE_PANGO=1) has not effect on this.
(7) Using a clean firefox profile has no affect.
(8) I use oxygen-gtk/3 which I uninstalled for test purposes: no affect.
(9) I use KDE 4.10-rc3, testing in XFCE with a clean slate, has no affect.
(10) freetype: disabling the freetype infinality patchset, uninstalling croscorefonts, w/ or w/o auto-hinter... no affect.
Portage 2.2.0_alpha161 (default/linux/amd64/10.0/desktop, gcc-4.7.2, glibc-2.16.0, 3.7.4 x86_64)
System uname: Linux-3.7.4-x86_64-Intel-R-_Core-TM-_i7_CPU_860_@_2.80GHz-with-gentoo-2.2
KiB Mem: 8162792 total, 382316 free
KiB Swap: 4000060 total, 4000060 free
Timestamp of tree: Sun, 27 Jan 2013 05:15:01 +0000
ld GNU ld (GNU Binutils) 2.23.1
dev-lang/python: 2.7.3-r3, 3.2.3-r2
sys-devel/autoconf: 2.13, 2.69
sys-devel/automake: 1.9.6-r3, 1.11.6, 1.12.6, 1.13.1
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
Repositories: gentoo local-crossdev java-overlay fordfrog DuPol aluco qt toolchain vmware science x11 graaff multimedia mozilla sabayon prometheanfire kde local_ebuilds
ACCEPT_KEYWORDS="amd64 ~amd64 ~amd64-linux"
ACCEPT_LICENSE="* -@EULA PUEL dlj-1.1 sun-bcla-java-vm skype-eula googleearth AdobeFlash-10 AdobeFlash-10.1 Oracle-BCLA-JavaSE Intel-SDP AdobeFlash-10.3 skype-188.8.131.52-copyright"
CFLAGS="-march=native -O2 -pipe"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/polkit-1/actions /usr/share/themes/oxygen-gtk/gtk-2.0 /usr/share/themes/oxygen-gtk/gtk-3.0 /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /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="-march=native -O2 -pipe"
FEATURES="assume-digests binpkg-logs candy config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox"
GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://de-mirror.org/distro/gentoo/"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,-z,combreloc -Wl,-z,now"
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"
PORTDIR_OVERLAY="/usr/local/portage-overlays/local.crossdev /var/lib/layman/java-overlay /var/lib/layman/fordfrog /var/lib/layman/DuPol /var/lib/layman/aluco /var/lib/layman/qt /var/lib/layman/toolchain /var/lib/layman/vmware /var/lib/layman/science /var/lib/layman/x11 /var/lib/layman/graaff /var/lib/layman/multimedia /var/lib/layman/mozilla /var/lib/layman/sabayon /var/lib/layman/prometheanfire /var/lib/layman/kde /usr/local/portage-overlays/local"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 336980 [details]
firefox @ h-online.com: corrupted
Created attachment 336982 [details]
firefox @ h-online.com: normal
Created attachment 336984 [details]
firefox @ slashdot.org: corrupted
Created attachment 336986 [details]
firefox @ slashdot.org: normal
Created attachment 336988 [details]
Created attachment 336990 [details]
Two major pieces of information I forgot to add:
(a) This only happens in firefox and thunderbird. I almost exclusively use Qt-based applications, so this might be a factor. For what's it worth: I have never seen anything like that in Chromium, dolphin or konqueror.
(b) Using Xlib/XCB exclusively in cairo (enable-xlib-xcb) makes this bug either unbelievably hard to trigger or fixes/shadows it very effectively because I have yet to see a single case of this corruption since switching over to using xcb exclusively (w/ cairo master and a patched ebuild to enable this naturally).
I've been seeing this problem for awhile too.
As my card is a very old radeon using xf86-video-ati, it doesn't seem hardware based.
I've yet got to try cairo 1.12.10-r1 (on 1.12.8), pixman is 0.28.0, kernel is 3.6.8, arch x86 - very little in common.
With firefox 18.0 it became a bit less pronounced (though perhaps it was due to a different upgrade), but it's still there.
Using XCB instead of Xlib functions in cairo does indeed solve the font corruption (which was very easy to trigger before) but unfortunately it causes infrequent corruption of page backgrounds with random contents of some graphics buffer.
AFAICR (and please correct me if I am wrong), Mozilla has patched cairo quite heavily for their own purposes and did not upstream all of those changes. My best guess is, what Mozilla is using as cairo internally, is not 100% compatible anymore with vanilla cairo. This https://bugzilla.mozilla.org/show_bug.cgi?id=722975 upstream bug is quite an interesting starting point (and we do have that patch in the tree as well).
tl;dr: I will disable system cairo here and see if this is actually the cause and report back. If it is, can we at least make this a use flag which by default is off? The releases from Mozilla which use their internal cairo look just fine (wrt font rendering), so I do not see any harm.
Paul Bredbury mentions the same issue in the forums (http://forums.gentoo.org/viewtopic-p-7176654.html#7176654)
I am hit by this as well. There are two ways I could recreate it.
Go to this site http://www.chakra-project.org/ and watch the links where the moving image would scroll, if unconstrained, over the links. (whatever update I did recently seems to have fixed this bug, beit ff 18.0.1 or who knows)
This one still works however. Mouseover the "free software" link in the top paragraph, then mouseoff, do it quickly. The text "showcase project created by a bunch of" on the right will get bolder and bolder. Select the text to reset, then repeat.
Ok, since I work on a web project for a client, I use firefox all day long and wanted to be sure before updating the bug: Disabling system cairo for Firefox indeed fixes all problems (as expected).
I'll update to today's cairo master, since there have been some interesting fixes, enable system cairo again and try with cairo's xlib-xcb one more time. I'll report back once I've more info.
But one thing is sure by know: Enabling system cairo for Firefox with the current cairo versions in the tree, causes graphical glitches.
Ok, even with today's cairo master (which has seen a fair amount of fixes), there is still the same background corruption when used with xlib-xcb (fonts still look fine though). Since activating this (xlib-xcb) through normal means is not even possible, this is not really important but would have been a nice workaround to have.
So I am at the end of my rope here. If there is anything else I should try, please let me know. I will _not_ dig into the Mozilla codebase though. :)
If no one has a keen idea what is causing this and how the bug can be fixed, I would suggest either adding a system-cairo use flag to the appropriate eclass and have it default to off or completely switch to bundled cairo for the time being.
(In reply to comment #13)
> Ok, even with today's cairo master (which has seen a fair amount of fixes),
> there is still the same background corruption when used with xlib-xcb (fonts
> still look fine though). Since activating this (xlib-xcb) through normal
> means is not even possible, this is not really important but would have been
> a nice workaround to have.
- did you try without xlib-xcb ?
- most likely it's not as much a new bug, as an old one, that had been masked before (well, it was that way with the problem fixed by patch in -r1)
As for the background corruption in firefox *with* xlib-xcb, it's an old problem - IIRC dating back to at least cairo 1.12.0.
(In reply to comment #14)
> Two things:
> - did you try without xlib-xcb ?
Always. :) In my last post I forgot to mention that I naturally also tried the cairo master checkout w/o xlib-xcb which immediately brought back the font corruption (which is really easy to trigger).
> As for the background corruption in firefox *with* xlib-xcb, it's an old
> problem - IIRC dating back to at least cairo 1.12.0.
*sigh* Pity it hasn't been fixed yet upstream because otherwise that would have been a nice workaround for the font corruption.
In all honesty, I think it would really be for the best to offer the user a choice with regard to the system cairo usage and default it to off since there are definitely problems associated with it. This also implies only conditionally applying cairo compatibility fixes to mozilla products.
The best solution would be naturally to find out what is causing both problems, fix them and be done with it. But since I don't have enough free time on my hands to dive into the mozilla and cairo codebase and do some proper debugging, I cannot help with that. :(
I find I don't get the font corruption with cairo 1.12.2-r4, but this has been removed from portage. Any versions higher it appears consistently.
It would seem that it's a bit better with cairo 1.12.14 - there's still a slight random corruption, but now it looks less fuzzy, a bit like artificial bold...
Well, at least it seems that way to me.
Given the low number of commits between .12 and .14, it could suggest that there's still a place or two where float rounding needs to be fixed.
I've been experiencing this issue as well. My testing isn't nearly as complete as far as finding fixes. All I've done is test various fonts (to no avail) and mess with fontconfig settings (ditto).
For those of us with less knowledge on font rendering, should we switch to the binary version until the bug's fixed? I don't mind being a test subject since Firefox only takes ~15 min for me to compile.
@comment 18: the problem here is that it's very hard to tell what the real problem here is.
As mozilla upstream will most likely be quite unhelpful (with all their internal copies), perhaps somebody should check freedesktop bugzilla for cairo bugs and if nothing similar is found, perhaps ask a question on its mailing list about what tools to use to diagnose the exact source of the problem ?
For the time being it is enough to add
mozconfig_annotate '' --disable-system-cairo
into ebuild's src_configure to compile firefox with internal cairo support and workaround the bug.
It would be nice, if ebuild provide flag "system-cairo" until the bug is really fixed.
(In reply to comment #20)
> For the time being it is enough to add
> mozconfig_annotate '' --disable-system-cairo
> into ebuild's src_configure to compile firefox with internal cairo support
> and workaround the bug.
> It would be nice, if ebuild provide flag "system-cairo" until the bug is
> really fixed.
Confirmed to work for me. No font corruption on any of the pages that were doing it prior.
Finally the solution to that nasty problem!
USE="-system-cairo" really helps.
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system.
Thank You for your support and understanding
The Mozilla Team