From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: Ralph Corderoy <ralph@inputplus.co.uk>
Message-ID: <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>
Subject: Re: [9fans] Drawterm and FreeBSD
Date: Fri, 21 Mar 2003 09:59:41 +0000
Topicbox-Message-UUID: 82da506a-eacb-11e9-9e20-41e7f4b1d025

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.

> There does exist an XSynchronize() function that could
> be inserted into the problematic application to help enforce
> sequencing, which might at least help you to identify the exact
> problem.

If drawterm is an Xt Intrinsics application then -synchronous on the
command line would have the same effect.

Cheers,

-- 
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/