Created attachment 88565 [details] screenshot Scrolling vertically in LibreOffice results in corruption at the bottom of the row-number inidcator (looks like text clipping issue) on my SNB laptop (intel git 4a7217b05c232484a80abc7bd67494996dd32057)
Running localc from f20 on a SNB with and without a compositing manager, it doesn't want to reproduce. Any clues? Mind attaching your Xorg.0.log to rule out an incorrect version?
Not seeing the issue or the problem in the code yet. Can you try tweaking the various defines at the top of src/sna/sna_glyphs.c: #define FALLBACK 0 #define NO_GLYPH_CACHE 0 #define NO_GLYPHS_TO_DST 0 #define NO_GLYPHS_VIA_MASK 0 #define NO_SMALL_MASK 0 #define NO_GLYPHS_SLOW 0 #define NO_DISCARD_MASK 0 to see which path is affected, and perhaps try diff --git a/src/sna/sna_glyphs.c b/src/sna/sna_glyphs.c index 5830d9b..53a87fc 100644 --- a/src/sna/sna_glyphs.c +++ b/src/sna/sna_glyphs.c @@ -522,6 +522,8 @@ static inline bool clipped_glyphs(PicturePtr dst, int nlist, GlyphListPtr list, PixmapPtr pixmap; BoxRec box; + return true; + if (dst->pCompositeClip->data) { DBG(("%s: yes, has complex region\n", __FUNCTION__)); return true;
Created attachment 88628 [details] Screenshot of text corruption I get similar corruption using Moneydance (java-based finance software) when entering new transactions. In the screenshot below, I had first typed "Winn Dixie" and backspaced over it, and then typed "Giganews" I get the same behavior both with and without xfce's compositor enabled, although I have not checked to see whether disabling the X Composite extension affects it. I can attach the complete Xorg log if needed, but here are the parts I think you are interested in: X.Org X Server 1.14.3 Release Date: 2013-09-12 [ 95.580] X Protocol Version 11, Revision 0 [ 95.580] Build Operating System: Slackware 14.1 Slackware Linux Project [ 95.580] Current Operating System: Linux liberty 3.10.17 #1 SMP Wed Oct 23 16:28:33 CDT 2013 x86_64 [ 95.580] Kernel command line: auto BOOT_IMAGE=3.10.17 ro root=fd02 vt.default_utf8=1 reboot=pci printk.time=0 resume=/dev/cryptvg/swap [ 95.580] Build Date: 09 October 2013 08:27:11PM [ 95.580] [ 95.580] Current version of pixman: 0.30.2 ... [ 96.101] (II) LoadModule: "intel" [ 96.101] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 96.176] (II) Module intel: vendor="X.Org Foundation" [ 96.176] compiled for 1.14.3, module version = 2.99.905 [ 96.176] Module class: X.Org Video Driver [ 96.176] ABI class: X.Org Video Driver, version 14.1 ...
the early exit in clipped_glyphs did help for this case.
Created attachment 88657 [details] [review] Always compute glyph extents Does this patch fix the issue?
I too am experiencing corruption in the window "furniture" below a window's content area. This is in kde-3.5.10 scrolling a konqueror (in filemanager mode) window with the files represented as icons. See the emails archived at: http://lists.freedesktop.org/archives/xorg/2013-October/056141.html http://lists.freedesktop.org/archives/xorg/2013-November/056163.html and http://lists.freedesktop.org/archives/xorg/2013-November/056159.html I'll add a screenshot of the corruption I see.
Created attachment 88712 [details] screenshot Screenshot showing curruption in a konqueror window
Created attachment 88716 [details] Xorg log with segfault Chris, that patch seems to cause a segfault immediately after logging in with xfce here. kdm appears fine, but something happens during xfce session startup. I'm attaching the Xorg log with the segfault in it, on the off chance that it's helpful.
Mmm. I don't know if this will make any sense, but it's what my experiments have revealed, so here goes... If the konqueror window is placed at the top left-hand corner of the screen, I get the corruption all the way across the status bar at the bottom of the window when I scroll the window with the mouse wheel (as shown in the screenshot I posted earlier) If, however, I drag and drop the window to the top, right-hand of the screen, force a redraw (by minimising and then re-opening the window) to clear the corruption, and then perform the same scroll action, I don't see the corruption. When I place the window in at top and (horizontal) middle of the screen, I see corruption below the rightmost column of icons in the window, but all the others are fine. With the window a little further left, the corruption will occur below the two rightmost columns. The further left I drag the window, the more columns the corruption with occur below when I scroll the window.
Sorry, I should have said that my experiments that led to the observar=tions in posted in comment 9 where with the patch from commant 5. In fact the driver is built with the tarball of the driver up to and including that patch.. DSo, the patch has not improved things here.
Chris - you may recall that last week, I bisected the problem I am getting to: ec0866e86d365ae3fd9790b1b263d49fc4981220 is the first bad commit commit ec0866e86d365ae3fd9790b1b263d49fc4981220 Author: Chris Wilson <chris at chris-wilson.co.uk> Date: Wed Oct 16 22:39:54 2013 +0100 sna/glyphs: Fix computation of extents for long strings See http://lists.freedesktop.org/archives/xorg/2013-October/056141.html. I reported that the commit did not revert cleanly against the current HEAD. You reported that there had been a fix to that patch, but unfortunately, it didn't dawn on me that reverting the fix first would be the right thing to try. However, in a flash of inspiration, that idea came to me this morning. So, using the tarball up to and including 93193aaf7d0fc4e3a3b9be1632bfd36331b47d2e, which was head earlier this morning, I've reverted yesterday's test patch, the fix (f81a7f7192a821654bc72a6b34625a6367cb8479) and the patch I reached in the bisect (ec0866e86d365ae3fd9790b1b263d49fc4981220) and built the driver. That driver improves things somewhat. I still get some corruption, but it's now wholly contained within the content area of the window - i.e. it does not stray into the status bar or outside the window into other windows lower in the stack. I'll attach a snapshot in a few moments.
Created attachment 88743 [details] Snapshot of window after expreiments described in comment 11
Sorry Chris, 93193aaf7d0fc4e3a3b9be1632bfd36331b47d2e is not the tarball I built the driver from this morning. That commit is, of course, your test patch. The commit I built the driver from is up to and including commit ef842d2ceee4d1ccf8a0f8a81530dc8be8e18b44, but with the three glyph-related patches reverted. Having got that correction out of the way, I can now report that after I posted this morning's findings, I powered my laptop down for a while, whilst I did some other stuff. Since I booted it again, I have made no changes to the system whatsoever, but the (reduced) screen corruption I saw with the newly built driver this morning has now gone away completely. Why it should be different this afternoon, I can't explain. The only possibility I can come up with is that after installing the driver this morning, I would not have done a complete powerdown - I will either have rebooted or just restarted X with Ctrl-Alt-Backspace. So I'm now in more or less the same position as I was in after the bisection. A driver that includes the change "sna/glyphs: Fix computation of extents for long strings" (ec0866e86d365ae3fd9790b1b263d49fc4981220) results in the corruption and one without it doesn't.
So completely puzzled. The current check is whether the entire bounding box of the glyph string is wholly contained within the clip region or else perform individual clipping of glyphs. If you apply diff --git a/src/sna/sna_glyphs.c b/src/sna/sna_glyphs.c index f2c1788..a38dd94 100644 --- a/src/sna/sna_glyphs.c +++ b/src/sna/sna_glyphs.c @@ -711,6 +711,7 @@ glyphs0_to_dst(struct sna *sna, BoxPtr rects; int nrect; int x, y; + int clipped; if (NO_GLYPHS_TO_DST) return false; @@ -721,11 +722,9 @@ glyphs0_to_dst(struct sna *sna, __FUNCTION__, op, src_x, src_y, nlist, list->xOff, list->yOff, dst->pDrawable->x, dst->pDrawable->y)); - if (clipped_glyphs(dst, nlist, list, glyphs)) { - rects = REGION_RECTS(dst->pCompositeClip); - nrect = REGION_NUM_RECTS(dst->pCompositeClip); - } else - nrect = 0; + clipped = clipped_glyphs(dst, nlist, list, glyphs); + rects = REGION_RECTS(dst->pCompositeClip); + nrect = REGION_NUM_RECTS(dst->pCompositeClip); x = dst->pDrawable->x; y = dst->pDrawable->y; @@ -800,8 +799,10 @@ glyphs0_to_dst(struct sna *sna, r.dst.x, r.dst.y, x2, y2, rects[i].x1, rects[i].y1, rects[i].x2, rects[i].y2)); - if (rects[i].y1 >= y2) + if (rects[i].y1 >= y2) { + assert(clipped); break; + } if (r.dst.x < rects[i].x1) dx = rects[i].x1 - r.dst.x, r.dst.x = rects[i].x1; @@ -826,8 +827,12 @@ glyphs0_to_dst(struct sna *sna, r.height = y2 - r.dst.y; tmp.blt(sna, &tmp, &r); apply_damage(&tmp, &r); + } else { + assert(clipped); } } + } else { + assert(clipped); } } else { struct sna_composite_rectangles r; and compile with --enable-debug, do we get a hit? Do we still get a hit with --enable-debug=full, and if so can you please attach the debug Xorg.0.log?
(In reply to comment #14) > > and compile with --enable-debug, do we get a hit? Do we still get a hit with > --enable-debug=full, and if so can you please attach the debug Xorg.0.log? If by getting a hit you mean do we get a desktop crash, then the answer is yes. I get the crash (with drivers compiled with --enable debug and with --enable-debug=full) when a konqueror window is opening to show the contents of my home directory. It is an odd problem though. Over the weekend, I had some stuff I had to get done, so I reverted to a stable driver. This morning, I re-installed the driver I built last week, with your test patch and the two glyph-related changes reverted. The corruption I reported in comment 11 (i.e. wholly contained within the content area of the window) was there again. I closed the laptop down and restarted it a few hours later and the corruption was gone again. This evening it was back again. Very odd! Anyway, I applied today's patch to ef842d2ceee4d1ccf8a0f8a81530dc8be8e18b44, but did not revert last week's test patch or the glyph-related changes. I'll attach the Xorg.0.log in a moment. It's a 13MB uncompressed, so I've bzipped it.
Created attachment 89060 [details] Xorg.0.log from tests described in comment 15
commit 4493fb8d21fa013a074f7de66387e92ef23d191a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Nov 12 00:05:11 2013 +0000 sna: Apply drawable offset to glyph bbox prior to checking for clipping This is a correction to commit ec0866e86d365ae3fd9790b1b263d49fc4981220 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Oct 16 22:39:54 2013 +0100 sna/glyphs: Fix computation of extents for long strings in order for us to correctly detect when we need to clip. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71191 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On 11/12/13 08:42, bugzilla-daemon@freedesktop.org wrote: > Chris Wilson <mailto:chris@chris-wilson.co.uk> changed bug 71191 <https://bugs.freedesktop.org/show_bug.cgi?id=71191> > What Removed Added > Status NEW RESOLVED > Resolution --- FIXED > > *Comment # 17 <https://bugs.freedesktop.org/show_bug.cgi?id=71191#c17> on bug 71191 > <https://bugs.freedesktop.org/show_bug.cgi?id=71191> from Chris Wilson <mailto:chris@chris-wilson.co.uk> * > > commit 4493fb8d21fa013a074f7de66387e92ef23d191a > Author: Chris Wilson <chris@chris-wilson.co.uk <mailto:chris@chris-wilson.co.uk>> > Date: Tue Nov 12 00:05:11 2013 +0000 > > sna: Apply drawable offset to glyph bbox prior to checking for clipping > > This is a correction to > > commit ec0866e86d365ae3fd9790b1b263d49fc4981220 > Author: Chris Wilson <chris@chris-wilson.co.uk <mailto:chris@chris-wilson.co.uk>> > Date: Wed Oct 16 22:39:54 2013 +0100 > > sna/glyphs: Fix computation of extents for long strings > > in order for us to correctly detect when we need to clip. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71191 <show_bug.cgi?id=71191> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk <mailto:chris@chris-wilson.co.uk>> > This fixes the problem of drawing outside the content area of the window, so... Tested-by: Chris Clayton <chris2553@googlemail.com> However, as I've said, I sometimes get corruption inside the content area. As that problem comes and goes and I haven't figured out a reliable way of reproducing it, I'll run the driver for a few days and report back. > ------------------------------------------------------------------------------------------------------------------------ > You are receiving this mail because: > > * You are on the CC list for the bug. >
On 11/14/13 10:46, Chris Clayton wrote: [snip] > > This fixes the problem of drawing outside the content area of the window, so... > > Tested-by: Chris Clayton <chris2553@googlemail.com> > > However, as I've said, I sometimes get corruption inside the content area. As that problem comes and goes and I haven't > figured out a reliable way of reproducing it, I'll run the driver for a few days and report back. > I have had no instances of the problem of corruption inside the content area, so it seems that the problems I have reported with the driver are now fixed. Thanks, Chris.
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.