[interfacekit] Re: BHandler::fToken
- From: "Marc Flerackers" <mflerackers@xxxxxxxxxx>
- To: <interfacekit@xxxxxxxxxxxxx>
- Date: Tue, 11 Mar 2003 11:24:59 +0100
> > > I've proposed to DarkWyrm to use as a server token a BView pointer,
> > > for a faster retrieval of the BView that's gonna receive the message.
> >
> > I suppose you mean a ServerView(or Layer) pointer?
>
> NO! I mean a BView pointer( more exactly, the address)!
> Look down, and you'll find the reason.
So you want to use as server_token on the app_server the pointer of the
local BView.
> Here is a detailed method that I propose for server tokens representation.
> (especially BView tokens, because I think BWindow tokens need to be
> uniquely identified in app_server)
>
> Why am I proposing this? First, because, it's an alternative to
> BView::server_token :-). Second, and here we're done with jokes,
> for SPEED.
> This method, is really fast.
>
> App_server messages concerning BViews are very numerous! For every
> message that's meant for a BView, I have to make a search through the
> BViews tree. That is really expensive, and there is NO better
> algorithm for
> searching a specified BView!!!
Actually, the BMessages sent from the app_sever enter the queue, and are
handled like all other messages. From the messages that are dispatched by
the window directly I don't really see a problem with finding the
destination.
-Key messages: except for some exceptions, they go to the focus view, which
pointer is kept in BWindow::fFocus. They can also go to the default button,
which is kept in BWindow::fDefaultButton. If a command key is down, you find
the possible target in BWindow::accellist. View navigation is handled in
BWindow itself.
-Mouse messages: if a view grabbed the pointer, it's sent to this one.
Otherwise a quick search through the view tree using the coordinates does
the trick.
> Because of that, I suggested, that, at least in BView's case, we use as a
> server token its pointer. That means that in case of BView-Layer
> association
> we should generate server tokens client-side!
The problem I see with this is that server_tokens are used on the
server_side, they never come back to the BView. They are used in the port
communication only, and not in the message loop. in the message loop you
only have messages sent to the BWindow, which either have a handler token,
or are meant for the BWindow itself, which then searches the target and
dispatches the messages.
> That way, when we receive a message that contains a server token, we,
> actually do a cast to BView*, witch is MUCH FASTER, and immediately call
> the BView's function we need!
I find it quite dangerous to just cast something and call functions, without
doing any checking on it. When a view gets destroyed, there can still be
messages for it in the queue for example. I also don't see why there would
be so much overhead. Even if you would do a FindView(where) call every time
you get a B_MOUSE_MOVED message, since the amount of checks in the view tree
is at most the depth of the tree. I think reading the parameters from the
BMessage takes more time then the searching.
> If we do it like that, every ServerWindow object should have a hash table,
> with the key being BView's pointer, and Layer's pointer as the associated
> object. Ingo said that memory overhead for maintaining a hash table per
> window would be big compared with a single one for app_server. I totally
> disagree. The memory overhead will be the same. Either we have a big
> has table maintained for all ServerWindows or we have a lot of small hash
> tables for every ServerWindow, the memory overhead will be the same.
A hash table uses a bit more memory then the data it contains.
> PLUS, this is where we AGAIN gain some time(I might say - A LOT),
> because we only need to search through a relatively small(!) hash, not the
> entire list of Layers that exists on the app_server!
A hash table is usually used to search fast through a relatively large list
in O(1) time. If you have a hash table for each window I think the hash
table is more of an overhead than a speed-up.
> When adding a BView as a child of a BWindow, we actually attach the
> pointer in the creation message. When ServerWindow receives this message
> it creates a Layer, then adds an entry in the (local)hash table
> with BView's
> pointer being the key, and Layer's pointer being the associated object.
> When we detach the BView, we will send a message to ServerWindow
> with BView's server token attached, it will search the hash, find the
> correct entry, get Layer's pointer(AGAIN, gaining some speed(!),
> by avoiding a search in ServerWindow's list of Layers, where, again, no
> optimization is possible!), and use it do delete(after other calls have
> been made) that object.
But the only place where you would ever need optimization are B_MOUSE_MOVED
messages, and the target can be found quite easy, since you have a tree with
the right properties to search through. Or am I overlooking another
frequently sent message?
> So, you see... there are 3(!!!) places where we gain significant speed!!!
>
> I'm sure that I've missed something, but in high lines, this is
> how I would
> like to see the server tokening working.
As I understand it, the BMessage sent from the app_server would contain the
BView pointer, so you can call (token)->hook() directly. I really think the
overhead gained would be negligible, compared with the danger to stability.
Marc Flerackers (mflerackers@xxxxxxxxxx)
Software Engineer
Other related posts:
