Bug 5128 - Issues with font drawing on non-RENDER X server
Summary: Issues with font drawing on non-RENDER X server
Status: RESOLVED INVALID
Alias: None
Product: cairo
Classification: Unclassified
Component: freetype font backend (show other bugs)
Version: 1.1.1
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Owen Taylor
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-23 01:52 UTC by Bogdan Nicula
Modified: 2008-09-30 03:29 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Bogdan Nicula 2005-11-23 01:52:53 UTC
Not sure if the component (i.e. ft font backend) is correct.

I'm seeing this with a GTK+ application on X server without RENDER (VNC), cairo
HEAD (something similar happens with 1.0.2):

==30218== Use of uninitialised value of size 4
==30218==    at 0x1B96DC22: fbBltOne (icbltone.c:400)
==30218==    by 0x1B96927A: fbCompositeSolidMask_nx1xn (fbpict.c:953)
==30218==    by 0x1B96A7E4: INT_pixman_composite (fbpict.c:1894)
==30218==    by 0x1B94803E: _cairo_image_surface_composite
(cairo-image-surface.c:599)
==30218==    by 0x1B94F1DE: _cairo_surface_composite (cairo-surface.c:870)
==30218==    by 0x1B94DF6A: _cairo_scaled_font_show_glyphs (cairo-scaled-font.c:890)
==30218==    by 0x1B9507A5: _cairo_surface_old_show_glyphs_draw_func
(cairo-surface.c:1877)
==30218==    by 0x1B945668: _cairo_gstate_clip_and_composite (cairo-gstate.c:1123)
==30218==    by 0x1B9508B1: _cairo_surface_show_glyphs (cairo-surface.c:1927)
==30218==    by 0x1B9469E6: _cairo_gstate_show_glyphs (cairo-gstate.c:1987)
==30218==    by 0x1B9419CB: cairo_show_glyphs (cairo.c:2158)
==30218==    by 0x4355419A: (within /usr/lib/libpangocairo-1.0.so.0.1001.0)
==30218==    by 0x4363AA67: pango_renderer_draw_glyphs (in
/usr/lib/libpango-1.0.so.0.1001.0)
==30218==    by 0x43554733: pango_cairo_show_glyph_string (in
/usr/lib/libpangocairo-1.0.so.0.1001.0)
Comment 1 Chris Wilson 2008-09-30 03:29:26 UTC
Thanks for the report. The complication here is that composite() is such a generic function (it's passed 3 buffer pointers) that identifing the culprit is impossible without at least a minimal test-case (the new valgrind --track-origins=yes tool is a promising, though oft-confusing guide.)

Marking as invalid due to its age and lack of necessary info to reproduce. Though please if you can identify problematic cases, I'll add them to the test suite.


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.