[interfacekit] Re: Re: :) B_MOUSE_MOVED

>Well, adding 4 bytes does not affect performance at all.
>
>But please have a look at the modifiers() function.
>The disassembly clearly shows that is constructs a BMessage,
>askes the input server using <=5Fcontrol=5Finput=5Fserver=5F=5F=
>5FFP8BMessageT0>
>where a BMessenger is constructed, etc.
>This is huge overhead when moving the mouse.
>
>Marcus
I agree that adding the extra 4 bytes has a measurable (but humanly 
imperceptible) impact, and I also think that the impact it would have 
comparied to calling modifiers() is significant, BUT I am not so sure it is 
necessary for a number of reasons.

Think about it - what purpose might there be if a user were going to move the 
mouse with the shift key down? While I'm a bit limited in my thinking, I 
can't really think of a reason to, say, attach some sort of functionality to 
a user moving the mouse while holding down the shift key, for example - even 
while dragging. Generally, modifier keys are used for for clicking, not 
dragging and otherwise moving the mouse.

Likewise, it is currently possible to track the modifiers without calling 
modifiers() or getting it from the message - cache it as a class member and 
handle B_MODIFIERS_CHANGED in MessageReceived() to modify the cached copy. 
This could be done for any class which really needs to track the modifier 
states.

Lastly, a *very* good reason not to do it is to avoid feature creep. Michael, 
on numerous occasions, has mentioned that new features are for R2. Axel is 
right in saying that some developers might use it and we wouldn't be able to 
remove it if, for some reason, we discovered that it had been a Bad Thing 
(tm).

It would be a trifle for me to add it to the server code to support this even 
without the support of the Input Server team, but I do not believe it is wise 
to do so. Sometimes the easy thing to do is not the right thing to do.

--DW

Other related posts: