Bug 38904

Created attachment 48682 [details]
garbled font in firefox

That looks more like a driver bug...

The way xcb distinguishes itself from xlib in the case of glyph rendering is that it will try to bypass the mask when it can. Disabling that might help at least point where the bug lies:

diff --git a/src/cairo-xcb-surface-render.c b/src/cairo-xcb-surface-render.c
index d1f2288..36ae401 100644
--- a/src/cairo-xcb-surface-render.c
+++ b/src/cairo-xcb-surface-render.c
@@ -4464,6 +4464,7 @@ _cairo_xcb_surface_render_glyphs (cairo_xcb_surface_t	*surface,
 		info.glyphs = (cairo_xcb_glyph_t *) glyphs;
 		info.num_glyphs = num_glyphs;
 		info.use_mask = overlap || clip != NULL || ! extents.is_bounded;
+		info.use_mask = 0;
 
 		status = _clip_and_composite (surface, op, source,
 					      _composite_glyphs, &info,

Meh, that should have been use_mask=1.

Created attachment 48683 [details]
screenshot

Still the same with info.use_mask = 1;

Ok, let's try something more intrusive:

cairo-xcb-surface-render.c, line 4421, at the beginning of the function _cairo_xcb_surface_render_glyphs add the following:
return CAIRO_INT_STATUS_UNSUPPORTED;

That will make cairo do all font rendering via fallback to the image surface. Let's hope firefox calls cairo_surface_flush often enough...

If this doesn't help, the problem is somewhere in xlib-xcb (some font-magic? dunno).

Also, I couldn't reproduce this yet. How long does it usually take for you to hit this? Is it always in the same text on the page (e.g. always a bold/italic text)? What happens when you force redraws, e.g. via scrolling or selecting text?

Where in thunderbird where you seeing this?

diff --git a/src/cairo-xcb-surface-render.c b/src/cairo-xcb-surface-render.c
index ad7454f..6adc4ff 100644
--- a/src/cairo-xcb-surface-render.c
+++ b/src/cairo-xcb-surface-render.c
@@ -4418,6 +4418,7 @@ _cairo_xcb_surface_render_glyphs (cairo_xcb_surface_t     *surface,
     cairo_status_t status;
     cairo_bool_t overlap;
 
+    return CAIRO_INT_STATUS_UNSUPPORTED;
     if (unlikely (! _operator_is_supported (surface->flags, op)))
        return CAIRO_INT_STATUS_UNSUPPORTED;

With "return CAIRO_INT_STATUS_UNSUPPORTED; " line all text renders fine. 
The bug is rather reproducible for me on http://www.bbc.co.uk/news/world/latin_america/ page. Go to the page and reload several times, in half cases some text will be garbled. Also you can try to resize browser window — some text flickers between garbled and correct rendering.
It happens with different text, force redraws with selection/mouseover no links/etc makes rendering fine, but scrolling leads to different results (correct rendering or different text garbled), just like page reload.

In thunderbird (just like firefox) it can happen anywhere: interface/message list/message text/etc.

I suspect that gecko generates this more than other cairo apps because
it stores so much data on the X server.  As vram fills an the server is
forced to migrate between cpu ram and vram the incidence increases.

Try opening a dozen tabs with, each with a reasonably large html.

Reflow seems to be a trigger; scrolling around while a page slowly loads
(I often have to use heavily congested pipes) is a common trigger.

Still happens with latest git.

I still don't have any good test (happens sporadically in thunderbird, happens slightly more often if all glyphs go through render_glyphs_via_mask instead of _composite_glyphs), but I couldn't reproduce this since the following commit:

commit 2a60e8deecd8f63671cd595012843a665187d695
Author: Uli Schlachter <psychon@znc.in>
Date:   Thu Dec 8 22:41:10 2011 +0100

    xcb: Fix invalid casts from cairo_content_t to cairo_format_t
    
    This was introduced in a69335a84e when the second argument of
    _cairo_xcb_surface_create_similar_image was changed from content to format.
    
    Signed-off-by: Uli Schlachter <psychon@znc.in>


Could you retest? (And no, I don't really know how that commit fixes this bug, something down the call graph must be mis-handling some format...?)

Created attachment 54320 [details]
screenshot with cairo-git be288ce

Corruption still here.
Also I have corruption even without xlib-xcb (as mentioned in http://lists.cairographics.org/archives/cairo/2011-September/022297.html ), after introduction of new compositor architecture (af9fbd1) if I remember correctly (I'll try to bisect if needed)
Can it be some underlying issue, which just wasn't seen before without xlib-xcb?
Or new bug should be filled for --without-xlib-xcb case?

The best way I’ve found to trigger the corruption is to browse pages
which are heavy on ecma-script.

Google’s mail, voice, etc apps are particularly effective at triggering
the bug.

Seamonkey and firefox are equally affected, IME.

Smaller bitmaps are affected more frequently than larger ones, so text
runs with tinier (in pixels) fonts are more vulnerable.

Since this also happens with xlib-xcb, the bug must be elsewhere. After having stared at the code for a while, I think that the image backend doesn't freeze the font cache and so we sometimes get a use-after-free from the resulting race. Also, the bug triggers more often with xlib-xcb if all font drawing goes through the fallback path (drawing a mask via the image backend).

Reassinging to the image backend.

Oh and: Can't reproduce in google mail (This was the first time I used the web interface instead of the POP server).

Still happens on latest git (0f40cde api: add cairo_surface_supports_mime_type).

Still happens with latest git (f905f71 Fix docs for cairo_xlib_device_debug_cap_xrender_version).

Still reproducible with HEAD is now at 841b405 version: Post release bump to 1.12.1

I apologise for letting this bug linger, but it does look characteristic of a driver bug not cairo.

It happens for me with xf86-video-ati, xf86-video-intel and also via ssh -X/in Xnest (don't know how particularly it works/what driver is used, though). Doesn't look like driver bug for me.
Can it be xserver/libX11 bug?

Because I saw it only in firefox/thunderbird (almost don't use any other gtk programs), can it be firefox-side bug? Can it be related to https://bugzilla.mozilla.org/show_bug.cgi?id=715658#c12 ?

As a side not: patch from comment 5 seems to fix the issue also on current git.

Sorry for many questions, but I really don't know what to do with this bug right now.

Cannot reproduce on intel anymore, maybe my previous tests was incorrect. Also trying to poke radeon devs ._.

Please also take a look at https://bugs.freedesktop.org/show_bug.cgi?id=47266#c33
The same issue with nouveau? Maybe mesa/gallium bug?

I can reproduce the issue on  xf86-video-ati-6.13.0 and 
OpenGL renderer string: Gallium 0.4 on AMD RS780
OpenGL version string: 2.1 Mesa 8.1-devel (git-8fc5662)
OpenGL shading language version string: 1.20

Please note that I cannot reproduce the issue on fedora-16 with xf86-video-intel 2.17.0 and 
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) G33 
OpenGL version string: 1.4 Mesa 7.11.2

with firefox running on local machine and with firefox running on mentioned above machine with xf86-video-ati via ssh -X.

Erm.. read xf86-video-ati-6.14.3, not xf86-video-ati-6.13.0 in the comment above.

Also please mention that I can reproduce the issue on machine with xf86-video-ati and firefox running on remote machine via ssh -X.

*** This bug has been marked as a duplicate of bug 47266 ***