Ideas for X improvement.

[David Jackson]

This advice is valid for all software projects. if you want people to help
develop software, document the software code with documentation. Explain how
the parts of the software fit together, how the code operates, explain what
the different parts do, document functions and variables and what each of
those do. Explain the processes involved with several of the code paths,
such as the code path followed at startup, and when a message or event is
recieved, and so. provide documentation that will allow a person with only a
basic understanding of C or Python or other language used to become an
expert in the software, without having to do detective work to try to
backengineer how the software works. With software, it can take months to
figure out how complex software work by looking at source code, with good
documentation this can be reduced to days or weeks.

The X.org developers should also listen to this advice. in the case of X,
this also includes not only documenting fully how the server works and its
internals, but also how video hardware works.

On Fri, May 27, 2011 at 4:08 PM, Antoine Martin <antoine at nagafix.co.uk>wrote:

> 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:
> http://article.gmane.org/gmane.comp.window-managers.parti.general/511
> 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 ;)
>
> Cheers
> Antoine
>
> > 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 gmail.com
> > <mailto:djackson452 at gmail.com>> 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 oracle.com <mailto:alan.coopersmith at oracle.com>>
> >     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.
> >
> >         http://en.wikipedia.org/wiki/Xpra
> >         http://code.google.com/p/partiwm/wiki/xpra
> >
> >         --
> >                -Alan Coopersmith-        alan.coopersmith at oracle.com
> >         <mailto:alan.coopersmith at oracle.com>
> >                 Oracle Solaris Platform Engineering: X Window System
> >
> >
> >
> >
> >
> > _______________________________________________
> > xorg at lists.freedesktop.org: X.Org support
> > Archives: http://lists.freedesktop.org/archives/xorg
> > Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> > Your subscription address: antoine at nagafix.co.uk
>
> _______________________________________________
> xorg at lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> Your subscription address: djackson452 at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20110527/209d97fa/attachment.html>