Ideas for X improvement.

[David Jackson]

X.org needs to listen to users on  X Window System  flexibility. X has
always been about mechanism, not policy, that allows users choice and
flexibility, such as in window manangers. Many people I talk to, including
myself, find remote desktop capabilities extremly useful and greatly
increase the useability of the X Window System. Network transparency,
backwards and forward compatability are all vital features X.org needs to
maintain a commitment to. I urge the X window system to increase flexibility
and provide mechanisms that allow people to use X Window System as they
want, to implement the following features.

A display driver that contains a VNC server. The problem with x11vnc is that
it is slow, very slow. XVnc server, which is a X server that contains a VNC
server but has no hardware drivers, is much faster since the VNC server is
built directly into the X server, however this does not allow one to export
their main X display which is also displayed directly to video hardware. The
solution here is to include a driver in the X.org main server distribution
for a VNC server that can be loaded into the X server. The VNC server driver
should be able to be dynamically loaded while the server is running and the
output of the server displayed simultaneously to VNC clients and to the
local video hardware. This can be controlled from provided command line and
GUI utilities.

One of the very severe problems I have been having is that Xvnc does not
support Render extensions, and many applications no longer work without the
Render extension. VNC driver with X.org therefore must support the Render
extension and other ones.

Dynamic runtime enabling and disabling, configuration and setup and removal
of display output and input drivers while the server runs without server
restart. this allows for instance, the user to have the X server display to
a new target while the server runs, or display to many different display
outputs at the same time This includes the VNC Server driver above, this
allows a person to easily swtich the VNC on and off from displaying to
certain outputs, such as they could turn off display to the local monitor
and then turn it back on again, or turn on and off VNC display.

Another feature that increases flexibility to the user would be to allow the
user to direct display of a certain window or the entire root window and
display over an X client connection to another server, or any number of
other servers. This would also forward the windows children who would also
be displayed on the remote server inside the parent window. The forwarded
window could be displayed at any location inside of any window on the remote
server. This allows, for instance, the user when they are using an X server
away from home, to direct applications running on their home X server to
also be displayed simultaneously on their remote X server. This also allows
windows and displays to be multiplexed, displayed to multiple X servers at
the same time. The Window could also be unmapped or minimised on one server
while being displayed on another server. There is flexibility that comes
from a mechanism, not policy approach here, such as chaining a series of
servers to together through daisy chain sharing of certain windows. This
whole thing would likely work by an expose event on the servers being
propogated back through the servers to the original application, and X
protocol. GLX and other X commands being forwarded from one server to
another.

Many users, including myself, want to have many X servers running at the
same time and then at run time be able to change to where these servers are
being displayed, and as well when an app is started, to which server it is
displayed with the -display option. Each server must be allowed to have a
different configuration, including different driver configurations and
display configurations, and input device configurations. Users must be
allowed to have headless and VNC only servers.

While improving and enhancing programming facilities availaible to
developers and enhancing features and flexibility to users, X.org needs to
commit to full backwards compatability with the X11 protocol and the
extensions to it, including binary compatable at the protocol level and
backwards compatability at the xlib API level.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20110525/2c8f0ad9/attachment.html>