THanks for the info on XPRA. I will give it a try. It looks promising and the way they use the compositing manager sounds genius. It sounds like they get basically final rasterised data from the compositor, so basically it seems like a huge bitmap, if I am correct. Or maybe I am not. <br>
<br>If hardware is being used to generate rasterised data from opengl commands, then, i suppose the compositer would need to get rasterised data back from the hardware for individual windows, rather than the whole display.<br>
<br> I am guessing that some hardware may not support that but I am not sure. Some hardware i guess just provides a video array for bitmap data and does not take OpenGL commands. I am guessing more advanced hardware takes OpenGL commands and generates rasterised data ready for the screen from them. I suppose depending on hardware design the hardware may allow the programmer to give opengl commands to the graphics card and it renders them to screen, or it may give the programmer the opportunity to rasterise opengl scenes, and instead of hardware displaying them to screen,  the programmer get the bitmap back and save them or use them in some way in programs, and then feed the bitmap back to the video card when desired. That way the programmer could render individual windows one at a time, get the bitmap data, then do whatever composite or process need for the windows data, then dump all of the windows bitmaps to the video hardware. <br>
<br>It is unlikely the entirety of each window would need to be rasterised as well since some windows may be partially or fully non visible. <br><br>I have not had the opportunity to study modern video hardware so these are guesses. <br>
<br><div class="gmail_quote">On Fri, May 27, 2011 at 12:23 PM, David Jackson <span dir="ltr"><<a href="mailto:djackson452@gmail.com">djackson452@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thank you for the information. As I mentioned, I was previously aware of Xmx, Xmove and XTV..<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Fri, May 27, 2011 at 11:44 AM, Alan Coopersmith <span dir="ltr"><<a href="mailto:alan.coopersmith@oracle.com" target="_blank">alan.coopersmith@oracle.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 05/26/11 12:29 PM, David Jackson wrote:<br>
> The client wouldnt have to be moved between servers at all, it could be the same<br>
> proxy server, the proxy server could then open up connections to actual X<br>
> servers and forward things to the real X servers. The proxy would massage and<br>
> rework data as necessary to trick the X client and hide the fact it is being<br>
> displayed to many X servers and also keep the X servers in the dark about what<br>
> is really going on as well. This requires no protocol changes and no changes to<br>
> the clients or servers. There are already two or more codebases that this has<br>
> already been done on, one is something called Xmux, the other was something<br>
> called Xshare or something, and I am aware of a possible third that was called<br>
> XTV. None are actively developed at this time.<br>
<br>
</div><a href="http://en.wikipedia.org/wiki/Xpra" target="_blank">http://en.wikipedia.org/wiki/Xpra</a><br>
<a href="http://code.google.com/p/partiwm/wiki/xpra" target="_blank">http://code.google.com/p/partiwm/wiki/xpra</a><br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div>        -Alan Coopersmith-        <a href="mailto:alan.coopersmith@oracle.com" target="_blank">alan.coopersmith@oracle.com</a><br>
         Oracle Solaris Platform Engineering: X Window System<br>
<br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>