From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: Ralph Corderoy Message-ID: <454b.3e68c3c9.e9a0a@blake.inputplus.co.uk> References: <714e1db4e1070444e5392174bec42571@plan9.bell-labs.com>, <18aefafa4a55e60cd64469860ad0c6a2@plan9.bell-labs.com> Subject: Re: [9fans] refresh problems with drawterm on x (freebsd)? Date: Fri, 7 Mar 2003 16:19:35 +0000 Topicbox-Message-UUID: 7cd078a2-eacb-11e9-9e20-41e7f4b1d025 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/