| Summary: | www-client/firefox, mail-client/thunderbird, www-client/seamonkey: font corruption | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matthias Dahl <ua_gentoo_bugzilla> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | bas, dark.shadow, josef64, poncho, redneb, serge, yaron.tausky, zlg |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
firefox @ h-online.com: corrupted
firefox @ h-online.com: normal firefox @ slashdot.org: corrupted firefox @ slashdot.org: normal thunderbird: corrupted thunderbird: normal |
||
|
Description
Matthias Dahl
2013-01-27 09:58:19 UTC
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]
thunderbird: corrupted
Created attachment 336990 [details]
thunderbird: normal
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. > Two things: - 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 |
