GNOME Bugzilla – Bug 160848
[GOK] dwell tracking performance poor on sparc w/2 usb mice
Last modified: 2011-10-14 10:57:49 UTC
Please describe the problem: Connfigure the second usb mouse as a switch on a sparc machine, all the setting is set by default. Launch GOK and move switch cursor, you'll find its motion is too slow. Steps to reproduce: Connfigure the second usb mouse as a switch on a sparc machine on which S10_72 is installed, all the setting is set by default. Launch GOK and move switch cursor, you'll find its motion is too slow. Actual results: GOK moves too slowly. Expected results: GOK moves should be more smoothly. Does this happen every time? Yes. Other information:
I note that you have OS to all. Does this mean that this is also a problem on linux?
No, it's on sparc/solaris10.
I have seen this when using the second pointer in dwell mode. Inn the Gok Preferences Dialog, in the Actions tab set the Action to Dwell in the topmost ComboBox. The Sensitivity value seems to control the speed of the mouse motion.
This is OS dependent and seems to depend a lot on the hardware as well.
I made code changes to improve performance in this area on SPARC earlier this year. It may not be feasible to do much more.
doing much better here would require implementing pointer averaging and some sort of timer-based dwell delay. Would have negative impact on perceived performance on faster platforms too.
Does this happen only with USB mice? And is it a regression? I have not observed such slowness on sparc...
I have configured two mice on different machines(sparc and x86) successfully. It covers three OS(s10/sparc, s10/x86 and jds3/linux). Please refer the detailed info below: ----------------------------------------------------------------------------- Machine OS MouseConfigure Performance ----------------------------------------------------------------------------- SunBlade 100 s10/sparc 2 usb mice poor ----------------------------------------------------------------------------- Dell PC s10/x86 1 usb mouse(CorePointer) and good 1 ps2 mouse(Switch) ----------------------------------------------------------------------------- Dell PC jds3/linux 1 usb mouse(CorePointer) and good 1 ps2 mouse(Switch) -----------------------------------------------------------------------------
Is the behavior improved if you set gok's valuator sensitivity to a smaller number, for instance 0.2 ?
Is gok's valuator sensitivity the "Delay before Activation" value? I didn't change this value before. It is always the original value "0". And I think it's the minimum user could set.
"Is gok's valuator sensitivity the "Delay before Activation" value?" No, it's marked "Valuator sensitivity" and it's on the "Actions" page of the settings dialog.
Created attachment 36224 [details] Screenshot
But I could only find the "Delay before Activation" value in Actions tab. Please refer to the attachment above.
Tim: you must switch to a Dwell action in the 'Name' combobox before you see the relevant setting. (This bug is about dwell performance, not switch behavior, if I understand correctly)
Thank you Bill. According to your comments in #9 and #14, the performance is partly improved. But I find if I set the "Define Actions" as switch and "Access Methods" as "Dwell Selection", the performance is poor. This is the right bug I filed here.
OK, so you are saying that changing the valuator sensitivity for the 'Dwell' action reduces the severity of this bug... right?
Tim, do you know if there has been any further investigation into this from the sparc hardware end?
reopening (i closed this one by mistake)
Here's a candidate patch for this bug. I still cannot find the root cause, but the patch attached causes GOK to cache the XInput motion events and act on them at idle, as opposed to forcing activity on each XInput motion event as it is received. This makes GOK more robust against the scenario where either it's own "find key at mouse position" calculations, or other client-side calculation (such as XInput calculation) becomes slower than the XInput event delivery itself (i.e protects against "can't keep up" scenario).
Created attachment 52276 [details] [review] patch to make GOK react to XInput events only at idle
Patch has been associated with regressions/crashes on SPARC. Possibly this is due to insufficient error checking before the memcpy() call, revised patch is pending.
Bill, Just bumping this. Is it still on your radar?
Closing as OBSOLETE, please reopen as you deem necessary.
Why was this closed? AFAIK status did not change...
Reopening.
Bill, are you still around? Would be great to get this patch refreshed and tested against trunk.
gok (GNOME on-screen keyboard) development has been stalled and it has been replaced by caribou [1]. Maintainers don't have future development plan so i am closing all the bugs as WONTFIX. [1] https://mail.gnome.org/archives/gnome-bugsquad/2011-October/msg00001.html