B_NO_POINTER_HISTORY has no effect

[tangobravo]

BeOS R5 has a flag that Views can set - B_NO_POINTER_HISTORY - useful for when MouseMoved hooks take a lot of processing and can't keep up with the speed of new mouse messages.

One example of where this is used is in the column view of Tracker, which exhibits slow resizing in Haiku (#160).

I've written a small test app to compare R5 and Haiku behaviour, attached below. It shows B_NO_POINTER_HISTORY does not seem to have any effect in Haiku.

[tangobravo]

Small test application

[tangobravo]

--Observed R5 behaviour-- If mouse is moved over the view, the first message instantly begins processing. If the mouse is stopped before processing completes, only one more event is processed. This suggests all B_MOUSE_MOVED messages in the queue (excluding the one currently being processed) are removed before the new event is added to the end. It seems the BView::MouseDown and MouseUp functions also call MouseMoved - Haiku does this too. Perhaps this was so there are no issues with simply removing all B_MOUSE_MOVED messages. The KeyDown override was to examine the behaviour if it is not only mouse events that take a long time to process. I tested by pressing a key, moving the mouse, pressing a key, moving the mouse, etc. Interestingly some of the MouseMoved events did still get through before all the keypresses were processed, although many were removed. I had thought something like this might be needed to ensure that the view does receive *some* MouseMoved notifications, but I haven't discovered the exact scheme employed by R5. I also haven't examined how the B_ENTERED_VIEW etc flags are dealt with when using B_NO_POINTER_EVENTS.

--Current Haiku Behaviour (hrev20572)-- All the events are delivered to the view in the order in which they occurred.

I assigned the bug to the app_server as it seemed the appropriate place to do any removal of old messages as it as the entity that should know about the EventMask set for the view.

[axeld]

Thanks for the test app! I've reworked it a bit (and applied our coding style), and put it into our repository under src/tests/server/app/no_pointer_history/. Fixed in hrev22021; the server did evaluate that option, but it was still way too fast generating the messages (as it didn't know when the view had read that last message). Now, we do the filtering client side.