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.
On Wed, May 25, 2011 at 3:25 PM, Corbin Simpson <[email protected]>wrote: > /me trudges through the rest > > On Wed, May 25, 2011 at 12:53 PM, David Jackson <[email protected]> > 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. > > 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. > > > 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. > > 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 > <[email protected]> >
_______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: [email protected]
