X Server is a complex piece of software and thus there are complex issues involved with its implementation that warrant the message length. I did put most of my concerns in this message so there is not much more I need to add. The message is not that long though, its not a 50 page technical document. <div class="gmail_quote">On Wed, May 25, 2011 at 3:25 PM, Corbin Simpson <<a href="mailto:mostawesomedude@gmail.com">mostawesomedude@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> /me trudges through the rest <div><div></div><div class="h5"> On Wed, May 25, 2011 at 12:53 PM, David Jackson <<a href="mailto:djackson452@gmail.com">djackson452@gmail.com</a>> wrote: > Backwards compatability is always a must. It has become clear that X > graphics primatives today are outgrown today by some applications today > which have intense graphics needs. Current X protocol must continue to be > supported however new mechanisms can always be offered. The solution to this > that provides the most flexibility for users is for the X Window System to > provide more advanced and more diversity of vector graphics rendering > facility over the X protocol, and that is already being done to an extent > with GLX. The X Window System xlib, xcb, glx libraries and so on provide > access to these features. The reason for this is that it applications > should be encouraged to offload as much graphics operations and processing > to the X provided library APIs as possible and do as little of that as > possible in the applications own code or in 3rd party toolkits. It should be > recommended that applications avoid in application and 3rd party toolkits > rasterisation and rendering as much as they can. This means that more data > is being sent as higher level vectors which use less bandwidth over the wire > rather than the application sending bitmaps it has created in application > code and 3rd party driver code. That increases flexibility when display an > application remotely and locally, and also allows as much vector and 3D > graphics processing to be done by the video card as possible. Another > feature that can speed up and increase flexibility of displaying locally or > remotely is allowing the application to upload a frequently used bitmap once > and storing it in the server, adn referring to it later on with a token. The > application can delete the bitmap when no longer needed, and if the user > sets a limit to X server memory usage, the X server could delete long unused > bitmaps and ask for the bitmap again if the application uses the token for > it. The user could also completely disable this in which the server will ask > for the bitmap (or just the damaged region) with each redraw. This concept > could also be used for vector graphics as well or any other data the client > sends to the server. By avoiding placing low level graphics rasterisations > in applications own code or 3rd party libraries and having apps use X window > system provided libraries for that whenever possible, it makes it more > flexible to use applications over different mediums and display targets. It > works well for both local desktop display and remote display. </div></div>Hey, cool, sounds like you discovered Xrender and Xft. Yay! We already know why Xrender's far more awesome than core rendering. Nobody's disputing that, and our current plan *is* to keep core rendering for protocol compatibility while encouraging application developers to use toolkits which offload rendering and use modern rendering techniques. You also seem to have guessed that backing store is no longer used by the server. Or I think that's what you said; that's a really big wall of text to dig through. <div class="im"> > the above plan preserves the ability to do both network transparent display, > direct rendering, and also preserves the ability to do rasterisation in the > server, in the application, or in the hardware. This is due to the fact that > applications should use Xlib, XCB, and GLX libraries API for rendering > provided by the X Window System. The Xlib libraries can then according to a > users runtime selection, send graphics it recieves over X protocol to a > remote X server, or do direct rendering one of two ways: rasterise the > graphics in application into bitmaps to send directly to video hardware, or > send the vector graohics commands directly to video hardware. The > applications still have an X socket connection to the server in the case of > direct rendering, the server can still coordinate things. The rasterisation > in the X server as well can either utilise its own rasterisation facilities > in server or send the vector commands to video hardware to be rasterised > there. and quite a bit of that is done already with GLX. Alpha transparency, > blurring and antialiasing are common features needed by many apps, and an > application needs these as well as complex vector graphics provided by > further expanded GLX capabilities. The user can then select at runtime the > target the aplication should display to, with the -display flag to select > their X server. if the X server supports direct rendering, it will notify > the X client of this over the X connection, then the graphics API calls from > the application to xlib can be sent directly to video hardware. The X server > can manage and coordinate. Both remote X socket apps and direct rendered > apps could co-exist on the display. </div>Yes, this all already exists in the current, modern X11 desktop. Which part of this isn't already done by Compiz? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <<a href="mailto:MostAwesomeDude@gmail.com">MostAwesomeDude@gmail.com</a>> </blockquote></div>