nanogui: Re: [linuxce-devel] Re: Microwindows/Nano-X version 0.87pre1 rele ased


Previous by date: 2 Dec 1999 17:04:06 -0000 FreeDOS, Imre Lebr
Next by date: 2 Dec 1999 17:04:06 -0000 Re: [linuxce-devel] Re: Microwindows/Nano-X version 0.87pre1 rele, Alan Cox
Previous in thread:
Next in thread:

Subject: RE: [linuxce-devel] Re: Microwindows/Nano-X version 0.87pre1 rele ased
From: Greg Haerr ####@####.####
Date: 2 Dec 1999 17:04:06 -0000
Message-Id: <796896539E6CD311B0E70060083DFEFB076E3C@NBA-SLAM.CenSoft.COM>

On Thursday, December 02, 1999 6:24 AM, Alan Cox  wrote:
: > at extremely high speed.  Unlike the Xlib implementation, Nano-X still
runs
: > synchronously per client, meaning that once a client request packet is
sent,
: > the server waits until the whole packet has arrived until servicing
another
: > client.
: > This keeps the server code immensely simpler, while still running very
quickly.
: 
: That kills you on a network or a client hang at the wrong moment.

Yep.  No question about that.  I considered holding the release until I had
that
working, but wanted to get it out, so that users could say that it was fast
enough.


 Reblocking
: the data isnt hard but it can be sorted later.

Yeah, I'll add the algorithm.  The tricky part is that once you do partial
reads,
that means that there's the possibility of deadlock if the network buffers
become full.  That means that you have to do delayed write scheduling as
well,
something else that I haven't implemented to keep it small and simple.

 The big thing with reblocking
: in nanogui will be keeping the max command length low to avoid large
buffers

Now this is perhaps the biggest problem area.  Nano-X unfortunately uses
the X-like CopyArea, Area, and ReadArea primitives to transfer pixel
data from client to server.  On a truecolor display at 32bpp, these
transfers
can get very large, very quick.  The ReadArea call requires a large malloc
on the client, as well.  Currently, I have it designed so that we _could_
handle
a 24 bit malloc (I know, huge) in the case that everything is running
on Linux for speed.  One trick, used by Xlib, is to split any Copy/Read/Area
large rectangle into smaller rectangles and make smaller requests for
each.  Perhaps we should go that route.  How big should nanogui think
a large buffer is?  Whatever is sent by the server handshake?

Greg




Previous by date: 2 Dec 1999 17:04:06 -0000 FreeDOS, Imre Lebr
Next by date: 2 Dec 1999 17:04:06 -0000 Re: [linuxce-devel] Re: Microwindows/Nano-X version 0.87pre1 rele, Alan Cox
Previous in thread:
Next in thread:


Powered by ezmlm-browse 0.20.