nanogui: make microwin api : client/server
Subject:
Re: make microwin api : client/server
From:
"Bradley D. LaRonde" ####@####.####
Date:
25 Apr 2000 15:01:22 -0000
Message-Id: <007701bfaec6$0de6cb50$0701010a@ltc.com>
----- Original Message -----
From: Rob Taylor ####@####.####
To: nanogui ####@####.####
Sent: Tuesday, April 25, 2000 10:39 AM
Subject: RE: make microwin api : client/server
>
> >
> > 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"...
> >
>
> actualy this is refereing to the type of shared memory use that nano-X
> aready does (and some other X servers do).. and the effectiveness is
pretty
> dependent on the size of your L2 cache - the larger the cache the less use
> SMT is. so yeah, I'm sure in this sense most embedded developers aren't
> using 'modern hardware'. (I know I'm not!)
>
> this is quite different to the direct frambuffer acesses model I'm
> proposing. (just incase anyone is confused already ;-)
The X model isn't so bad. I'm using X on an embedded device (66MHz MIPS,
8k/16k cache, 16MB RAM, 16MB ROM), and the performance is admirable, even
excellent.
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?
Regards,
Brad
