From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <5.2.0.9.0.20030321115722.037080a0@pop.noos.fr>
To: 9fans@cse.psu.edu
From: Philippe Anel <philippe.anel@noos.fr>
Subject: Re: [9fans] Drawterm and FreeBSD
In-Reply-To: <5ad6.3e7a4899.14367@blake.inputplus.co.uk>
References: <5.2.0.9.0.20030312171850.030086d0@pop.noos.fr>
 <3E75B4E9.8050305@strakt.com>
 <3E7771FC.33FE8147@null.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Date: Fri, 21 Mar 2003 12:24:02 +0100
Topicbox-Message-UUID: 82dee490-eacb-11e9-9e20-41e7f4b1d025

At 09:59 21/03/03 +0000, you wrote:
>Hi,
>
> > BRL's involvement in the X11 part would be mainly Gary Moss and to a
> > lesser extent myself.  The only use of XCopyArea in our version of
> > sam/xterm is the bitblt() function, and there are no special
> > precautions or comments there.  XFillRectangle is used in three
> > places, rectf() (same notes as for bitblt()) and texture(), where
> > color depth 1 is handled somewhat differently due to X-server not
> > supporting it.  But there doesn't seem to be anything about order of
> > the actions.
>
>Stuff like XCopyArea or XCopyPlane is often found to exhibit bugs when
>an accelerated server backend has replaced the standard `device
>independent' implementation.  Has anyone snooped the protocol when it
>fails and sent off the relevant snippet to the server maintainers?  It
>seems unlikely the client could be doing anything wrong.

I agree with your analyze.

Indeed, using ethereal, it seems there is no difference in the data
exchanged between the client and the server when the bug arise and
when drawterm works.

However, I noticed an extra XCopyArea between two 'memimage's before
the XCopyArea-XFillRectangle 'normal' sequence when glyphes are not
drawn.

I didn't (and still don't) have the time to look further into that.
Moreover, with my 'XInitThreads()' patch, drawterm still rocks here.

I'll try to post the ethereal logs next week.

         Philippe,