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.
A screencap of the problem can be downloaded here:
Does the patch here:
fix the problem?
No, that patch does not fix the problem.
22.214.171.1242 and later are also effected because it was pulled in as part of
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.
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.
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?
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
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));
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:
I wonder if this is helped by:
Author: Peter Harris <firstname.lastname@example.org>
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 <email@example.com>
Reviewed-by: Keith Packard <firstname.lastname@example.org>
Signed-off-by: Keith Packard <email@example.com>
Nope. This issue still exists in master.
Note that git-gui has changed a bit over the years. The version in git 126.96.36.199 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.