Menu
▾
▴
#112 mouse device generate too many packets
in iodev/keyboard.cc, there is a timer function used to
query the gui code for any mouse update, and it sends
down the status to the device right after. This code
should actually check if there was any change in this
packet compared to the previous one, and if no change
was detected and (x,y) movement is 0, do not enqueue
the packet.
This not implemented behaviour cause bochs to generate
hundreds of packets per minute containing x=0,y=0
buttons=none, which could be one of the reason for why
moving the mouse in win95 (due to windows mouse
acceleration code) is so slow.
Logged In: YES
user_id=185114
Moving this to high priority. It should be very easy to try
and verify. And mouse performance is very important for
usability.
Logged In: YES
user_id=125806
This is a mixed problem. The gui code isn't supposed to
send down those empty packets, and the device code isn't
dropping them. I've made a change to keyboard.cc to drop
useless packets, which should help some. To really get the
performance up the gui code needs to be designed so that it
doesn't try to send unchanged packets either.
Logged In: YES
user_id=185114
Greg, your fix made a huge improvement. If you're satisfied
with it, let's close this up.
Logged In: YES
user_id=125806
I added a hack, dropping useless packets in mouse_motion().
There is still a performance improvement in stopping the
creation of those packets at the source. (At the source,
not just creating them and then filtering calls to
mouse_motion(), but stopping the whole event creation
process much earlier.)
This "bug" is less important now, so I've decreased the
priority and moved the category to GUI, where the changes
need to occur.
NOTE: I also added some other code to change the queueing
behavior of the mouse code, which has greatly helped to
improve mouse performance. The queueing code might also
make useless mouse_motion calls less of a problem, but they
really should be stopped at the source in the gui code.
Logged In: YES
user_id=93674
seems like the GUI code does not need any adjustment, the
simple hack did the trick. AFAIK both the X GUI and the SDL
GUI will generate packets only when the host OS generates
events, so there shouldn't be too many packets generated by
the GUI itself.