Bug 38904 - Garbled font with xf86-video-ati
Summary: Garbled font with xf86-video-ati
Status: RESOLVED DUPLICATE of bug 47266
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-02 02:07 UTC by ojab
Modified: 2012-03-28 23:29 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
garbled font in firefox (291.40 KB, image/png)
2011-07-02 02:10 UTC, ojab
no flags Details
screenshot (479.33 KB, image/png)
2011-07-02 03:07 UTC, ojab
no flags Details
screenshot with cairo-git be288ce (134.41 KB, image/png)
2011-12-11 05:12 UTC, ojab
no flags Details

Description ojab 2011-07-02 02:07:38 UTC
Sometimes I see garbled font in firefox/thunderbird with cairo-git built with --enable-xlib-xcb (please check the attached file). 
Also happens via `ssh -X`/in Xnest.

Don't have any way to reproduce this bug, just happens occasionally during browsing.
Haven't seen such behavior in apps other that firefox/thunderbird, but I don't intensively use any cairo-based apps except these two.
Comment 1 ojab 2011-07-02 02:10:16 UTC
Created attachment 48682 [details]
garbled font in firefox
Comment 2 Chris Wilson 2011-07-02 02:19:32 UTC
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,
Comment 3 Chris Wilson 2011-07-02 02:19:55 UTC
Meh, that should have been use_mask=1.
Comment 4 ojab 2011-07-02 03:07:02 UTC
Created attachment 48683 [details]
screenshot

Still the same with info.use_mask = 1;
Comment 5 Uli Schlachter 2011-07-02 12:48:05 UTC
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;
Comment 6 ojab 2011-07-02 13:22:24 UTC
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.
Comment 7 James Cloos 2011-07-03 03:35:05 UTC
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.
Comment 8 ojab 2011-07-29 10:21:54 UTC
Still happens with latest git.
Comment 9 Uli Schlachter 2011-12-11 02:32:25 UTC
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...?)
Comment 10 ojab 2011-12-11 05:12:56 UTC
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?
Comment 11 James Cloos 2011-12-11 07:37:36 UTC
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.
Comment 12 Uli Schlachter 2011-12-11 11:34:38 UTC
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).
Comment 13 ojab 2012-01-24 10:18:21 UTC
Still happens on latest git (0f40cde api: add cairo_surface_supports_mime_type).
Comment 14 ojab 2012-03-03 06:26:11 UTC
Still happens with latest git (f905f71 Fix docs for cairo_xlib_device_debug_cap_xrender_version).
Comment 15 ojab 2012-03-24 03:24:14 UTC
Still reproducible with HEAD is now at 841b405 version: Post release bump to 1.12.1
Comment 16 Chris Wilson 2012-03-24 03:33:04 UTC
I apologise for letting this bug linger, but it does look characteristic of a driver bug not cairo.
Comment 17 ojab 2012-03-24 04:49:07 UTC
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.
Comment 18 ojab 2012-03-28 22:46:08 UTC
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.
Comment 19 ojab 2012-03-28 22:48:26 UTC
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.
Comment 20 Michel Dänzer 2012-03-28 23:29:53 UTC

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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.