Re: [9fans] drawterm tearing

Re: [9fans] drawterm tearing

[erik quanstrom]

> what changed recently?
> not drawterm.

no.  not drawterm.  not the video card.
i've recently "upgraded" x.

	; ls -l `{which drawterm}
	-rwxr-xr-x 1 quanstro users 1226424 Mar 12  2009 /home/quanstro/bin/amd64/drawterm

but that may be a red herring, see below

> can you tell us more about the bug?
> if you resize the window, forcing faces to redraw,
> does steve's face get put back together?
> is it always faces?
> is it always small screen regions?
> etc.

scrolling does not fix the problem.  the framebuffer
is wrong.  forcing faces to redraw does fix the problem.
i don't have enough screen real estate so faces is sometimes
partially obscured by acme.  the tear appears to be in line
with the top of acme's window.  in testing just now it
happened 4/4 times with faces partially obscured and 0/3
times with faces not obscured.

- erik

Re: [9fans] drawterm tearing

[Russ Cox]

> scrolling does not fix the problem.  the framebuffer
> is wrong.  forcing faces to redraw does fix the problem.
> i don't have enough screen real estate so faces is sometimes
> partially obscured by acme.  the tear appears to be in line
> with the top of acme's window.  in testing just now it
> happened 4/4 times with faces partially obscured and 0/3
> times with faces not obscured.

great. now that you have a reproducible test case, try this:

in drawterm/gui-x11/x11.c:/^xdraw it says

        /*
         * drawterm was distributed for years with
         * "return 0;" right here.
         * maybe we should give up on all this?
         */

        if((dxm = dst->X) == nil)
                return 0;

try adding an unconditional "return 0;"
right there and see if the problem goes away.
if so, problem solved, or at least pinned on
some combination of the drawterm x11 code
and the new x11 server you have.
that code is trying to do a good job when
x11 is on the other end of a network connection,
but that case is getting less and less important.

russ

Re: [9fans] drawterm tearing

[erik quanstrom]

> great. now that you have a reproducible test case, try this:
>
> in drawterm/gui-x11/x11.c:/^xdraw it says
>
>         /*
>          * drawterm was distributed for years with
>          * "return 0;" right here.
>          * maybe we should give up on all this?
>          */
>
>         if((dxm = dst->X) == nil)
>                 return 0;
>
> try adding an unconditional "return 0;"
> right there and see if the problem goes away.
> if so, problem solved, or at least pinned on
> some combination of the drawterm x11 code
> and the new x11 server you have.
> that code is trying to do a good job when
> x11 is on the other end of a network connection,
> but that case is getting less and less important.

does fix!

curiosity: is this a locking problem or an arithmetic
problem?

- erik

[9fans] drawterm tearing

[erik quanstrom]

i've recently been suffering from tearing in drawterm
http://www.quanstro.net/9fans/tear.png

 ; xrdb -symbols | grep REL
-DRELEASE=10503000

- erik

Re: [9fans] drawterm tearing

[Russ Cox]

On Fri, Oct 16, 2009 at 1:02 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> i've recently been suffering from tearing in drawterm
> http://www.quanstro.net/9fans/tear.png
>
>  ; xrdb -symbols | grep REL
> -DRELEASE=10503000

what changed recently?
not drawterm.

i'm not claiming drawterm is bug-free, but there must
be something causing this new behavior: a new version
of x11, a new video card, a new version of the host os, etc.
figuring that out might give a clue as to what to look at.

can you tell us more about the bug?
if you resize the window, forcing faces to redraw,
does steve's face get put back together?
is it always faces?
is it always small screen regions?
etc.

russ