[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#627087: marked as done (xpdf causes screen corruptions when another window is dragged over its window)

Your message dated Sun, 25 Sep 2011 16:58:19 +0200
with message-id <20110925145818.GA8993@radis.liafa.jussieu.fr>
and subject line Re: Bug#615197: xserver-xorg-video-intel: Screen corruptions to due insufficient clipping
has caused the Debian Bug report #615197,
regarding xpdf causes screen corruptions when another window is dragged over its window
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
615197: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615197
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: xpdf
Version: 3.02-12
Severity: important

When I drag another window in front of xpdf window, the other windows 
gets corrupted (see attached screenshots). 

I've noticed this problem in two machines with Intel
chipsets (82865G and 945GM/GMS/GME) so it may be associated with
known problem with Intel driver (e.g.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596085 ).
Two other machines with  "[SiS] 65x/M650/740 PCI/AGP VGA" and 
"nVidia Corporation NV18 [GeForce4 MX4000]" chipsets didn't show such problem).

Anyway with Linux kernel < 2.6.38 the problem on Intel machines occures
only with xpdf, so it must be associated with particular way in which
xpdf interacts with the Xserver.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.37.3 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xpdf depends on:
ii  lesstif2                      1:0.95.2-1 OSF/Motif 2.1 implementation relea
ii  libc6                         2.13-4     Embedded GNU C Library: Shared lib
ii  libgcc1                       1:4.6.0-2  GCC support library
ii  libpoppler5                   0.12.4-1.2 PDF rendering library
ii  libstdc++6                    4.6.0-2    The GNU Standard C++ Library v3
ii  libx11-6                      2:1.4.3-1  X11 client-side library
ii  libxt6                        1:1.1.1-1  X11 toolkit intrinsics library

Versions of packages xpdf recommends:
ii  gsfonts-x11                   0.22       Make Ghostscript fonts available t
ii  poppler-data                  0.4.4-1    Encoding data for the poppler PDF 
ii  poppler-utils                 0.12.4-1.2 PDF utilitites (based on libpopple

xpdf suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 2:2.16.0-1

On Mon, May 16, 2011 at 09:52:13 +0100, Chris Wilson wrote:

> On Sun, 15 May 2011 21:51:59 +0200, Julien Cristau <jcristau@debian.org> wrote:
> > On Sun, May 15, 2011 at 21:34:26 +0200, Thomas Richter wrote:
> > > Sorry, I don't quite get the question. All what the code does is
> > > that it checks whether the current line (fullY1) is between the top
> > > edge of the current rectangle in the damage region (pbox->y1<=
> > > fullY1) and above
> > > the bottom edge of the damage region (pbox->y2>  fullY1). It is
> > > probably written in a somewhat unconventional way. A nicer way to
> > > put it is:
> > > 
> > > fullY1 >= pbox->y1 && fullY1 < pbox->y2
> > > 
> > > Thus, line at or below the top edge, and above the bottom edge. A
> > > rectangle doesn't have to be invalid to have fullY1 >= pbox->y1 and
> > > fullY1 < pbox->y2. I'm not quite clear what the break is used for,
> > > but
> > > I assume that the rectangles are ordered by increasing Y coordinate, and
> > > that the code can terminate early if it detects a rectangle in the
> > > damage region that has a top edge below the line.
> > > 
> 
> The clip rectangles are YX banded, so that if we see a rectangle which
> starts below the point of interest, we know all further rectangles are
> below the point.
> 
> The question that remains is then does this rectangle, which we know has
> to start above (or equal to) the point extend beyond the point. So we need
> to test:
> 
> diff --git a/uxa/uxa-accel.c b/uxa/uxa-accel.c
> index 0650ac2..56f219c 100644
> --- a/uxa/uxa-accel.c
> +++ b/uxa/uxa-accel.c
> @@ -178,7 +178,7 @@ uxa_fill_spans(DrawablePtr pDrawable, GCPtr pGC, int
> n,
>                                 if (pbox->y1 > fullY1)
>                                         break;
>  
> -                               if (pbox->y1 <= fullY1) {
> +                               if (pbox->y2 > fullY1) {
>                                         partX1 = pbox->x1;
>                                         if (partX1 < fullX1)
>                                                 partX1 = fullX1;
> 
> which is probably what you said originally. If you send a patch along
> these lines, I will gladly apply it. And if you have a test case to hand,
> better yet -- collecting examples of where I goofed to prevent repeating
> my mistakes...
> 
That code was changed in 2.16, so I think this should be fixed, closing.

Cheers,
Julien

--- End Message ---
Reply to: