[interfacekit] Re: PortThief

DarkWyrm wrote:
> 
> >Why?  We control app_server *and* the IK/App kits -- the protocol is
> >whatever we choose to make it!  We're no longer operating under the
> Oh, DUH! <smacks forehead> I forgot that we're not just dropping in the
> app_server, but *also* libbe.so  and the input server. In a perfect world,
> we'd be able to drop in any one of those three and have things work the same
> way. Reversing the protocol will take a lot of time, so I'll probably be
> asking you guys about what you think the protocol should be as I get working
> on it.

In a perfect world, yes.  It became apparent to me pretty quickly that
"perfect world" just isn't worth the effort, so please don't bother
reverse engineering the protocol.

> If I didn't make myself very clear, the BView actually owns the bitmap (I
> think), but the app_server does all the rendering. I know I didn't word
> things very well - I had a long day yesterday, so my English degraded into my
> native tongue, Gibberish. ;)

The server-side of BView, yes?  So the idea would be that the view
scribbles on its own bitmap, and the app_server blits an appropriately
clipped portion of that bitmap, right?  Sounds like one way to do it,
however I'm concerned about the amount of memory needed to maintain
bitmaps for every single view, not to mention possible speed issues. 
The question is whether executing clipped drawing commands straight to
the framebuffer would be faster.  Could be useful for prototyping,
though.  I think the thing to do is abstract the actual drawing
mechanism; keep it as isolated as possible so that the rest of
app_server is protected from our attempts to optimise drawing.

> >While I agree that knowing the full app_server protocol would be
> >helpful, I think the time necessary to decode it will be much better
> >spent designing and implementing it ourselves.  I think the basic
> >question is this:  what elements does the protocol consist of?  These
> >things certainly:
> >
> >* Registering and unregistering the application with the
> >app_server/roster.
> >* Registering and unregistering each window with the app_server
> >* Communicating drawing commands to the app_server
> >* Sending updated window & view information to the server-side windows
> >* Retrieving window & view information from the server-side windows
> >(only a few things are cached on the client side)
> >* Retrieving system/roster information from the app_server
> >
> >I don't think there's much else, is there?  If there is, surely we'll
> >figure it out as our technical specs get fleshed out, no?
> It's definitely a start, if not complete. While I'm thinking of it, which do
> you think would be more efficient, using read/write port or BMessages?

Read/write port is going to be *much* faster.  BMessage is very handy,
but a lot of overhead comes along for the ride.  We'll be wanting to do
something more like (look out!  It's pseudo-code!):

port << OUR_DRAW_LINE_OPCODE << start_x << start_y << end_x << end_y;
port.flush();

I.e., we shove data straight into the port buffer and flush.  Not to say
we shouldn't abstract the port into a nice, tidy object. =)

e

Other related posts: