> The issue that input drivers devices need high refresh frequency to be
> able to achieve high-precision freehand drawing is quite well known┬╣.

Yes.  But the bug here isn't about that.  I think I'll have to elaborate
a little.

When you move the mouse, it will report its motion in an event with a
two-component vector.  Naturally both components must always be present,
otherwise information is lost.  When wsmouse(4) gets such an event,
it will break that event into two separate events, one for the X delta
and another for Y.  This is because the current event structure cannot
contain the deltas for both axes.

Now ws(4) takes these two events and naturally considers them independent
(as there is no metadata to couple them together), and fills in the blanks
by setting one or the other delta to zero.  The result is two orthogonal
vectors which represent a motion your mouse never reported.  Their sum is
the original vector, but the motion they describe is still wrong.

So the problem here is not refresh frequency, precision or anything like
that.  It's just that our data gets effectively mangled and corrupted 
between the two layers.  My diff attempts to reconstruct the original
vector by summing consecutive delta events, but as you noted below, this
can also result in data loss.  The lossless method would involve extending
the ws event structure or adding some metadata (in the form of new events),
or perhaps stuffing both deltas into the value field we have now (this is
lossless only if they fit in 16 bits)..  Interpolation is something I
definitely wouldn't apply here :-)

> I re-did a few experiments with and without your patch on my laptop
> (with the Lenovo track point wihch is a relative device). I could not
> reproduce the waves you're getting in Gimp, but without your patch
> diagonals show indeed larger staircases effects. Under xfig(1) or
> bitmap(1) the difference is much less noticeable. Clearly the
> strategy used by applications to trac mouse motion for freehand
> drawing are not the same.
> I do fear that with some devices your patch will collapse too many
> events and make it harder to follow small radius curves. 

Right, I did not consider this case.  If this is a problem, perhaps
the code could be changed to only collapse a pair of DELTA_X and
DELTA_Y events, but never more than that.  This way it might still
incorrectly merge two independent motions along the axes into one
diagonal motion, but I would expect that to be rare, and the deltas
to be so small that it has very little impact on anything.

Reply via email to