Re: About our effort at NoMachine

On Wednesday 26 March 2003 06:06 pm, you wrote:
> > - Xcompext library is needed to let agents compress images in
> >   various formats and transform replies in events.
>
> Sounds right.  Hadn't thought about cleaning padding bytes, but you're
> probably on to something there.  It is almost certainly worth clearing
> the bytes entirely, as it is likely the memory cycle will happen in any
> case, and then general stream compression works better.

For us, to cleanup padding bytes is a necessity, especially for
images. Image data, infact, is checksummed to find out if it can
be retrieved from cache.

> We're in the middle of grovelling through this data right now, but here
> are a few highlights from this work in progress:
>
> 1) Client side fonts are making a significant reduction in round trips,
> as expected, with real applications, and application startup time is
> significantly reduced, relative to using core fonts, in all cases.
> (local machine, local net, or simulated broadband network).

Sure they are. I checked the remote KDE session I'm running and I
see 76 between X_QueryFont and X_ListFonts, so far, for a total
amount of 500KB of reply data. They would have been many more,
probably, if agent would not have cached duplicate requests across
different clients. Nevertheless the real advantage is when you go to
migrating sessions to different X servers. We are implementing this
and our topmost concerns are fonts, being used in GCs at the time
a session is interrupted, that are not available on the new X server. 

> 2) bandwidth usage for client side fonts is about the same as
> with server side fonts, as expected, even with no code to compress the
> glyphs. Compressing glyphs (or the entire protocol stream) would be a
> serious win.

Agree, and gliphs would be trivial to cache.

> 3) LBX is no better than using straight SSH, and appears to be actually
> worse. LBX looks to have been a bad idea, at least as implemented.

I think that the problem with LBX is only that it doesn't achieve
satisfactory compression results :-), especially with today's clients
that are making use of a huge amount of images. LBX lacked a
strategy to deal with this. The reason it doesn't even achieve the
compression results of straight SSH is probably because it is tied
to the X protocol, having been written as a X extension. SSH can
better compress the Z stream using the string matching algorithms
more efficiently as it doesn't have to flush the stream at the time
a flush is mandated by clients.

> 4) Some of the new toolkits are doing stupid things: we're talking
> with the appropriate people to get them fixed.  I won't name names right
> now, but you know who you are :-).

Sorry if I have to repeat myself, but having been working on this
since a while, I can say that this is the main reason of slowness
of X over low bandwitdth links. Things are improving day by day,
and the situation is quite satisfactory in respect to one or two years
ago (as Keith noted in a e-mail), but there is stillsome work to do.
I'd be very glad to get in contact with GNOME and KDE people to
provide some modest suggestions (not because I'm that smart,
just because I spent a significant amount of hours looking at X
statistics :-).

> 5) as expected, intern atom is a hotspot, along with fetching properties.
> There needs to be a new callback based Xlib interface to allow streaming of
> get property replies, to get rid of alot of round trips.

Currently the most popular desktop environments issue some
-thousands- of InternAtom and GetProperty requests. InternAtom
are already optimized in Xlib, and would probably be simple to
implement the same strategy for GetProperty. IMHO, anyway,
clients should use PropertyNotify events when needed instead
of asking questions all the time to the poor X server. But maybe
it's just because I miss something...

The interface for async replies in Xlib is difficult to use and,
so, nobody is using it. I suggest a simple mechanism to handle
reply notifications as events. We did this in NX and it works very
well. In practice you get a event when a reply is ready (i.e. has
been received from remote side) then client can call a function
to get the reply and its data. This is simple to handle for most
existing clients as it is trivial to plug in the usual event loop. This
mechanism was used for GetImage requests, then we got rid
of it completely when we switched to a fb at X client (agent)
side.

Of course this solves the problems only if clients have
something to do in the meanwhile. In our case, agent (that is
a client and a X server) was free to handle other clients.

>  This is
> causing havoc not only with application startup, but with things
> like drag and drop feel. Havoc Pennington coded some of this up (the
> interface not ready for prime time yet) and it is used in his metacity
> window manager, used in Gnome.
>
> 6) enough extensions get loaded, with typically at least 2 round trips
> at least to get each going, and maybe 4-5 extensions used
> by the applications (toolkits). We need an extension extension to avoid
> these round trips, (one could just kludge around with a batching call;
> but there are other shortcomings with the extension system,
> like the lack of extension versioning in the framework) that I think
> it is wise to think about a better framework).

...Like a plug-in system similar to those of Web browsers? I vote for it.

>
> 7) image transport is a real issue, whether for glyphs or other images.
> This is in part due to image sizes having grown due to greater depth
> (most people have 32 bits/pixel these days). So besides compressing
> glyphs, having the window system able to better
> take images in pretty native formats would be a serious win for alot of
> applications.

I can only agree. But I suggest a stupid idea that, nevertheless
I like very much. Why not let clients just indicate images as URLs
and let X server get them by itself (file:// or http://or xis://, where xis
is a X image server). I've been thinking at this since a long and I 
can't still see a reason why it should not work. I think that some
image/audio/video formats decoding could be built in X server. I didn't
have time to look at XMS very much, but from what I remember, it 
makes some steps in this direction.

>
> The trap to avoid here is the XIE slippery slope, and focus on image
> transport, rather than image processing.

I think that image transport could be a good start :-).

/Gian Filippo.