[Xpert]Re: Patches in limbo - was Re: Re: Proposal for mouse speed & acceleration settings
Michael Toomim <[EMAIL PROTECTED]> writes: > David Dawes wrote: > > Once a submission is reviewed, any of the following may happen: > > 1. submission found to be a duplicate, or problem already fixed > > 2. committed with or without changes > > 3. submitter contacted for further information > > 4. held for further review > > 5. rejected > > Thanks for the explanation. Soeren, do you know which of these things > happened for your patch, or did it just get lost from your perspective? I haven't heard anything at all about it, unless I overlooked a mail about it. I don't know if that means 1, 2, 3 or "hasn't been reviewed yet". Søren ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Proposal for mouse speed & acceleration settings
Michael Toomim <[EMAIL PROTECTED]> writes: > The issue disappeared from the mailing list, but I had some discussion > offline with Joe Krahn about it after the mailing list posts that you > saw. During that discussion, I communicated with the woman who > researched mouse acceleration algorithms at Apple, and she told me > what algorithm Apple used and what her methodology was to come up with > the algorithm. That is interesting. Could you say more about what she did? > So between the first two options, my proposal retains backwards > compatibility and Soeren's gives it up. Personally, I'd prefer to > give up backwards compatibility, as I don't believe there is anybody > who actually *prefers* the threshold-multipler acceleration. But a > safer route might be to introduce the option first, and then to phase > it out slowly as people and desktops begin to support it. A fourth option would be to create a new extension that would allow the mouse acceleration to be controlled in detail. From searching on Google it appears you can do this on Windows XP. (I am not necessarily suggesting it is a good idea). Søren ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Proposal for mouse speed & acceleration settings
Michael Toomim <[EMAIL PROTECTED]> writes:
> Proposal: Add a boolean option to XF86Config called
> "UseSmoothMouseAccel" that changes the behavior of xset. If this
> variable is set to true, the command `xset m [A] [B]' will mean "set the
> cursor movement function to `[A] * raw_mouse_speed^[B]'".
Back in May this year I sent the mail below to [EMAIL PROTECTED], but
I never got any response.
Søren
From: Soeren Sandmann <[EMAIL PROTECTED]>
Subject: Smoother mouse acceleration
To: [EMAIL PROTECTED]
The current mouse acceleration algorithm when the user defined
threshold is non-zero is essentially this:
if (d > t)
d' = A * d
else
d' = d;
where d' is the new traveled distance, and d the distqance reported by
the mouse. The constant t is the user defined threshold, and A
(= num/den) is the user defined amount of acceleration.
There are some problems with this:
- if you set the threshold high, the mouse cursor feels
sticky. If you move the mouse at just the right speed, you
will se jerky cursor movements as the traveled distance
oscillates around the threshold.
- if you set the threshold low and the acceleration high, you
lose precision as the cursor moves too fast even on small
movements.
- if you set the acceleration low, it gets difficult to reach
to corners of the screen.
So, while this isn't terribly bad, it not really good either
Here is a patch that modifies the mouse acceleration code to use the
formula
d' = c * d^alpha + d
where d' is the new distance and d is the distance reported by the
mouse. The constants c and alpha are based on the acceleration
settings, specifically
c = 1 / (threshold / 4) ^alpha
which ensures that when the travelled distance is less then
threshold/4, the distance is not modified by more than 1. This ensures
that the threshold set by the user still corresponds to the precision
of the device.
The constant alpha is just a linear function of the user set
acceleration.
The patch also changes the default acceleration to 8/3 3, which in my
opinion is a more useful setting than 2/1 4, which is the current
default.
Søren
--- ../../../xcoriginal/programs/Xserver/hw/xfree86/common/xf86Xinput.c Tue May 21 01:50:43 2002
+++ ./hw/xfree86/common/xf86Xinput.c Tue May 21 01:49:00 2002
@@ -905,15 +905,42 @@
/*
* Accelerate
*/
- if (device->ptrfeed && device->ptrfeed->ctrl.num) {
- /* modeled from xf86Events.c */
- if (device->ptrfeed->ctrl.threshold) {
- if ((abs(dx) + abs(dy)) >= device->ptrfeed->ctrl.threshold) {
- valuator[0] = (dx * device->ptrfeed->ctrl.num) /
- device->ptrfeed->ctrl.den;
- valuator[1] = (dy * device->ptrfeed->ctrl.num) /
- device->ptrfeed->ctrl.den;
+ if (device->ptrfeed && device->ptrfeed->ctrl.num && device->ptrfeed->ctrl.den) {
+ if (device->ptrfeed->ctrl.num <= device->ptrfeed->ctrl.den) {
+ valuator[0] = (dx * device->ptrfeed->ctrl.num) / device->ptrfeed->ctrl.den;
+ valuator[1] = (dy * device->ptrfeed->ctrl.num) / device->ptrfeed->ctrl.den;
+ }
+ else if (device->ptrfeed->ctrl.threshold) {
+ static int cached_num = -1;
+ static int cached_den = -1;
+ static int cached_threshold = -1;
+
+ static double c = -1;
+ static double alpha = -1;
+
+ double k;
+
+ if (cached_num != device->ptrfeed->ctrl.num ||
+ cached_den != device->ptrfeed->ctrl.den ||
+ cached_threshold != device->ptrfeed->ctrl.threshold) {
+
+ double A, t;
+
+ cached_num = device->ptrfeed->ctrl.num;
+ cached_den = device->ptrfeed->ctrl.den;
+ cached_threshold = device->ptrfeed->ctrl.threshold;
+
+ A = (double)cached_num / cached_den;
+ t = (double)cached_threshold;
+
+ alpha = A/3.0 + 2.0/3.0;
+ c = 1 / pow (t/4.0, alpha);
}
+
+ k = c * pow (dx*dx + dy*dy, 0.5 * (alpha - 1)) + 1;
+
+ valuator[0] = k * dx;
+ valuator[1] = k * dy;
}
else if (dx || dy) {
mult = pow((float)(dx*dx+dy*dy),
--- ../../../xcoriginal/programs/Xserver/include/site.h Tue May 21 01:50:43 2002
+++ ./include/site.h Tue May 21 01:17:48 2002
@@ -113,9 +113,9 @@
#define DEFAULT_INT_MAX_VALUE 100
#define DEFAULT_INT_DISPLAYED 0
-#define DEFAULT_PTR_NUMERATOR 2
-#define DEFAULT_PTR_DENOMINATOR 1
-#define DEFAULT_PTR_THRESHOLD 4
+#define DEFAULT_PTR_NUMERATOR 8
+#define DEFAULT_PTR_DENOMINATOR 3
+#define DEFAULT_PTR_THRESHOLD 3
#define DEFAULT_SCREEN_SAVER_TIME (10 * (60 * 1000))
#define DEFAULT_SCREEN_SAVER_INTERVAL (10 * (60 * 1000))
Re: [Xpert]Slow opaque window resizing
Keith Packard <[EMAIL PROTECTED]> writes: > Please give the enclosed patch a try I would, but unfortunately I don't any longer have access to a machine where I can modify the X server. Søren ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Slow opaque window resizing
Mark Vojkovich <[EMAIL PROTECTED]> writes: >I'm not really sure about that. I've seen the effect that Owen > described and it's always seemed rather subtle to me. I could never > see appreciable slowdowns unless I sat there resizing manically for > a few seconds. Maybe Owen has some pathelogical cases that can > show it quicker, but I still don't think it's the primary cause of > opaque resize slowness. There are alot of apps that redraw everything > whenever they get a ConfigureNotify event. That's a problem. > I have written sample apps that do not have problems with opaque > resizes in my environment. The behaviour where the client stops drawing completely is not difficult to get with a moderately complex gtk+ 2.0 application and the X server running without -dumbScheduler. With -dumbScheduler, I can't get drawing to completely stop, but there is definitely noticeable lagging. Compared to Windows, opaque resizing really sucks. I think this is what happens during opaque resizing (with gtk+): (a) 1 window manager gets a mouse event. 2 window manager reconfigures client window and draws frame 3 server draws frame and sends the configure event to client (b) 1 client reads all configure events 2 client relayouts widgets and resizes all windows 3 client normally redraws everything (although some widgets, like the TextView, and in 2.2 the TreeView, are smarter and only redraw newly exposed areas). A gtk+ client often overflows Xlibs request buffer 30 or more times during b.3 (a simple strace will confirm this), so the X server can easily get scheduled during this [1], and get back in (a). With the smart X scheduler clients that are getting input events have their priority increased, and since during opaque resizing the window manager gets input events and the application doesn't, the application gets starved and it is possible to get stuck in (a) forever, which looks as if the application has stopped drawing completely. With -dumbScheduler we can still get stuck in (a) for a long time, but not forever. It would be an interesting experiment to make the window manger block an an XSYNC counter after it reconfigures the application window. Then, when the application finished drawing, it would increase that counter. (It is possible to also block the window manager on a timer, so it wouldn't be blocked forever). [1] And this is probably the reason gtk+'s windows can get quite a bit out of sync during opaque resizing. >The X-server would have to block until the refresh. It might not even > be scheduled at that time meaning you could miss refreshes. The performance > impact would be profound. The guys who have tried to synchronize video > overlays in software when the hardware doesn't double-buffer the swaps > for them know what I'm talking about here. The X server doesn't even have access to the vsync interrupt, right? As far as I know cards send an interrupt when they enter vertical retrace, but the (linux) kernel doesn't pass it on to user space applications. If the kernel did pass it on, maybe as a signal, wouldn't that make the latency from the interrupt occured until the x server was scheduled very small? Why would the entire X server have to block? If the SYNC extension was extended with a counter indicating vblank, then the window manager could send "wait for vblank" requests itself before it moved a window, and the server wouldn't have to block any other client. Søren ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
