[9fans] Drawterm and FreeBSD

[9fans] Drawterm and FreeBSD

[Philippe Anel]

Hello,

	I tried to figure out why occasionally, some glyphes
aren't drawn under drawterm on my FreeBSD box.
	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.
	Yesterday, I realized that the function XInitThreads()
is not called in the source of drawterm, so, in desperation,
I decided to add it, and until now, the bug didn't occur.
	Might it be that simple ? I don't think so.

	I hope it helps,
	Xigh.

Re: [9fans] Drawterm and FreeBSD

[Russ Cox]

It's certainly possible.  There are multiple processes
doing X operations:

	- any proc in devdraw on behalf of a client (only one at a time)
	- any proc in setcursor on behalf of a client
	- the proc reading x events and feeding them
	  to the keyboard and mouse drivers

I think the third guy is safe, but it's possible
that the first two conflict causing some calls to
get dropped.  There are a lot more character
draws than there are background fills, which
explains why we don't notice background fill
problems.

Russ

Re: [9fans] Drawterm and FreeBSD

[Russ Cox]

XInitThreads() does not fix the problem
on the Thinkpad X21 we've been using as
a test case.  I changed the code to allocate
a new XDisplay for the cursor code, so now
each different process has its very own 
XDisplay to use.  Regardless of whether
XInitDisplay is there, the glyph problem
persists.

I changed stringbg to paint only half
the background for debugging, but got faked out
by the fact that libframe does its own background
painting.  Tomorrow perhaps.

Russ

Re: [9fans] Drawterm and FreeBSD

[Boyd Roberts]

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.

Re: [9fans] Drawterm and FreeBSD

[Douglas A. Gwyn]

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!

Re: [9fans] Drawterm and FreeBSD

[Ralph Corderoy]

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/

Re: [9fans] Drawterm and FreeBSD

[Philippe Anel]

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,

Re: [9fans] Drawterm and FreeBSD

[Russ Cox]

We found that XInitThread slows down
drawterm a lot, probably enough that the
race no longer happens on your machine.

Re: [9fans] Drawterm and FreeBSD

[Russ Cox]

> 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.

Which is it?  No difference or an extra XCopyArea?

The normal sequence should be a single XFillRectangle
(to erase the background for a whole line of text)
followed by a large number of XCopyAreas (one for
each character to draw the text).

Re: [9fans] Drawterm and FreeBSD

[Ralph Corderoy]

Hi Russ,

> The normal sequence should be a single XFillRectangle (to erase the
> background for a whole line of text) followed by a large number of
> XCopyAreas (one for each character to draw the text).

Presumably, just one thread does this and no other thread ever writes to
XFillRectangle's drawable?

I'd find a way to bump this off to the server author's ASAP.  Perhaps a
simple test-case that people can run against a server with no Plan 9
involved so everyone can try it and watch for problems.

Cheers,

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