Opened 13 years ago

Closed 13 years ago

#1415 closed bug (fixed)

B_NO_POINTER_HISTORY has no effect

Reported by: tangobravo Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


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.

Attachments (1) (2.0 KB ) - added by tangobravo 13 years ago.
Small test application

Download all attachments as: .zip

Change History (3)

by tangobravo, 13 years ago

Attachment: added

Small test application

comment:1 by tangobravo, 13 years ago

--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.

comment:2 by axeld, 13 years ago

Component: Servers/app_serverKits/Interface Kit
Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.