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