nanogui: Thread: make microwin api : client/server

question: make microwin api : client/server
is there any "official" project to make microwin api : client/server
thx in advanced!:)

I plan on adding module-loading capabilities to the microwin
api, which will allow multiple "applications" to use that API.

Creating a full-blown client/server architecture involves LOTS
of typing, unless we use a MIDL-like compiler that generates
the client and server stub marshalling for us.  This is required
because win32 uses pointers in the API, unlike ID's in Nano-X.

Regards,

Greg

  ----- Original Message ----- 
  From: 曾昭明 
  To: ####@####.#### 
  Sent: Tuesday, April 11, 2000 11:38 PM
  Subject: make microwin api : client/server


  question: make microwin api : client/server
  is there any "official" project to make microwin api : client/server
  thx in advanced!:)

Well,..., I'm a little concerned about not having that process
seperation between the server and the actual app.  In fact quite
concerned.  You're right... it would be a LOT of work, but isn't it
worth it?  Well, maybe we're not ready for it.  But I'm a little
skeptical at putting a lot of time/effort into the "module" loading
when it's not going to be the final solution.  Shared memory pages
would be awesome..., but the MSDOS folk might not be able to use this.
Write the Client side stuff as just sharedmemory page manipulation,
and the Microwin server would just pull up changes from that.  Could
anyone confirm as to whether X works like this when run "locally"?
That's what I thought, but could be totally wrong.  Oh, yes and when
not in local mode it would function through some sort of network
interface thingee.

We want X functionality..., but we don't want to be X... this is the
enigma.

Thanks,
Shane.

On Thu, Apr 13, 2000 at 04:52:34PM -0600, Greg Haerr wrote:
> I plan on adding module-loading capabilities to the microwin
> api, which will allow multiple "applications" to use that API.
> 
> Creating a full-blown client/server architecture involves LOTS
> of typing, unless we use a MIDL-like compiler that generates
> the client and server stub marshalling for us.  This is required
> because win32 uses pointers in the API, unlike ID's in Nano-X.
> 
> Regards,
> 
> Greg
> 
>   ----- Original Message ----- 
>   From: ´¿¬L©ú 
>   To: ####@####.#### 
>   Sent: Tuesday, April 11, 2000 11:38 PM
>   Subject: make microwin api : client/server
> 
> 
>   question: make microwin api : client/server
>   is there any "official" project to make microwin api : client/server
>   thx in advanced!:)
> 

> Write the Client side stuff as just sharedmemory page manipulation,
> and the Microwin server would just pull up changes from that.  Could
> anyone confirm as to whether X works like this when run "locally"?
> That's what I thought, but could be totally wrong.  Oh, yes and when
> not in local mode it would function through some sort of network
> interface thingee.
>
well, depends what sort of shared memory usage tyou mean... some X servers
support shared memoey usage  in the sens that the client can buffer a whole
load of X evemnts/requests in a shared memory area and only XSync/Xflush
cause an actual pipe tansaction, which signals the Xserver to pull
everything off the shared area and execute it.
(note: I don't think XFree86 can do this, but i belive HP's can.)

Anyway I think, although this is better than normal pipe transactions, I
don't think it's the best option: you still need to marshal/unmarshal
argumnets, which sucks.  My suggestion is that the client actually does it's
own drawing to the framebuffer, and the server processes simply deals with
telling the client what screen regions it has use of (window
management)(obviously with the relevent information stored in a shared
memory buffer) and top-level event routing.

What do people think?

Rob

> Anyway I think, although this is better than normal pipe transactions, I
> don't think it's the best option: you still need to marshal/unmarshal
> argumnets, which sucks.  My suggestion is that the client actually does it's
> own drawing to the framebuffer, and the server processes simply deals with
> telling the client what screen regions it has use of (window
> management)(obviously with the relevent information stored in a shared
> memory buffer) and top-level event routing.
> 
> What do people think?
> 
> Rob

Hmm..., well..., can't only one program "own" the framebuffer at a
time?  I don't know if we could segment this memory between the
various apps.  I think this could be riddled with problems..., it
needs to be abstracted into a set of functions which manipulate the
memory at the server level I think.  Using shared memory segments you
could for instance stick a series of bits and directly memcpy it onto
the framebuffer into the right place.... from the server side.  Maybe
I'm wrong, but I'm pretty sure only one central app can control the
framebuffer memory.  One potential would be to have sort of a virtual
framebuffer that apps could write that would be a shared memory page
that the server could copy to the screen.  However can you hear the
slurping sound?..., yes it's your memory getting sucked up. :-).

The "best way" that I see is just to abstract the whole API.  Take the
whole NanoGUI/microwin API, and let "client" apps say to the server,
perform this function on my window.  Then the microwin engine says,
your windows not visible... never mind that.  Only "servicing" visible
windows requests for changes.  How those function calls get into the
main server app could be anything..., shmget's, et. al for local
clients, or read off a socket..., doesn't matter that much.

Of course... that's a ton of work.  Seriously... a ton.

The key piece is process seperation between the server and the clients
that do the actual work.  This allows more than one app to run
simultaneously... a serious short coming in our present setup.  This
is present in the NanoGUI api at some level, but not Microwin.  (I
mean to say the shortcoming is fully present in Microwin, but only
partially in NanoGUI)

Hmm..., this might seem a little off, but what if we were to see if
there were some really tiny CORBA/COM implementations lying around.
The server process could grab data chunks via the object request
broker, and implement them.  The clients could transmit their requests
for changes to the screen to the ORB, and all would be well.  This
smacks of bloat though, and that concerns me.  Your right though
marshalling is non trivial.  But if we leverage what someone else has
done well into our well designed setup... it could be cool.  I think
in the future most modern GUI toolkits will be written like this...,
why not right the display server like this itself?  (Bonobo comes to
mind)

Oh well... just a crazy idea to start your morning right.

Thanks,
Shane.

> Hmm..., well..., can't only one program "own" the framebuffer at a
> time?  I don't know if we could segment this memory between the
> various apps.  I think this could be riddled with problems..., it
> needs to be abstracted into a set of functions which manipulate the
> memory at the server level I think.  Using shared memory segments you
> could for instance stick a series of bits and directly memcpy it onto
> the framebuffer into the right place.... from the server side.  Maybe
> I'm wrong, but I'm pretty sure only one central app can control the
> framebuffer memory.  One potential would be to have sort of a virtual
> framebuffer that apps could write that would be a shared memory page
> that the server could copy to the screen.

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...



> The "best way" that I see is just to abstract the whole API.  Take the
> whole NanoGUI/microwin API, and let "client" apps say to the server,
> perform this function on my window.  Then the microwin engine says,
> your windows not visible... never mind that.  Only "servicing" visible
> windows requests for changes.  How those function calls get into the
> main server app could be anything..., shmget's, et. al for local
> clients, or read off a socket..., doesn't matter that much.
>

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..

Rob

> 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.

Rob Taylor wrote:

...

> >
> well, depends what sort of shared memory usage tyou mean... some X servers
> support shared memoey usage  in the sens that the client can buffer a whole
> load of X evemnts/requests in a shared memory area and only XSync/Xflush
> cause an actual pipe tansaction, which signals the Xserver to pull
> everything off the shared area and execute it.
> (note: I don't think XFree86 can do this, but i belive HP's can.)
> 
> Anyway I think, although this is better than normal pipe transactions, I
> don't think it's the best option: you still need to marshal/unmarshal
> argumnets, which sucks.  My suggestion is that the client actually does it's
> own drawing to the framebuffer, and the server processes simply deals with
> telling the client what screen regions it has use of (window
> management)(obviously with the relevent information stored in a shared
> memory buffer) and top-level event routing.
> 
> What do people think?
> 

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"...

Jim


------------
 
Rik Faith writes :


> 
> I have completed an initial exploration of Shared Memory Transport and have 
> written up a description of the implementation and the performance issues
> involved.  Here is the abstract of the paper:
> 
>   Shared Memory Transport (SMT) is a mechanism for using shared memory
>   to communicate X protocol information between the client application
>   and the X server.  This paper reviews existing SMT implementations,
>   defines design criteria for SMT in XFree86, outlines a staged imple-
>   mentation of SMT for XFree86, and analyzes the performance of this
>   implementation.  On workstations, SMT has historically provided a sig-
>   nificant improvement in performance.  However, on modern workstations
>   and on modern PC-class hardware, SMT improves overall performance by
>   less than 10%.  On modern hardware, the performance of the host CPU
>   (including the X server and operating system implementations) is well-
>   matched to the performance of the graphics hardware.  Because of this,
>   the performance of the typical X operation is almost completely lim-
>   ited by the performance of the graphics hardware, and the improvement
>   in transport speed provided by SMT cannot provide large gains in ren-
>   dering performance.  Because of these observations, I do not recommend
>   devoting more engineering time to the active improvement of the cur-
>   rent SMT implementation for XFree86.
> 
> 
> The fully paper is available in several formats:
> 
>     http://precisioninsight.com/smt/smt.html
>     http://precisioninsight.com/smt/smt.txt
>     http://precisioninsight.com/smt/smt.ps
> 


----------------------------------------------------------------------------------------------

> > 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

>
> 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 ;-)

Rob