Ideas for X improvement.

[David Jackson]

On Wed, May 25, 2011 at 4:36 PM, Glynn Clements <glynn at gclements.plus.com>wrote:

>
> David Jackson wrote:
>
> > 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,
>
> What sample size does your analysis use? How many different hardware
> configurations, and how many different applications?
>
> x11vnc has the drawback that it's reading a framebuffer which is
> typically in video memory, so the data has to be read over the bus.
> The speed of this operation may vary significantly depending upon the
> hardware being used. It may also vary depending upon the amount of
> activity (i.e. if it has to wait for the outstanding rendering
> operations to complete before it's allowed to read the framebuffer).
>
> Xvnc has the advantage that the framebuffer is in system memory. But
> this is also a drawback, as it means that all rendering is performed
> in software. Try running an application which uses OpenGL to render
> detailed scenes; you might want to reconsider your assertion about
> Xvnc is fast.
>
> IOW, it's a case of "choose your poison". x11vnc has fast rendering
> but slow export, Xvnc has slow rendering but fast export. A similar
> tradeoff exists for X11 verus VNC for remote display.
>
> > 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.
>
> Does the VNC driver read the framebuffer on the video card (which
> suffers from the same performance issues as x11vnc), or does it
> attempt to duplicate the framebuffer by emulating whatever video
> hardware is installed? If it's the latter, the application will be
> slowed to the speed of the VNC driver's software renderer (which will
> be extremely complex, as it will have to mimic every feature which is
> available in at least one hardware driver).
>
> > 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.
>
> The main "other one" being OpenGL, for which a software implementation
> will be much, much slower than a modern GPU.
>
> > 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.
>
> To do this at the protocol level requires a completely new protocol
> and significant support from the toolkit. The X protocol exposes a
> significant amount of implementation detail to the client. Much of
> that information is required to remain constant for the lifetime of
> the client.
>
> E.g. if the client queries the list of OpenGL extensions, and starts
> using some of them, there's no mechanism by which to inform the client
> that an extension is suddenly unavailable, which would be required if
> you were to "redirect" the window to a different server with different
> hardware.
>
> Even if such a mechanism existed, it's debatable how many applications
> would support it. Reconstructing the current server-side state from
> scratch is a lot of work, and toolkits can't always help (e.g. they
> won't help reconstruct the server-side OpenGL state, as the toolkit
> doesn't get involved in the rendering process).
>
> > 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.
>
> AFAICT, there are only two feasible approaches to window "mobility":
>
> 1. VNC-like framebuffer sharing. The application connects to a
> specific X server which performs all rendering. You have the option to
> forward rendered images to other systems for physical display.
>
> 2. Use GUI toolkits which offer an abstract, high-level interface to
> the client. The toolkit has the ability reconstruct and clone windows
> at will.
>
> --
> Glynn Clements <glynn at gclements.plus.com>
> _______________________________________________
> xorg at lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> Your subscription address: djackson452 at gmail.com
>


x11vnc is noticeably slower. I think the really annoying thing that makes it
hard to use is that there is a longer delay when typing for characters to
display on the screen than there is with Xvnc. I can notice this. When you
are typing characters do display much more quickly to the screen on Xvnc.
That is a big issue, because, it is really hard to type when you have a long
delay of characters appearing when you type them.Perhaps this is due the
polling of the framebuffer.

The VNC driver could  do its own rendering, get the graphics commands from
the application directly. Yes, you are correct that is slow for many complex
operations. You are correct, the other alternative is to grab the
framebuffer. You are correct it might be faster for those complex graphics.
Grabbing the framebuffer inside the X server and feeding it out to VNC
clients via a VNC server in the X server, might save a little bit of time by
avoiding having to be sent over a socket to another process, but i do not
know if that is true. It may be it might do all that being interrupted fewer
or no times, where with x11vnc you are gauranteed a task switch and some
time for x11vnc to get the CPU. I guess x11vnc asks for the framebuffer over
an X connection, then wait for the X server to get the CPU to process the
request, then wait again for x11vnc to get CPU and the data to be sent to
VNC clients. if we have a framebuffer based VNC driver inside the X server,
it may allow for tighter synchronisation and less delay. I cannot say how
significant it would be.

The other issue mentioned, about the window forward feature. You are
correct. I have been thinking about these issues. It would be best for it to
be invisible to clients. Ive been thinking about these problems.

I am know C, however I know little about X internals or X protocol. Is there
a good source of documentation that would give a person a full introduction
and overview of how the X server works,including how it all fits together,
and a tour of the system and documentation of the internals such as
functions, variables etc? Basically everything need for a person who only
knows C to learn all about how the X server works?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20110525/e9c97742/attachment.html>