Re: [9fans] refresh problems with drawterm on x (freebsd)?

[Ralph Corderoy <ralph@inputplus.co.uk>]

Hi Russ,

> it seems pretty clear that painting the background is completing after
> painting the foreground characters, but the question is why.  we have
> the same problem with the accelerated hardware drivers -- drawing the
> background is an accelerated op so you have to issue it and then wait
> for it to complete before trying to draw the text.  i did not realize
> that sequential X calls can overlap like that, but empirically, they
> must.

I'm coming into the conversation part-way through here, but if you're
saying you've an X client doing XDrawText() and XFillRectangle() Xlib
calls, or you're generating the equivalent protocol, there's no way that
the operations should be done out of order.

> yesterday i tried inserting calls to XSync() after issuing the
> XFillRectangle calls, but that didn't help.  i still need to try
> XFlush.  i really wish the documentation were better.

X protocol is asynchronous, but the order is maintained.  You can watch
the protocol by putting a `snooper' in the middle, but if you find a
filled rectangle drawn before the text is covering it then it suggests
an X server bug, probably specific to the graphic card's driver.  A
mixture of accelerated and non-accelerated ops are the driver's problem,
not the X client's or the device independent parts of the X server.

Does this only occur with a specific X server?  If multiple people are
seeing it with different graphic cards/X servers, then it suggests a
client bug, possibly a dodgy Graphics Context results in the
text-drawing not changing any pixels.

Cheers,

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