Ideas for X improvement.

[David Jackson]

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
<mostawesomedude at gmail.com>wrote:

> /me trudges through the rest
>
> On Wed, May 25, 2011 at 12:53 PM, David Jackson <djackson452 at gmail.com>
> 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
> <MostAwesomeDude at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20110525/bed385e3/attachment.html>