I vaguely recall hearing something about Be doing the "consolidate mouse
messages" trick.
Personally, I never liked that. I like the idea of using the MouseMoved events.
I would *GUESS* that Maarten used mouse polling to work around some bugs. In an
email some years ago, he mentioned to me that there was an issue where the
message queues would fill up, preventing him from doing "real" MVC. This seems
like a work around for that sort of thing.
-----Original Message-----
From: "Stephan Assmus" [superstippi@xxxxxx]
Date: 07/08/2008 14:46
To: pedevel@xxxxxxxxxxxxx, haiku-development@xxxxxxxxxxxxx
Subject: Re: [haiku-development] Pe and mouse tracking under Haiku
Hi all,
you may or may not have noticed how selecting text in Pe with the mouse in
Haiku is lagging badly. This is how Pe tracks the mouse:
unsigned long buttons;
GetMouse(&cur, &buttons);
while (buttons)
{
...
snooze(20000);
GetMouse(&cur, &buttons);
}
Obviously the mouse driver is polling the mouse at a much shorter interval.
So regardless of whether or not Haiku has initially too many mouse messages
in the message queue, these messages would just pile up with code like
that. This must be a problem on BeOS as well if code such as above works
well there. The only solution I can see is checking the count of the mouse
messages in the Haiku BWindow implementation and just removing old ones at
a certain limit at least "plain" ones where the transit does not change.
Other than that, the code above is clearly not doing what it probably
intends to do, namely
GetMouse(&cur, &buttons, false);
Another option of course is to simply fix applications like Pe to do what
they intend on doing and leave Haiku as is. Opinions?
Best regards,
-Stephan
