views:

87

answers:

3

Hi,

I'm experimenting with developing a tool for remote OpenGL rendering, in C++. The basic idea is:

  1. The client issues OpenGL commands like it's a normal app
    • Those commands are actually sent over the network to an external server
    • The server performs the rendering using some off-screen technique
    • Once done, the server transmits a single frame over the network to the client
    • The client renders the frame on screen.
    • Loop.

I know I shouldn't start worrying about optimization if I don't have a finished product yet, but I'm pretty sure that is going to be very slow, and the bottleneck is probably going to be the single frame transmission over the network, even if those computers are connected in the same LAN.

I'm thinking about using some kind of video streaming library. That way, the frames would be transmitted using proper compression algorithms, making the process faster.

Am I in the right path about this? Is it right to use a video streaming library here? If you think so, what's a good library for this task (in C or C++, preferably C++)?

Thank you for your help!

A: 

Imagine having to spend $ on both machines to provide them with proper graphics processing power. You could avoid this and simplify the client development if you centralize all the graphics related tasks on one single machine. The job of the client would be only to send/receive/display data, and the server could focus on processing the graphics (OpenGL) and sending the data (as frames) back to the client.

The bottleneck you referred to depends on a couple of things on your side: the size of the images and the frame rate you need to send/receive/display them.

These are some of the interesting topics I've read and hopefully they will shed a light on the subject:

http://stackoverflow.com/questions/1825338/video-streaming-using-c/1825369#1825369

http://stackoverflow.com/questions/464732/how-do-i-stream-video-and-play-it/465085#465085

karlphillip
+1  A: 

You have two solutions.

Solution 1

  • Run the app remotely
  • Intercept the openGL calls
  • Forward them on the network
  • Issue the openGL calls localy

-> complicated, especially when dealing with buffers and textures; the real openGL code is executed locally, which may not be what's wanted, but it's up to you. What's more, it's transparent for the remote app (no source modification, no rebuild). Almost no network communication.

Solution 2 : what you described, with the pros and cons.

If you go for Solution 2, don't bother about speed for now. You will have enough challenges with openGL as it is, trust me.

Begin by a synchronous mode : render, fetch, send, render, fetch, send Then a asynchronous mode : render, begin the fetch, render, end of the fetch, begin the send, render, etc It will be hard enough, I think

Calvin1602
+1  A: 

Depending on the resolution you need to support and the speed of your LAN it may be possible to stream the data uncompressed.

A 24-bit 1280x1024 frame requires 30 Mbit, and with a gigabit ethernet this means a theoretical 33 frames per second uncompressed.

If that is not enough, adding a simple RLE-compression yourself is fairly straightforward.

Plow