[Haiku-commits] r29413 - haiku/trunk/src/add-ons/input_server/devices/mouse

Stephan Assmus superstippi at gmx.de
Fri Mar 6 16:44:21 CET 2009

Hi Jérôme,

> 2009/3/6 <stippi at mail.berlios.de>
> > Limit the number for ioctl()s per second to about 125 for mouse
> transfers.
> > This
> > fixes the high CPU usage when using USB mice. I experimented with
> transfers
> > scheduled at fixed intervals, and with using a fixed pause between
> > transfers.
> > The fixed pauses, though much less sophisticated, give the smoothest
> > drawing
> > in WonderBrush. ;-)
> >
> Very interesting!
> Maybe it would be a good idea to have this delay mechanism in input_server
> so that it can be changed on demand per device.
> Something like BInputDevice::GranulateWait() and
> BMouseSettings::kDefaultMouseGranularity = 125

Sounds like a clean thing to do, but what could be the benefits of making this settable? After all, the human movement precision and the perception have limits. At first, I considered 1/60s, the usual screen refresh rate, to be a good number. Then I used double that just for kicks. Consider that the mouse device will buffer (pile up) intermediate movement measurements, so nothing is lost. In WonderBrush you have to move the mouse very fast and make enough of a turn to see edges in a stroke. Regular strokes, where you still have enough control and precision, should have enough samples per distance to look smooth. And if one wants more smoothness, it probably helps the user more to smooth out the mouse samples algorithmically (in WonderBrush), than by taking more samples per second. The only other interesting aspect would be games and some gamers believing their mouse needs to have 4000 dpi resolution. That resolution is of course not fully explored when taking too few samples per second, but I would not be easily convinced that 125 samples/s is not precise enough. Then again, I haven't stood beside a real gamer performing his art yet. ;-)

Best regards,

More information about the Haiku-commits mailing list