[Fwd: Re: CVS Update: xc (branch: trunk)]

[Owen Taylor]

On Tue, 2005-01-04 at 16:27 -0700, Brian Paul wrote:

> > In that case glxgears then would wait
> > for the event after having prepared the next frame (e.g. for(;;) {
> > swap_buffers() ; render_background_buffer_content();
> > wait_for_swap_event() ; swap_buffers(); }) - glxgears would then render
> > with maximum speed but wouldn't spam the server to death.
> 
> But there is no such thing as 'wait_for_swap_event()'.

Well, actually, you can do things like:

 A) Call glSwapBuffers
 B) Change a property
 C) Do some more drawing
 D) Use XPending()/XNextEvent() to read events from the server
    and see if the PropertyNotify is among them

This allows you to see when the server executes the glXSwapBuffers
command.
Though it only works if you know you are indirect rendering. And it
doesn't
account for graphics card pipeline latency (not an issue with 
software-only indirect rendering)

> Again, I can come up with any number of ways an OpenGL application 
> might send a stream of rendering commands which will overwhelm a slow 
> server and cause a command back-log.

For the core X protocol, if you write too many commands to the server,
you get a big backlog. Tough. If you want to do better, you need to
either call XSync() or use more sophisticated techniques to try and
guess how far ahead to write.

If the frame drawing time is predictable, there is an optimum amount
to write ahead based on A) The bandwidth to the X server, and 
B) The speed commands are being executed. But should libGL try to
second-guess the application on that?

Regards,
				     Owen

(Throttling the write-ahead to 4 frames or something should be 
harmless, but at that point the application is already pretty lagged,
so it's no real solution.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050104/6ae35b12/attachment.pgp>