Subject:
re: make microwin api : client/server
From:
"Rob Taylor" ####@####.####
Date:
25 Apr 2000 14:40:49 -0000
Message-Id: <002a01bfaec2$eeb08ee0$b400a8c0@eventhorizon>
> > 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 separate processes, 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 separation between the app, and the display server. A
> process barrier. 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.
ah. I'm taking the more usual embedded developers point of view of :
1) the processes are most likely going to be running on the same box
2) I have limited memory and processor, so speed + mem efficiency are very
important - biggest cost factor is processor speed. and is often a limiting
factor (e.g. on portable products)
3) process integrity is important (keep process mutual failure nodes to a
small kernel)
I acknowledge that we're coming at this from different, but equally valid
angles. Please keep
this in mind.
With this in mind, what's the commonality?
I was originally thinking of this for nano-X (as this is the layer I'm most
familiar with).
I pictured there being a switchable middle layer that would allow the
developer to choose (say) pipe/socket based comms, shared memory + pipe (a
la X), and shared framebuffer
Now this is still possible in Microwidows, but there s the complication that
in most Win 32 API calls you pass in local memory references , which win32
deals with by having the graphics calls specially authorised to map other
processes memory for w/r access.
so you would need one backend that marshalled augments and did rpc, and
another that didn't.
sounds fair enough to me.
coming back to:
> 1) Have a separation between the app, and the display server. A
> process barrier. 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.
I don't understand how you see this being the case:
The only point where all applications access a single shared area is the
framebuffer/screen, and if corruption happens here, only the screen display
is corrupted, not process stability. If a process corrupts their shared
memory region description, it is only they that suffer (assuming that the
window manager is robust enough to cope with corrupt structures in this
region - which is the same assumption as assuming an X-style graphics server
can cope with all permutations of input to a given function).
Please let me know if you can see any flaws in this reasoning.
coming back to:
> 2) I want remote access to the microwin API. Not via VNC, but
> natively.
do you? why?
If you don't mind me saying, don't you actually want the ability to run a
process on a different box to its graphics display?
if you answered yes to the above, have a look at
ftp://ftp.uk.research.att.com/pub/docs/att/tr.98.1.pdf
now one of the reasons that X is slow is because it was designed to do this.
this is one of it's limitations. if you want to give microwindows the same
functionality, you're going to end up giving it the same problems of X,
> 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.
this is a real lot of overhead to add just for drawing a rectangle..
Can I suggest an experiment to you: get an application that funs on Windows
and X (anything in fltk should do) that has a high refresh rate for a
component. run it in Windows and watch the processor usage, and run it on X
and watch the processor usage. This should give you an idea about why I
think this is important.
Rob
