Ideas for X improvement.

Antoine Martin antoine at
Fri May 27 14:08:32 PDT 2011

On 05/28/2011 12:39 AM, David Jackson wrote:
> 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.
I happen to maintain an enhanced xpra (not quite a fork yet).
Upstream has not made any releases since 2009, but we do make regular
releases, including one today:
This latest version includes an exciting new feature: bandwidth
constrained adaptive JPEG compression (thanks to Arthur Huillet).

Although xpra is designed to work with Xvfb, we have done some work to
make it easier to run against Xdummy or even a full blown graphics
accelerated server. Hopefully, we can take this further. Help is always
welcome ;)


> 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.
>  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.
> 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.
> I have not had the opportunity to study modern video hardware so these
> are guesses.
> On Fri, May 27, 2011 at 12:23 PM, David Jackson <djackson452 at
> <mailto:djackson452 at>> wrote:
>     Thank you for the information. As I mentioned, I was previously
>     aware of Xmx, Xmove and XTV..
>     On Fri, May 27, 2011 at 11:44 AM, Alan Coopersmith
>     <alan.coopersmith at <mailto:alan.coopersmith at>>
>     wrote:
>         On 05/26/11 12:29 PM, David Jackson wrote:
>         > The client wouldnt have to be moved between servers at all, it
>         could be the same
>         > proxy server, the proxy server could then open up connections
>         to actual X
>         > servers and forward things to the real X servers. The proxy
>         would massage and
>         > rework data as necessary to trick the X client and hide the
>         fact it is being
>         > displayed to many X servers and also keep the X servers in the
>         dark about what
>         > is really going on as well. This requires no protocol changes
>         and no changes to
>         > the clients or servers. There are already two or more
>         codebases that this has
>         > already been done on, one is something called Xmux, the other
>         was something
>         > called Xshare or something, and I am aware of a possible third
>         that was called
>         > XTV. None are actively developed at this time.
>         --
>                -Alan Coopersmith-        alan.coopersmith at
>         <mailto:alan.coopersmith at>
>                 Oracle Solaris Platform Engineering: X Window System
> _______________________________________________
> xorg at X.Org support
> Archives:
> Info:
> Your subscription address: antoine at

More information about the xorg mailing list