nanogui: make microwin api : client/server
Subject:
Re: make microwin api : client/server
From:
"Bradley D. LaRonde" ####@####.####
Date:
25 Apr 2000 18:32:30 -0000
Message-Id: <015d01bfaee3$8c8fb260$0701010a@ltc.com>
----- Original Message -----
From: Greg Haerr ####@####.####
To: Bradley D. LaRonde ####@####.#### Rob Taylor ####@####.####
nanogui ####@####.####
Sent: Tuesday, April 25, 2000 1:58 PM
Subject: Re: make microwin api : client/server
> : Thinking about your embeded device, what do you estimate the performance
> : improvement can be by using frame-buffer sharing versus a more X-like
model?
>
> When I added the shared memory support contributed by Morten and Vidar,
> the speed increased by a factor of 10, approximately. The shared memory
> support just allowed most of the data passed from client to server to
> go thru shared memory rather than a local UNIX socket.
>
> I think the client-mapped framebuffer idea of Rob's is fantastic. We've
> discussed this idea on the list before, and I plan an adding that
functionality
> to Microwindows at some time. I think the speed improvements will also
> be fantastic, especially on smaller systems that aren't sporting
super-fast
> micros. (like the 166Mhz StrongARMs, etc)
>
> Currently, Microwindows runs with the application linked with the server,
> so it's a non-issue. Nano-X apps run quite fast with the shared memory
option.
Was all that speed improvement due to shared memory, or was the Nano-X
protocol part of the problem (round-trip for everything)?
Regards,
Brad
