<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-15" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hi Simon, Tiago and list, Simon Thum: <blockquote cite="mid:4C83D329.6030700@gmx.de" type="cite"> <pre wrap="">Hi Albert, the code looks good to me in general. Besides some technicalities, there may be a larger problem: There is an effort to support wheels with higher precision (github.com/x-quadraht/pscroll).</pre> </blockquote> Ah, quite interesting. While my solution worked quite fine, I was thinking about that this would exactly be the next step because scrolling with such higher resolution would be much higher. This is also the main difference now if you scroll on MacOSX compared to my solution: The minimal scrolling-step on OSX is one single pixel. <blockquote cite="mid:4C83D329.6030700@gmx.de" type="cite"> <pre wrap="">Whether that particular solution will make it or not, it would be cool to handle wheel acceleration in one place.</pre> </blockquote> In one place with what? You mean together with pointer acceleration? pscroll does on Xorg the following: 1. In the Xorg server, it adds a way to add axes with no integration (I guess so that they are not interpreted as pointer position). 2. In each mouse input driver code (so far only evdev and synaptics), it creates additional axes for the wheel and in addition to the standard wheel button events (4 and 5), it sends axis motion events for the wheel axes. If the wheel acceleration is based on those wheel axes, it means that the acceleration works only for applications which support pscroll. It might be quite confusing/annoying for the user if it works in some application and not in others. Whereby, if you patch GTK and Qt, you already have most of the applications (except those who are statically linked and/or use a different framework). That is the problem if it was done wrong in the first place (why was it done with button events at all? only because it was simpler to do?) and now everythings depends on that. Of course that is not a reason to not fix this finally. It might be a reason though to implement the mouse wheel acceleration in a way that it works with both ways, i.e. it accelerates also those wheel button events (like what I have done). <blockquote cite="mid:4C83D329.6030700@gmx.de" type="cite"> <pre wrap="">I don't think the scheme mechanism is especially suitable here, IMO one can achieve a much higher degree of code sharing. </pre> </blockquote> Code sharing with pointer acceleration? <blockquote cite="mid:4C83D329.6030700@gmx.de" type="cite"> <blockquote type="cite"> <pre wrap="">+/******************************** + * acceleration proc + *******************************/ + + +void +ProcessWheelAccel( + DeviceIntPtr dev, + int button, + int* add_num_button_presses, + int evtime) +{ ... +} </pre> </blockquote> <pre wrap="">Most of that is done in the ptrveloc equivalent as well. You could instantiate a PointerVelocityRec using InitVelocityData (the structure is a bit tied to pointer accel but I'm cleaning that up.) and go like: switch(button) { case 4: x = 0; y = -1; break; case 5: x = 0; y = 1; break; case 6: x = -1; y = 0; break; case 7: x = 1; y = 0; break; default: /* unknown wheel button number */ return; } ProcessVelocityData2D(ptr, x, y, timestamp); Besides having a time-tested algorithm, you could adapt to a smooth wheel vs. button-based wheel by simply adjusting the PtrVelocityRec and some boilerplate code.</pre> </blockquote> I actually thought of that while I was investigating how I should implement it. The reasons I did not do it this way was: 1. The pointer acceleration is much more complicated because each motion event can have a different distance. For mouse wheeling (without pscroll), it was always the same. This simplifies the whole calculation a lot. 2. The pointer acceleration code was highly pointer specific. It heavily used those valuators. 3. I thought about that less is sometimes more. I.e. that it might be overkill to have different acceleration profiles/schemes for wheel acceleration. 4. I was not sure if all the code allowed me to have the acceleration the way I thought about it. More details: Currently, in my implementation, the acceleration code is quite simple. In case that the user scrolls in the same direction (and dt > 0): <meta charset="utf-8"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"> <pre style="word-wrap: break-word; white-space: pre-wrap;"> dt = evtime - velocitydata->lastWheelEvent[axeIndex].time; *add_num_button_presses = (int) (velocitydata->speed_mult / dt); </pre> And that is capped by some maximum (max_speed). This can be done that simple because of the single button events. If you translates that to velocity, it basically is this: v_new = v_old * (1 + min( int( speed_mult * v_old ), max_speed ) ) If pscroll is being adopted, this situation changes of course. Then, it would not very difficult anymore to reuse that code. My first two points may become invalid (whereby I still don't really like that valuator-stuff in that code). My third point may hold, though (well, that is arguable). I'm not sure about the fourth point but with pscroll, it is anyway not possible anymore to do the calculation that simple. When will pscroll be adopted? Or will it? When/how is such a decision made? Will it be soon? If not, what are the problems with pscroll? If not, might it be a solution to adopt my wheel acceleration patch for now and to reimplement (just with shared code from pointer acceleration) it as soon as we have something like pscroll? Tiago Vignatti: <blockquote cite="mid:20100906162744.GG4247@cachaca" type="cite"> <pre wrap="">I'm not sure about the feasibility but implementing all the velocity framework in the client side seems to solve this kind of issues. </pre> </blockquote> I don't think that it would be a good idea to have it on the client side. We also don't have pointer acceleration on the client side (well, this may be bad example because we also can't because the mouse pointer is handled server side). But I think it would be a quite bad idea to let each application / framework implement that itself. Cheers, Albert </body> </html>