Subject:
Re: make microwin api : client/server
From:
####@####.####
Date:
25 Apr 2000 13:30:11 -0000
Message-Id: <20000425061901.B4873@www.easysolutions.net>
> well if only one app can grb the framebuffer, then you simply have
> synchonisation and apps only grabbing it while they draw (or even better:
> just fix the framebuffer device so it isn't so brain-dead, if this is the
> case) I can understand your objects on the process safty side of thing, but
> it *Really* isn;t that bad, the only true shared resource id the screen
> frambuffer, the data structs describing application regionbs are only shared
> between the client and the sever (and hence are exacly the same, in processs
> security terms, as the pipe/shared mem stuff that some X servers do).
> The speed increases to be gained from doing client-side drawing are not tobe
> underestimated: think
>
> 1 write versus
>
> marshal argument (copy) to shared mem, pipe transaction, copy/unmarshal from
> shared mem, interpet call, write
>
>
> of course major downsides exist on the remote client front, but then again,
> you could make a really efficent vnc framebuffer...
Remote clients would be tragically slow probably. I'm not sure where
we're going with this..., the main idea is we want to be able to run
more than one program simultaneously in seperate proccesses, no? Or
you don't want that, but maybe that's what I want :-). Your focus is
speed, mines stability of the app, and a set of abilities. I want to
be able to do a few things:
1) Have a seperation between the app, and the display server. A
proccess barier. Otherwise we're putting to much constraint on the
app writer. If his app has one flaw, the entire app falls to
pieces... I think this is a really big issue.
2) I want remote access to the microwin API. Not via VNC, but
natively.
3) I want this to be fast.
In that order.
>
> nonononono! this is just how an accellerated X server works, and that still
> has the major problem that you need to marshall/unmarshall the api calls and
> serialize huge blocks of information (think about blatting a bitmap
> around??) and a CORBA solution would be simply the same thing under a
> different name..
That's true, it is the same thing under a different name. Except it's
standard, and we don't have to write it :-). omniORB is really really
fast. It's too big for this project, but when I can see responses on
the order of a 200 microseconds... I'm happy. If we can get/write
something with that sort of speed that is just smaller..., we're good
to go. We just write the client side API as a front end to our ORB,
and build the ORB into microwin... that way we can get a request,
respond to it, and write it directly to the framebuffer. We will have
to marshal, but is 200 microseconds to long for a basical marshall job
on a small packet? (characters, 100 of them) Of course we'd be
sending larger packets..., so this might raise issues..., but anyway
I'd just like to throw my idea into the ring. I'm very concerned
with the idea you propose in terms of stability. In terms of speed
clearly it would be superior..., but is that the focus? If that were
the focus would we be using a framebuffer? We'd probably be writing
in assembler to talk right to the on board graphics chip if we really
wanted speed only.
Thanks,
Shane.
By the way... I'm not really criticizing your idea. I think our
focuses are just different.
