As discussed on xorg-devel in early January, this commit is causing some clipping problems in some applications using the XQuartz DDX. http://cgit.freedesktop.org/xorg/xserver/commit/?id=a72c65e9176c51de95db2fdbf4c5d946a4911695 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.
A screencap of the problem can be downloaded here: http://people.freedesktop.org/~jeremyhu/fdo-26124.mov
Does the patch here: http://lists.freedesktop.org/archives/xorg-devel/2010-January/005065.html fix the problem?
No, that patch does not fix the problem. 1.7.3.902 and later are also effected because it was pulled in as part of http://cgit.freedesktop.org/xorg/xserver/commit/?id=2d6a8f668342a5190cdf43b5d385f592d10f5900
Well I guess I'll just have to just revert this patch for XQuartz... I'd rather find the correct fix. Any ideas?
I wonder if this and http://xquartz.macosforge.org/trac/ticket/290 share a similar root cause.
I'm befuddled... http://lists.x.org/archives/xorg-devel/2010-April/007518.html
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)
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.
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.
Hi Jeremy, I think that we've been chasing this same bug with TigerVNC for some time as well: https://bugzilla.redhat.com/show_bug.cgi?id=734424 http://sourceforge.net/tracker/index.php?func=detail&aid=3415308&group_id=254363&atid=1126848 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? Thanks, -brian
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 http://cgit.freedesktop.org/~jeremyhu/xserver/log/?h=server-1.13-apple
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) return; ... 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.
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: https://sourceforge.net/mailarchive/message.php?msg_id=29475167 HTH, -brian
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 Text". Signed-off-by: Peter Harris <pharris@opentext.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
Nope. This issue still exists in master. Note that git-gui has changed a bit over the years. The version in git 1.6.6.3 shows off this issue.
-- 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.