nanogui: make microwin api : client/server
Subject:
Re: make microwin api : client/server
From:
####@####.####
Date:
26 Apr 2000 08:24:03 -0000
Message-Id: <20000426081436.26271.qmail@www.nameplanet.com>
On Tue, 25 Apr 2000 07:56:08 -0600 Jim Buzbee ####@####.#### wrote:
>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"...
What's rather ridiculous about the message you quoted is that it basically
says that "who cares how much CPU we use, as long as it's the graphics
chip that is the bottleneck". But that assumes that the CPU will be idle
when it's not servicing the GUI. Sure, it may not have a great impact for
XFree86 when you don't do anything else with the machine, but reducing
the amount of memory accesses etc. will have a lot to say once you start
actually doing some real work with your CPU.
That's important to realise since it's so much more critical for embedded
systems likely to use Nano-X, where CPU power is a very real cost issue.
Also, notice that SMT is a more radical approach than the currenct XFree86
system. Most X applications actively used the shared memory extensions of
X for most/all pixmap data already, so for XFree86 SMT will only have an
effect for other protocol requests, while the patch Morten did for Nano-X
affects everything. There are more shared memory tricks that Nano-X could
benefit greatly from, though, including support for allocating shared-memory
off screen pixmaps (would be a great improvement for many applications doing
double buffering for instance), so SMT to the extent suggested for XFree86
is rather far down the list of what it's worth spending any time on.
Regards,
Vidar Hokstad
NamePlanet.com Ltd.
--
Get your firstname@lastname email for FREE at http://NamePlanet.com
