From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: "Douglas A. Gwyn" <DAGwyn@null.net>
Message-ID: <3E7771FC.33FE8147@null.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <5.2.0.9.0.20030312171850.030086d0@pop.noos.fr>, <3E75B4E9.8050305@strakt.com>
Subject: Re: [9fans] Drawterm and FreeBSD
Date: Wed, 19 Mar 2003 10:03:23 +0000
Topicbox-Message-UUID: 81a74bc6-eacb-11e9-9e20-41e7f4b1d025

Boyd Roberts wrote:
> Philippe Anel wrote:
> >     It seems that [at least] XCopyArea and XFillRetangles
> > are sent in the same order with the same parameters when
> > glyph are drawn and when they are not.
> I have some vague recollection about a comment in an
> early UNIX port of sam that remarked that such things
> may break wrt Save Unders.  This would have a been
> a sam port that BRL were involved in.

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.  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.  One thing I will caution you
about is feeding arbitrary characters to XDrawString(); if
there are embedded control characters it can lock up the X
server.  It is also worth remembering that XORing with the
display bitmap can be excruciatingly slow on some X-servers.
Of course, there are a number of things that could be done
wrong, and it takes detective work to track this kind of
thing down.  Good luck!