[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |