Bug 26124 - incorrect clipping offsets for glyphs
Summary: incorrect clipping offsets for glyphs
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: All Mac OS X (All)
: high normal
Assignee: Jeremy Huddleston Sequoia
QA Contact: Xorg Project Team
Whiteboard: 2015BRB_Reviewed
Depends on:
Reported: 2010-01-19 16:53 UTC by Jeremy Huddleston Sequoia
Modified: 2018-12-13 22:22 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Description Jeremy Huddleston Sequoia 2010-01-19 16:53:06 UTC
As discussed on xorg-devel in early January, this commit is causing some clipping problems in some applications using the XQuartz DDX.


I'm not too familiar with this code, so I think I've reached the end of my limits in debugging this.  I did notice an odd pattern in fbComposite.  After the calls to image_from_pict in fbComposite, the offsets returned were sometimes uninitialized.  Specifically the mask's offsets were not set:

Before 1 26521600 1 19396120 1 767442
After 0 0 1 19396120 0 0

this is from:

+fprintf(stderr, "Before %d %d %d %d %d %d\n", src_xoff, src_yoff, msk_xoff, msk_yoff, dst_xoff, dst_yoff);    
 src = image_from_pict (pSrc, FALSE, &src_xoff, &src_yoff);
 mask = image_from_pict (pMask, FALSE, &msk_xoff, &msk_yoff);
 dest = image_from_pict (pDst, TRUE, &dst_xoff, &dst_yoff);
+fprintf(stderr, "After %d %d %d %d %d %d\n", src_xoff, src_yoff, msk_xoff, msk_yoff, dst_xoff, dst_yoff);    

Additionally, I'm a bit confused by the TRUE->FALSE changes for some of the has_clip values.

Also, create_bits_picture seems to not translate by pict->pDrawable->y before doing the pixman_image_set_clip_region like it did before the patch.
Comment 1 Jeremy Huddleston Sequoia 2010-01-19 16:56:14 UTC
A screencap of the problem can be downloaded here:


Comment 2 Søren Sandmann Pedersen 2010-01-21 06:47:15 UTC
Does the patch here:


fix the problem?
Comment 3 Jeremy Huddleston Sequoia 2010-01-21 12:26:15 UTC
No, that patch does not fix the problem. and later are also effected because it was pulled in as part of

Comment 4 Jeremy Huddleston Sequoia 2010-02-12 19:48:47 UTC
Well I guess I'll just have to just revert this patch for XQuartz... I'd rather find the correct fix.  Any ideas?
Comment 5 Jeremy Huddleston Sequoia 2010-04-16 18:52:44 UTC
I wonder if this and http://xquartz.macosforge.org/trac/ticket/290 share a similar root cause.
Comment 6 Jeremy Huddleston Sequoia 2010-04-18 04:19:51 UTC
I'm befuddled...

Comment 7 Jeremy Huddleston Sequoia 2011-04-27 18:52:02 UTC
This doesn't reproduce with xserver and pixman master.  Huzah for bugs that go away on their own (or more likely were the same root cause as another fixed issue)
Comment 8 Jeremy Huddleston Sequoia 2012-01-10 22:42:50 UTC
I meant to reopen this a while ago, but I forgot to.  The issue does still exist.  On a hunch, Jamey suggested that I disable the render extension to see if it still reproduces, and with render disabled (noRenderExtension = TRUE early in main()), the issue doesn't reproduce, so it seems that something in render's glyph handling needs to be updated.
Comment 9 Jeremy Huddleston Sequoia 2012-01-10 23:00:02 UTC
Adding to the 1.12 tracker.  I don't have high hopes since this may be only affecting XQuartz, but it would be nice to get addressed in 1.13.
Comment 10 Brian P. Hinz 2012-07-06 06:42:03 UTC
Hi Jeremy,

I think that we've been chasing this same bug with TigerVNC for some time as well:


Have you made any progress on this issue?

I noticed that http://xquartz.macosforge.org/trac/ticket/290 is titled "xorg-server > 1.4 misrender borders" - I have not tried doing a diff between 1.4 and 1.5 to see if there are any suspicious changes that might help narrow down the issue, have you?

Comment 11 Jeremy Huddleston Sequoia 2012-07-06 10:30:09 UTC
I really reached the end of what I understand about this code.  I've been shipping XQuartz with this particular change reverted (and rebasing it as appropriate).  Take a look at

Comment 12 Brian P. Hinz 2012-07-09 22:18:13 UTC
In my case, those changes that you've reverted actually produce better results, however based on your work I started looking at miexpose.c and noticed that there are prgn's being passed into miPaintWindow that have 0 rects defined.  This causes miPaintWindow to return prematurely at:

    prect = malloc(RegionNumRects(prgn) * sizeof(xRectangle));
    if (!prect)

I put in some debug lines to print the coordinates of the drawable, etc. and these empty regions seem to correspond to the window borders that should be drawn but so far I have not been able to fall back to any coordinates or region sizes that produce the expected results.
Comment 13 Brian P. Hinz 2012-07-19 23:02:07 UTC
I don't know if it will shed any light on the issue affecting Xquartz, but we seem to have resolved the problem for TigerVNC.  Take a look at this thread:


Comment 14 Jeremy Huddleston Sequoia 2014-05-31 19:43:03 UTC
I wonder if this is helped by:

commit 983e30361f49a67252d0b5d82630e70724d69dbf
Author: Peter Harris <pharris@opentext.com>
Date:   Fri Apr 11 17:44:59 2014 -0400

    fb: Fix origin of source picture in fbGlyphs
    If a source picture doesn't repeat and a mask format is specified, the
    incorrect calulation of the origin of the glyphs caused the glyphs to
    not be drawn at all.
    Noticed when running gtk-demo from RHEL 6.5 and selecting "Rotated
    Signed-off-by: Peter Harris <pharris@opentext.com>
    Reviewed-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
Comment 15 Jeremy Huddleston Sequoia 2015-10-21 20:51:32 UTC
Nope.  This issue still exists in master.

Note that git-gui has changed a bit over the years.  The version in git shows off this issue.
Comment 16 GitLab Migration User 2018-12-13 22:22:32 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/389.

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.