nanogui: make microwin api : client/server
Subject:
RE: make microwin api : client/server
From:
"Rob Taylor" ####@####.####
Date:
25 Apr 2000 11:43:58 -0000
Message-Id: <002501bfaeaa$3cecf9e0$b400a8c0@eventhorizon>
> 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
