Yes, it would. In GL we use double and triple buffering to achieve
that effect. In X we use the instruction queue to achieve the same
effect. We put the commands in a queue, flush them to make sure they
have reached the X server and then continue on. Just as GL double and
triple buffers images, X buffers commands. Your X code will block when
the queue is full just the same way GL code will block when there is
no buffer available.
Even without vsync, glXSwapBuffers will induce a delay somewhere so
that you’re never working on more than one frame at a time (with
double buffering, anyway), won’t it? My ex-Discreet Logic co-worker
tells me that it usually either blocks if you do a second one before
the first one is finished, or the next drawing command after the
glXSwapBuffers will block, preventing client state from overrunning
server state (or, often, hardware state) by too much.
In X, there’s no such throttling, other than the size/length of the
queue itself, so you have to provide it yourself. You can throw a
lot of XCopyArea at the X server in a second, giving it work for
many seconds to come.
But…
If you want to ensure that you do not queue up to many operations
there are ways to do that. The easiest is to use XSendEvent to send a
fake event. Before sending it you increment a counter and after
sending it you XFlush. When the fake event comes back to the event
processing code you decrement the counter and discard the event. If
you find that the counter is higher than you like, say 1, 2 or 3, you
can XSync which should result in a zero counter and then go on. That
would do what you want, without such frequent calls to XSync. It would
also work the pretty much the way you want from using XCB’s version of
XSync. If you set you limit to 1 then you could have one set of
instructions running on the server while you are busy building a new
set on the client.
… this is an excellent trick, and I think should do very well, for a
game development library, anyway.
For the general case of “real” GUI applications, XCB is still better,
because there’s a number of functions that round-trip to the X server
while other things could be done (copy/paste or drag and drop, say),
and you still end up having silly slow downs. Only a few years back,
the main thing making Firefox start really really slowly over a long
distance network was a long series of XQueryExtension, for example,
which could very well have been all sent together, then all received
together (which the XCB API allows).
But in SDL, there probably isn’t enough things like that (how often do
we really do
XCB provides a fully generic way of accomplishing this, by simply
making no function be blocking, and cutting them all in send and
receive phases. But since my main problem with SDL is that none of
what it does is blocking (except for this XSync that’s being called
all the time), which is kind of the opposite. A “real” GUI application
uses a much wider range of X commands, so the usefulness of XCB would
be much more important, but for SDL, this should do.
We’d just need to get rid of that XSync in SDL, then (I think the
others are all during the setup of MITSHM stuff, sounds okay to me).
XShmPutImage has an option to request that an event be sent to tell
you when it is safe to touch the image again. So, you have the option
of either XSync-ing to make sure the operations are done or to wait
for an event.
Right, I remember now that I didn’t use it because I didn’t think I
had an equivalent for the non-MITSHM case, but I was mistaken.On Tue, Jun 30, 2009 at 4:34 PM, Bob Pendleton wrote:
–
http://www.google.com/profiles/pphaneuf
(Really, I can see