nanogui: make microwin api : client/server


Previous by date: 25 Apr 2000 14:06:11 -0000 Re: make microwin api : client/server, shane.isupportlive.com
Next by date: 25 Apr 2000 14:06:11 -0000 Re: make microwin api : client/server, Rob Taylor
Previous in thread: 25 Apr 2000 14:06:11 -0000 Re: make microwin api : client/server, shane.isupportlive.com
Next in thread: 25 Apr 2000 14:06:11 -0000 Re: make microwin api : client/server, Rob Taylor

Subject: Re: make microwin api : client/server
From: Jim Buzbee ####@####.####
Date: 25 Apr 2000 14:06:11 -0000
Message-Id: <3905A3F8.F3DB38E6@echostar.com>

Rob Taylor wrote:

...

> >
> well, depends what sort of shared memory usage tyou mean... some X servers
> support shared memoey usage  in the sens that the client can buffer a whole
> load of X evemnts/requests in a shared memory area and only XSync/Xflush
> cause an actual pipe tansaction, which signals the Xserver to pull
> everything off the shared area and execute it.
> (note: I don't think XFree86 can do this, but i belive HP's can.)
> 
> Anyway I think, although this is better than normal pipe transactions, I
> don't think it's the best option: you still need to marshal/unmarshal
> argumnets, which sucks.  My suggestion is that the client actually does it's
> own drawing to the framebuffer, and the server processes simply deals with
> telling the client what screen regions it has use of (window
> management)(obviously with the relevent information stored in a shared
> memory buffer) and top-level event routing.
> 
> What do people think?
> 

The following is from the XFree86 mailing list where this subject was
discussed a bit.  Read the quoted paper, but the final analysis seems to
indicate that on "modern hardware" doing the shared memory trick isn't
worth the effort. Of course many people using nano-gui won't be on
"modern hardware"...

Jim


------------
 
Rik Faith writes :


> 
> I have completed an initial exploration of Shared Memory Transport and have 
> written up a description of the implementation and the performance issues
> involved.  Here is the abstract of the paper:
> 
>   Shared Memory Transport (SMT) is a mechanism for using shared memory
>   to communicate X protocol information between the client application
>   and the X server.  This paper reviews existing SMT implementations,
>   defines design criteria for SMT in XFree86, outlines a staged imple-
>   mentation of SMT for XFree86, and analyzes the performance of this
>   implementation.  On workstations, SMT has historically provided a sig-
>   nificant improvement in performance.  However, on modern workstations
>   and on modern PC-class hardware, SMT improves overall performance by
>   less than 10%.  On modern hardware, the performance of the host CPU
>   (including the X server and operating system implementations) is well-
>   matched to the performance of the graphics hardware.  Because of this,
>   the performance of the typical X operation is almost completely lim-
>   ited by the performance of the graphics hardware, and the improvement
>   in transport speed provided by SMT cannot provide large gains in ren-
>   dering performance.  Because of these observations, I do not recommend
>   devoting more engineering time to the active improvement of the cur-
>   rent SMT implementation for XFree86.
> 
> 
> The fully paper is available in several formats:
> 
>     http://precisioninsight.com/smt/smt.html
>     http://precisioninsight.com/smt/smt.txt
>     http://precisioninsight.com/smt/smt.ps
> 


----------------------------------------------------------------------------------------------

Previous by date: 25 Apr 2000 14:06:11 -0000 Re: make microwin api : client/server, shane.isupportlive.com
Next by date: 25 Apr 2000 14:06:11 -0000 Re: make microwin api : client/server, Rob Taylor
Previous in thread: 25 Apr 2000 14:06:11 -0000 Re: make microwin api : client/server, shane.isupportlive.com
Next in thread: 25 Apr 2000 14:06:11 -0000 Re: make microwin api : client/server, Rob Taylor


Powered by ezmlm-browse 0.20.