[interfacekit] Re: BHandler::fToken
- From: "Adi Oanca" <e2joseph@xxxxxxxxxx>
- To: <interfacekit@xxxxxxxxxxxxx>
- Date: Tue, 11 Mar 2003 20:04:09 +0200
> > 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
No, BMessages created by BWindow from app_server 'simple' messages
> 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.
Yes, and that I'm trying to avoid! Having a pointer to that view eliminates
the search?!
> > 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.
Server tokens and handler tokens have NOTHING to do one with each other!
Handler tokens are handled by BLooper when it gets a BMessage through it's
port; Server tokens are handled by BWindow! They are attached to a message
that BWindow receives form it's server counterpart, ServerWindow. Note that
these messages do not came through BLooper's port, they came through a port
that BWindow opens in it's constructor! Then, they are readed in the
virtual private function task_looper() (BWindow's version listens to 2
ports),
dispatched to BWindow::ConvertToMessage() who will create
a BMessage then call BWindow::DispatchMessage().
> > 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 don't think that is going to happen! Possible, but I'll assure you I will
eliminate
that possibility! I'll have to see how!
> 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.
I don't need to read any parameter from any BMessage! Remember! BWindow
creates a BMessage for a specified BView, and, I already know the
token(address) (ServerWindow gave it to me!)
>
> > 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.
A little bit...
>
> > 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.
You must be kidding. It's complexity is O(n).
> If you have a hash table for each window I think the hash
> table is more of an overhead than a speed-up.
Excuse me??? where is the extra overhead???
>
> > 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?
No, here you are right! Let me remind you that ServerWindow, also does a
search through its tree of Layers, before sending a message to a BWindow.
Now why would we do that twice? It is later, after we complete R1, that we
will try to optimize our code, why not doing it now, when we already have a
method?
> 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.
The only place where we could have a dangerous situation is if we still have
a message in the queue who's token would be of a deleted BView! I'll try to
resolve that situation!
Other related posts:
