Re: [Xouvert-general] Network transparentcy and modules

[Jerry Westrick]

Not that I'm knowledgeable in this area or anything like that, but...

I've heard of an X-Extension, module, or something, that was written
for low bandwidth connections, and considerable reduced the amount of
trafic...

This sounds like an interesting topic, for this
discussion,unfortunatetly I cannot provide more information.

Another insteresting topic for dicusion would be looking into better
support for VNC, which is what most people use instead of a remote
X-Server.

Sorry, for jumping in, but....
I just couldn't help my self!

Jerry Westrick



On Tue, 2003-08-19 at 11:55, James Best wrote:
> Jonathan Walther wrote:
> 
> > On Tue, Aug 19, 2003 at 01:05:45AM +0000, Mark C. Ballew wrote:
> >
> >>> We *cannot* remove network transparency. Period. There is absolutely 
> >>> no question about it whatsoever. X11 *is* a _network_ protocol.
> >>> I think the reason everyone thinks its slow, is because everyone 
> >>> thinks that X11 on a local machine goes thru tcp/ip. It doesnt. It 
> >>> uses UNIX sockets which are very fast.
> >>
> >>
> >> Oh no, this totally isn't what I'm getting at. I was suggesting that the
> >> network transparency be even more transparent, by allowing different
> >> network protocols to be plugged in. I know to an extent this already
> >> exists, but I don't know if it is hard coded in or easily to modify.
> >
> >
> > Next time check the code first.  Adding in new transports is relatively
> > easy; the actual transport specific code is small.  As someone else on
> > the list said, the code to support X over DECNET is only 6k.
> >
> > Jonathan
> 
> Adding transports looks to be easy - but what about the protocol?  I 
> believe he said about "network protocols".  I, too, am curious about 
> this.  I understand that X is the protocol, and without it it wouldn't 
> be X.  I have looked at the protocol, though, and it is far from the 
> most efficient I have seen.
> 
> Although Unix pipes are quite fast, cutting the data sent over them in 
> half could have a substantial impact on the speed of the system.  As 
> clients build layer upon layer of gui abstraction, the X transport is 
> sending more and more little messages, and they add up.  There my be 
> better, faster encodings that can be developed.
> 
> On a different note, I don't think that X's sluggish response is from 
> the protocol or the network.  From my measurements and experience, it's 
> from task switching.  When I click on a button on the application, X 
> gets the event, sends it to the client.  The client does something with 
> it, and usually responds with some kind of redraw of the widget to 
> indicate the button was pressed.  Then, the user releases the button, 
> causing another event, another draw, and a number of other actions.  
> This communication causes the computer to switch tasks many times for 
> even the most basic button click.  At this point, other than kernel 
> tuning, I don't know how to reduce this.  This is where I am most 
> curious to help.
> 
> Jamie
> 
> 
> 
> _______________________________________________
> Xouvert-general mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/xouvert-general
>