Re: [Dri-devel] Re: [Xpert] GLX over network...

[Dan M. <dm...@dc...>]

> An interesting idea, but possibly one with only limited application
> here.  It really depends on the data stream, but if every vertex in an
> animation frame differs from the previous one (and that's not hard to
> do) you're pretty much stuck.

IMHO the right way to do remote rendering is to use some sort of high-level
scene graph protocol between client and server. Look at how Quake handles
slow internet connections -- the network server transmits very high-level,
low bandwidth commands ("Player 5 moves to 123.0,482.1"), which the local
client translates into high-bandwidth rendering commands. You could argue
that Quake can render at high framerates across a 56k modem line!

It's perfectly feasible to send scene graph updates through a socket; you
just can't expect to shove every single vertex through the same pipe. (look
at where graphics API's are going -- I betcha the next generation chips will
be storing large chunks of high-level scene data in video RAM to minimize
bus traffic...)

Applied to your particular concern: how about a local direct-rendering
client that uses one of the many OpenGL scene graph libraries? Make RPC
stubs for the entry points and use that as your network protocol =).

Dan