nanogui: make microwin api : client/server
Subject:
Re: make microwin api : client/server
From:
"Rob Taylor" ####@####.####
Date:
27 Apr 2000 09:41:02 -0000
Message-Id: <000401bfb02b$71a90d90$b400a8c0@eventhorizon>
> I don't want Palm OS, and I don't want Windows 3.11. Surely everyone
> could undertand why. In the same breath... I don't want X. Something
> in between, something standard based, and something simple. If
> someone had experience with other graphics display engines, they
> should be able to read a PDF for a day, and get the hang of what we're
> doing. I don't think that's feasable now..., but how could it be made
> that way? You can't have an application copying to the framebuffer...
> that's insane. Where's the seperation between server and app? I
> think the program should be able to say, put these bits on the screen,
> and pass a reference to a iovec or something like that. But not the
> application itself put the bits on the screen. Just say: put this on
> the screen, and a reference to some data (pointer), then the API would
> say... do we have SMT, okay good... let me copy this stuff over and
> notify the engine that it's supposed to put this on the framebuffer
> at these "relative" cooridinates to our window. Oh, no SMT?, okay let
> me contact the socket and write them synchronously, or asynchronously.
if that's what you want, I suggest you look at berlin
(www.berlin-consortium.org) - it fits your bill almost exactly. What you're
describing isn't really a good idea for most embedded systems as the cpu
overhead is pretty steep, it is however applicable to high-end embedded
systems, and berlin is the most suitable here.
Rob
