Any way to cannibalize the Windows 2000 mouse driver?

[jaclaz]

setting two SmoothX values to be the same (as you did with both SmoothX[1] and SmoothX[2] = 7) is a valid way to get the "step-up", so continue as you were!

Good.

So, summing it up, the six points are only five, and since the first one is always [0,0] they are actually only four (and one of them set at [40,568] makes no sense and can be placed at (say) [5,n] allright.

I have some issues with this :

- MouseSensitivity is "MouseSensitivity" from the registry

- MouseSensitivityFactor is =INT(MouseSensitivity*65536/10) (65536 for the 6/11, "10" position)

We have 11 Levels in the CP app cursor.

But we have at least 20 values in Mouse Sensitivity in Registry (from 1 to 20 or possibly from 0 to 20).

Since the good MS guys invented the "mickey" and more generally used units of measure in a very "vague" way, I feel authorized to introduce THREE elements:

MSCPL=Mouse Sensitivity in the Control Panel Levels

RMSV=Registry Mouse Sensitivity Values

ASOY=A Suffusion Of Yellow

The "conversion table is the following:

MSCPL 1 = RMSV 1

MSCPL 2 = RMSV 2

MSCPL 3 = RMSV 4

MSCPL 4 = RMSV 6

MSCPL 5 = RMSV 8

MSCPL 6 = RMSV 10

MSCPL 7 = RMSV 12

MSCPL 8 = RMSV 14

MSCPL 9 = RMSV 16

MSCPL 10 = RMSV 18

MSCPL 11 = RMSV 20

Using the control panel cursor you can only have these values in the MouseSensitivity key in the Registry, but all intermediate values are valid.

So you have a reversed table:

RMSV 1 = MSCPL 1

RMSV 2 = MSCPL 2

RMSV 3 = ASOY

RMSV 4 = MSCPL 4

RMSV 5 = ASOY

RMSV 6 = MSCPL 6

RMSV 7 = ASOY

RMSV 8 = MSCPL 8

RMSV 9 = ASOY

RMSV 10 = MSCPL 10

RMSV 11 = ASOY

RMSV 12 = MSCPL 12

RMSV 13 = ASOY

RMSV 14 = MSCPL 14

RMSV 15 = ASOY

RMSV 16 = MSCPL 16

RMSV 17 = ASOY

RMSV 18 = MSCPL 18

RMSV 19 = ASOY

RMSV 20 = MSCPL 20

The formula:

- MouseSensitivityFactor is =INT(MouseSensitivity*65536/10) (65536 for the 6/11, "10" position)

gives only a point (65536) of the diagram of conversion between MSCPL and actual MouseSensitivity Factor.

It would be logical that the "scalar set" to generate the family of curves is linear, i.e. that, using the "reduced" set of MSCPL you have:

MSF@MSCPL6=10*65536/10=65536

and:

MSF@MSCPL1=1*65536/10=6553

MSF@MSCPL2=2*65536/10=13107

MSF@MSCPL3=4*65536/10=26214

MSF@MSCPL4=6*65536/10=39321

MSF@MSCPL5=8*65536/10=52428

MSF@MSCPL6=10*65536/10=65536

MSF@MSCPL7=12*65536/10=78643

MSF@MSCPL8=14*65536/10=91750

MSF@MSCPL9=16*65536/10=104857

MSF@MSCPL10=18*65536/10=117964

MSF@MSCPL11=20*65536/10=131072

The results of a quick experiment lead me to think that this "scalar set" is non linear, and can be approximated with a quadratic expression.

Due to the obvious lack of precision of this early experiment and to the limited time I spent in half-@§§edly doing it, it is possible that the actual values are inaccurate, but the difference between a linear set and a function one is so evident that I have some serious doubts .

I am attaching a small spreadsheet with the results of the experiment, definitely - due to the half-@ssed testing procedure - I have lost important precision in the "lower levels", but "higher levels" should be "accurate enough", and more than that the "general shape" if not the actual scale/parameters should be also "accurate enough".

I tried to manually rebuild a more "logical" diagram of the "family of curves", measuring the image in the MS article, and the "linear formula" seemingly does not fit .

jaclaz

linearorcurve.zip

[WinWin]

Wow, this discussion really opened up in the past week or two. There is some really good info here and it gives good motivation to attempt to write a program that can fine-tune such curves a million times better than what is in our defaults. MarkTheC and jaclaz gave a huge amount of insight on this. It seems we have all come across the same roadblock of "compromise" when looking for the best solution. MarkTheC seems to know exactly what is going on when making those curves, the whole caveat being the smooth portion of the curve. It seems that no matter which points you create, that the intermediate values will be smoothed much like a bezier curve^a. This explains why some of these worked for slow movements or fast twitchy ones, but left something to be desired in between especially at points near that threshold^b and explains why exact values aren't achieved in the mouse movement recorder. (Thanks to MarkC for this.) Even though there isn't a perfect solution, there is a much better understanding of how things work and if I'm patient and smart enough, I'll eventually try to create a program that can better emulate different "curves" or "jumps".

For the time being I've been using Windows XP 64bit edition with MarkC's Mousefix builder 1.4 to achieve an exact 1:1 input and purchased a mouse that can change to any desired DPI on the fly and discovered simply doubling the other mouse's DPI gave back those perfect fast "twitchy" movements compromising the geared down slower ones with faster, jerkier ones. I discovered this to be better than having even a slight curve in between because it's not always predictable on a dime. This predictability is probably why I have become so attached to how it "jumps" with no curve in Win2k but no other subsequent OS; you know exactly where it is going to land every time. The good part is with a newer more responsive mouse, there feels to be a slight decrease in input latency which helps offset the slow jitter and over correction (Maybe 10ms or a frame or 2 at most) and the higher dpi makes it less noticeable. This seems to prove that in the evolution of tweaking the acceleration graph in subsequent versions of Windows OS that simpler is oftentimes the best solution. Again, great discussion, it really helped loads.

^aBézier curve (Wikipedia)

A bit how the "smooth" curve really behaves. (exaggerated for emphasis)

^b

[MarktheC]

It seems that no matter which points you create, that the intermediate values will be smoothed much like a bezier curve^a. This explains why some of these worked for slow movements or fast twitchy ones, but left something to be desired in between especially at points near that threshold^b and explains why exact values aren't achieved in the mouse movement recorder.

The smoothing that happens just near a step point is subtle, and I argue better (a little) in XP/Vista/7 than it was in Windows 2000...

I presume you have tried one or more of the × 1.0 stepping up to × 2.0 curves, and saw MouseMovementRecorder show what looks like a single intermediate smoothed value, rather than a sudden step-up? MMR might show 8 as 1:1=8, then 9 as 1.5:1=13, then another 9 as 2:1=18, and then other values at 2:1.

The middle 9 = 13 or 14 looks like "smoothing", which didn't happen in Windows 2000, and therefore bad?

Not necessarily so...

(If instead you were using a 1:2:4 curve, where the middle 2:1 section was a slope increasing from 1:1 to 4:1, then what I say below WON'T apply, but if you were using a 1->2 curve, please keep reading...

(For the examples below, forget the REG curve that steps up at 9, and imagine one built to step-up at exactly the same point that Windows 2000 did: 8)

1) If you are sweeping up past the threshold and then stay faster 8 or faster, then the difference is only 4 pixels that occurs once only (as the threshhold is passed) and likely not felt or noticed.

2) Imagine instead you are moving the mouse at a constant speed (perhaps trying to track a target?)

Suppose that speeds happens to be right at the threshhold, right in the middle, and you are moving at (on average) 7.5 mouse counts per poll.

The mouse sends 7, 8, 7, 8, 7, 8, ...

Windows 2000 would apply 1:1 to each of the 7s and 2:1 to each of the 8s, so after accel, the pointer would be 7, 16, 7, 16, 7, 16...

So a mouse speed of 7.5 has pointer speed of (7+16)/2 = 11.5 pixels on average. Average gain is 11.5/7.5 = 1.5333 !

Even Windows 2000 has smoothing just either side of the step-up point.

I've built a graph showing the difference between W2K and XP/Vista/7 for a mouse moving at a constant speed:

(X axis is (average) mouse movement in counts, Y Axis is (average) scaling applied)

Notice the transition between 7 and 8 is steeper with XP/Vista/7 than it is for Windows 2000.

As Windows XP/Vista/7 processes the 8s, it notices that IMMEDIATELY BEFORE the 8 was a 7, which was in the previous curve segment.

It reduces the accel to an average of the two curve segments, 1.5:1 for each 8.

As Windows XP/Vista/7 processes the 7s, it notices that BEFORE the 7 was an 8, which is in the next (or same) curve segment, and it does nothing special, just uses the current curve 1:1.

So after accel, the pointer would be 7, 12, 7, 12... and the pointer speed is (7+12)/2 = 9.5. Average gain is 9.5/7.5 = 1.267 !

The middle of the step is pulled down, making the transition steeper.

I think the steeper transition is better than the shallower transition.

3) Windows XP/Vista/7, the transition steepening can't be turned off, so there is no choice but to accept it!

For the time being I've been using Windows XP 64bit edition with MarkC's Mousefix builder 1.4 to achieve an exact 1:1 input and purchased a mouse that can change to any desired DPI on the fly and discovered simply doubling the other mouse's DPI gave back those perfect fast "twitchy" movements compromising the geared down slower ones with faster, jerkier ones. I discovered this to be better than having even a slight curve in between because it's not always predictable on a dime. This predictability is probably why I have become so attached to how it "jumps" with no curve in Win2k but no other subsequent OS; you know exactly where it is going to land every time. ... This seems to prove that in the evolution of tweaking the acceleration graph in subsequent versions of Windows OS that simpler is oftentimes the best solution.

You can't change your mind now!

I've just gone and applied much magic, and I now have 3 part curves where NO part needs to be a compromise.

There is a flat 1:1 section, a step up, a flat 2:1 section, a step up, a flat 4:1 section.

(These curves will closely match the Windows 2000 Medium and High accel settings.)

(They do have the "smoothing"/"transition steepening" as described above.)

When you used Windows 2000, did you use Low accel, or did you use Medium or High?

If you used Medium or High, would you like to try one of my "magic" curves?

Edited June 12, 2012 by MarktheC

[ownage11]

Thank you for the information really care deeply about how things worked in 2000,

I still got 2000 at the moment but on a Virtual machine,

I would like to give it a shot for you'r magic curves I'll check that out and give a report back.

By the way is the custom curves you made for me mark can have any useful fix? or it's the only option of that release? (Feels close)

Edited June 12, 2012 by ownage11

[MarktheC]

We have 11 Levels in the CP app cursor.

But we have at least 20 values in Mouse Sensitivity in Registry (from 1 to 20 or possibly from 0 to 20).

Since the good MS guys invented the "mickey" and more generally used units of measure in a very "vague" way, I feel authorized to introduce THREE elements:

MSCPL=Mouse Sensitivity in the Control Panel Levels

RMSV=Registry Mouse Sensitivity Values...

BTW, my MarkC Fix Builder allows the middle values to be used and entered as 2.5 3.5 4.5 etc., in the part that asks for what Pointer Speed Slider value to use.

Sorry, the way the MSCPL value affects scaling depends on whether the 'Enhance pointer precision' checkbox is ON or OFF.

(I should have said that, rather than assumed it.)

When EPP is ON, the scaling is MouseSensitivityFactor is =INT(MouseSensitivity*65536/10), which is a strictly linear function of MouseSensitivity.

When EPP is OFF, scaling is a piecewise function:

if (MouseSensitivity <= 2)
	MouseSensitivityFactor = MouseSensitivity / 32
else if (MouseSensitivity <= 10)
	MouseSensitivityFactor = (MouseSensitivity-2) / 8
else
	MouseSensitivityFactor = (MouseSensitivity-6) / 4

...and the typical pointer resolution is 400 mickey/inch.

They may have meant to say "pointing device resolution", but they mean "Mouse".

The term "Mickey" is an attempt to be clear.

I try not to use "dots", as in dots-per-inch to describe mouse resolution or mouse movement, because it can easily be confused with "pixel" (think of a monitor resolution usually measured in "dots-per-inch").

I use "mouse count", and CPI (counts-per-inch), and they use "Mickey" to make it 100% clear they are not talking about pixels.

Microsoft have stuffed up their example.

Note in YOUR calculations (with no "transformation"), that the one second of mouse movement was 375 counts (Mickeys/dots).

in YOUR calculations (with no "transformation"), that the one second of pointer movement was 225 pixels.

So which is it? 375 or 225?

Why would Microsoft suggest an example where on the MOUSE, there are 125 polling intervals every second, with 3 counts each interval, and then somehow assume that that corresponds to 75 refresh intervals on the monitor ALSO WITH 3 counts each interval?

That's just confused. The time intervals are of different lengths. How could there be the same number of counts (with no transformation)?

What do they imagine happened to the extra mouse counts during that 1 second?

The correct calculation is 1 second of movement @ 3 counts/poll = 375 counts and 0.9375 inches.

No transformation = 1:1 = 375 pixels on the monitor.

375 pixels on the monitor @ 80DPI = 4.6875 inches.

Mouse/Display Gain = 4.6875/0.9375 = 5.0

Throw all of the polling and refreshing and MS confusion way, the mouse is 400 CPI, the monitor 80 DPI, assuming 1:1 (no "transformation"), Mouse/Display gain = 400/80 = 5.0 (Hmmm same number as above!)

I don't know if you have read my first blog post, but Microsoft carried this stuff-up all of the way into the actual Windows XP code, then sort of realised there must be a mistake somewhere, then stuffed it up some more for good measure and shipped it...

Ditto for your second example with the 22 inch LCD monitor.

Why suddenly do mouse counts arriving 125 times a second, magically turn into (with no "transformation" = 1:1) 3 pixels moved 60 times a second (the 60Hz monitor refresh rate)?

Answer: They don't: Microsoft were confused.

The proper Mouse/Display gain (with no transformation) is 400/90 (CPI/DPI) (which is not 2.13).

We DO NOT have Screen Resolution, expressed in dpi (RWdpi).

We do have the Screen Resolution expressed in Xpixels*Ypixels, but unless we have the physical size of the screen we have NOT it in dpi (or ppi, pixels per inch).

Correct, we do not have directly have screen resolution (DPI).

We do have the monitor "Text Size", which will have to do, and be used in place of the actual monitor DPI.

Presumably they are at least crudely related, if for no other reason that a user with a high DPI monitor may tend to set the Text Size DPI higher so they can read text better...

How to change/view the DPI on Windows 7.

How to change/view the DPI on Vista.

How to change/view the DPI on XP.

"Text Size" AKA Monitor DPI will just have to do, and that is what MS use in the accel logic.

Logitech mouse drivers (SetPoint) if installed, can have their own scaling and accel, and disable the Window Control Panel settings.

Best to make sure what your Logitech mouse driver settings are before testing things, if you have SetPoint installed.

(Measuring mouse response)

I'd say your measurements are consistent with an actual mouse CPI of ~440 CPI.

With EPP ON, and moving slowling, the default Windows curve has a × 0.58 multiplier (Windows XP, 60Hz monitor, "Normal Fonts"=96DPI)

2.16" with × 0.58 should be 440×2.16×0.58 = 550 pixels, but would be more if you took shorter than 5 seconds to make that movement (because EPP accel would start to kick in).

With EPP OFF, 440×2.16" = 950 pixels

With EPP OFF, 440×0.85" = 374 pixels

Were I started, was moving the mouse slowly (make sure MouseMovementRecorder never shows more than 1s), and changing the monitor refresh rate and Text Size DPI and seeing how that affected the mouse response (with EPP ON of course) and then cursing at MS for what I found.

A quick observation makes evident that the mouse cursor "levels" that you can obtain in the control panel, which have been numbered from 1 to 11, being 6 the "middle setting", correspond to a value in the Registry HKEY_CURRENT_USER\Control Panel\Mouse\MouseSensitivity, with values that correspond to the following: ...

With EPP OFF, hopefully the piecewise sensitivity function above agrees with your measurements for CPL=1 thru 20.

(From memory, if the registry MouseSensitivity is outside the range 1 thru 20, Windows uses 10 instead.)

And finally:

THANK YOU jaclaz for querying about how many points there were and how many segments that corresponded to!

Because of yourcomments, I very closely reexamined the logic, and from 5 points, enough magic can be applied to get 3 flat segments and 2 step-ups, so that Windows 2000 Medium and High curves can be implemented, with 1 flat 1:1 section, a zero-width step-up, a flat 2:1 section, another zero-width step-up and a final 4:1 curve going out until approx 8000 mouse counts!

[jaclaz]

When EPP is ON, the scaling is MouseSensitivityFactor is =INT(MouseSensitivity*65536/10), which is a strictly linear function of MouseSensitivity.

When EPP is OFF, scaling is a piecewise function:

if (MouseSensitivity <= 2)
	MouseSensitivityFactor = MouseSensitivity / 32
else if (MouseSensitivity <= 10)
	MouseSensitivityFactor = (MouseSensitivity-2) / 8
else
	MouseSensitivityFactor = (MouseSensitivity-6) / 4

Is it possible that you missed a 65536 in the latter?

I.e. is the attachment correct?

Any idea why exactly the "cyanide" curve doesn't match levles 5, 6 or 7?

jaclaz

EPONOFF.zip

[MarktheC]

Is it possible that you missed a 65536 in the latter?

No ... and yes...

There are 2 ways of writing the formulas: One way more EASY easily readable and understandable by us humans, so we can understand the rough calculations, and another way showing the EXACT internal calculations done, if we need to be sure that the internal rounding is OK and remainders are being handled as we want them to be.

I've given the EPP=ON EXACT formula, but the EPP=OFF EASY formula, which is why it looks like a 65536 is missing.

Here is the EASY formula for EPP ON:

If:

- Smooth_X is the delta SmoothX value of the segment (SmoothMouseXCurve - SmoothMouseXCurve[i-1])

(1.0 = 0x10000)

- Smooth_Y is the delta SmoothY value of the segment (SmoothMouseYCurve - SmoothMouseYCurve[i-1])

- DPI is 96 (or whatever)

- MouseSensitivity is "MouseSensitivity" from the registry

- MouseSensitivityFactor is =MouseSensitivity/10 (1.0 for the 6/11, "10" position)

Then the final sensitivity (Windows 7) is:

Scaling=(Smooth_Y*((DPI/150)*MouseSensitivityFactor))/(Smooth_X*3.5))

(BTW, this is a simplified formula that only applies when the segment starts at 0,0, so it can be used for 1:1 fixes and the like...)

If we want to understand how the 'Enhance pointer precision' accel works, we can use the EASY formula.

But the EASY calculation, if done on your desk calculator, or if done by Excel, does not exactly represent what Windows does.

If we want to make sure that a curve we build has EXACTLY a 1.0 scaling (rather than a 65535/65536 = 0.99998 scaling), then we need the EXACT formula.

(The EPP=ON exact formula is on page 2 of this thread.)

When EPP is ON, the EASY formula and the EXACT formula sometimes give different results.

Here is the EASY formula for EPP OFF:

if (MouseSensitivity <= 2)
	MouseSensitivityFactor = MouseSensitivity / 32
else if (MouseSensitivity <= 10)
	MouseSensitivityFactor = (MouseSensitivity-2) / 8
else
	MouseSensitivityFactor = (MouseSensitivity-6) / 4
Scaling = MouseSensitivityFactor

For creating a graph comparing EPP=ON versus EPP=OFF, I would use the EASY formulas for both. Neither of which have a 65536 in them.

Here is the EXACT formula for EPP OFF:

(The scaling factor is stored in fixed point 24.8)

if (MouseSensitivity <= 2)
	MouseSensitivityFactor = INT(MouseSensitivity * 256 / 32)
else if (MouseSensitivity <= 10)
	MouseSensitivityFactor = INT((MouseSensitivity-2) * 256 / 8)
else
	MouseSensitivityFactor = INT((MouseSensitivity-6) * 256 / 4)
Scaling = MouseSensitivityFactor

BUT... If the EPP=OFF EASY calculation is done on your desk calculator, or done by Excel, it gives the SAME result as the EXACT calculation, so there is no point in using the exact calculation, which one reason I didn't include any 65536 or 256 in the EPP=OFF formula.

I.e. is the attachment correct?

Yes, the attachment is correct, although I suggest dividing the X-axis by 65536 so it runs 0 thru 3.5

Any idea why exactly the "cyanide" curve doesn't match levles 5, 6 or 7?

Eh? Sorry, I'm not sure what you are asking here.

The cyan coloured curve doesn't match what?

Edited June 14, 2012 by MarktheC

[jaclaz]

No ... and yes...

.....

Yes, the attachment is correct, although I suggest dividing the X-axis by 65536 so it runs 0 thru 3.5

I'tll try to correct the spreadsheet/implement the "EXACT" formulas, thanks.

Any idea why exactly the "cyanide" curve doesn't match levles 5, 6 or 7?

Eh? Sorry, I'm not sure what you are asking here.

The cyan coloured curve doesn't match what?

My bad , I gave as acquired that the issue I had in linearorcurve.xls about re-creating the "family of curves" graph was clear.

In the article the graph has 4 curves, and I only seem to find 3 of them (the 4th "cyan" one being "off by something").

It is possible that the graph was plotted with EP ON (whilst I only tried with EP OFF) .

Now that I have more clear the "levels" I will try again and see if I get a senceful result .

As always, I need some time to understand the implications of your post, at first sight I am confused but the references you make to the way the number is stored, whch to me seems like marginal/irrelevant, in my view:

If a number is stored in "xy.16" it is multiplied by 65536.

If a number is stored in "wz.8" it is multiplied by 256.

This happens IMHO "outside" of the formula and in the "conversion/storing".

And, given all the horrors implied or derived or caused by the implementation, I feel allowed to add that in this context where almost everything is either rounded or queerly converted or just plain wrong, if and when I get 0.99998 I would call it a "good enough" approximation of 1 .

Apple and oranges (YES, they can be compared ):

http://improbable.com/airchives/paperair/volume1/v1i3/air-1-3-apples.html

jaclaz

[jaclaz]

For NO apparent reason , and possibly of NO use whatever , a simple spreadsheet with common display resolutions and screen sizes (and consequent physical density in dpi).

jaclaz

Screens_dpi.zip

[jaclaz]

For even less apparent reasons , a set of batch files to test some of the "queer" behaviour of the mouse.

At the moment just a very rough, experiemental assembly of half-@§§ed batches.

You will need a couple external apps:

Nircmdc, part of Nircmd from Nirsoft:

http://www.nirsoft.net/utils/nircmd.html

(greetings and thanks to MarkTheC for pointing me to the sendmouse move capabilities of the above.

MAT (Mouse Acceleration Toggler):

http://skwire.dcmembers.com/wb/pages/software/mat.php

Put the batches in the same directory nircmdc and MouseAccelToggler.exe, open a command prompt and navigate to that folder.

Read the quick instructions that appear when you run any of them.

jaclaz

mousecmd.zip

[MarktheC]

I have built some .REG mouse fixes that make XP/Vista/7 emulate Windows 2000 & Windows 9X mouse acceleration.

I need some beta testers to test the Windows 2000 Medium and Windows 2000 High accel fixes, just to be 100% sure they are safe.

If you can help test the fixes, please send me a Private Message, by clicking on the 'PM this member' envelope icon below my name at the top left of this post.

@ownage11 : This includes you. If you can test the fixes, please send me a PM.

A normal CPL or Cheese or MarkC mouse fix is 100% safe to use.

The W2K Medium and High fixes are not normal.

There is a very small chance that they might not be safe.

I have tested them (on 3 different PCs) and they work for me, but I need more testers to be 100% sure they are safe.

To test them you will need one of:

- A Windows logon user account that is separate from your normal login. You login to Windows using that separate account, and test the fix.

OR

- Your PC boots to the Welcome screen or Logon dialog, and you already have a second logon user account that you can use if needed. You know that that second account is enabled and can be used to login. You login to Windows using your main account, and test the fix.

OR

- You have a Virtual Machine you can test the fix in.

You take a Snapshot of the VM, and test the fix in the VM.

[ownage11]

Hello hello,

surely i'm going to help you in everything needed, just tell me exactly the parts you want me to check out, since I know most of the old feels in win2000 + XP include in gaming tested my self for hours.

As I said before, I am running on my machine at the moment multiple operation systems. XP , 7 (64bit), 2000pro(virtual machine)

I am a risky guy anyway will try everything over there,

Thanks again Mark, I'm waiting for it.

Will also send you a private message right now!

Edited June 21, 2012 by ownage11

[jaclaz]

A better set of test batches, dosquares.cmd and doHlines.cmd + results of first test.

Provided that the nircmdc actually sends what it is supposed to to the mouse buffer (or whatever), it seems that there is in reality a not-so-trifling difference between what should happen and what really happens.

It is not a "timing" problem, I did a few more experiments and the timing is almost "right", it may possibly account for max 5% difference, but I have measured around 20% differences AND they are not "linear".

Tests have been made with a system using a (I assume 400 dpi) PS/2 Mouse polling at 100 Hz.

It is possible that the issues are related to the actual bus, and that a system with a USB mouse behaves differerently, but it would be "queer".

To measure length of lines I found this old version of Caliper very handy:

http://web.archive.org/web/20010424021827/http://www.iconico.com/caliper/

(thanks to tinyapps.org for the pointer ):

http://tinyapps.org/graphics.html

jaclaz

experiments1.zip