nanogui: make microwin api : client/server
Subject:
Re: make microwin api : client/server
From:
####@####.####
Date:
27 Apr 2000 07:52:51 -0000
Message-Id: <20000427004137.R955@www.easysolutions.net>
> 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.
From my perspective... I could care less how the bits are transfered. SMT,
socket, etc. What I care about is that the API is 1) Networkable 2)
Forward looking. Let's not make Windows 3.11. That's my only point.
CORBA, or an ORB setup does NOT have to use sockets. In fact...,
locally, it shouldn't.
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.
Okay, so maybe they're in threads... I could deal with that, that would
cut one more thing out of the loop. I'd prefer seperate processes,
but hey? whatever. It would be a bit faster. (Well, quite a bit)
Just what I think...
Thanks,
Shane.
