Mir

Code review comment for lp://staging/~mir-team/mir/introduce-pointer-event

introduce-pointer-event
Merge into development-branch

Revision history for this message

Chris Halse Rogers (raof) wrote on 2015-01-14:

On Wed, Jan 14, 2015 at 6:35 PM, Daniel van Vugt
<email address hidden> wrote:
> I think the ease with which I found the word "pointer" confusing
> suggests I won't be the last one. We have an opportunity to choose
> less ambiguous terminology now. Probably not so much later.

I don't think we have a better candidate terminology available yet?

The thing is, pointer events *don't* come from any physical input
device; they come from a synthesised virtual pointer.

It shouldn't be called MirRelativeInputEvent because the (the x,y axes
of the event) event is absolute (and the vscroll, hscroll axes are
relative ☺).

And, as you note, absolute devices like the stylus on a tablet *can*
produce MirPointerInputEvents; it would be pretty weird if they
produced RelativeInputEvents.

We *could* have a different model; make everything MirInputDeviceEvent
and then have a special “device 0” virtual pointer device. I'm not
sure if that's any better, though.

>
> Chris:
> I don't think fixed point is necessarily better than floats for
> input. If you have fixed 24.8 (32-bit) then to avoid overflows you
> need to remember to always work with 64-bit numbers. And of course,
> you need to shift in the end to get to your whole numbers. OK, yes
> there's a performance advantage in doing lots of ops with ints
> instead of floats, but not as great as it used to be. Can anyone cite
> a specific case for input where sub-pixel precision is important?...

Sub-pixel precision is important for two cases:

For relative motion events it's flat out necessary - otherwise, it's
possible to move the mouse at a slow but reasonable speed without
generating any non-zero input events.

For absolute events it's necessary if you're doing any sort of
transformation.

Hm. I was suggesting fixed point in part because that's what we get out
of libinput, but it seems that libinput switched to double since I last
looked at it.

Since float will still give us 8bits of subpixel precision all the way
out to 65,000x65,000 pixel outputs that might be enough. The reasons
why we might want doubles include: that's what we get from libinput,
and it gives nested servers some headroom.

If we need to we can double later.

On Wed, Jan 14, 2015 at 6:35 PM, Daniel van Vugt 
<daniel.van.vugt@canonical.com> wrote:
> I think the ease with which I found the word "pointer" confusing 
> suggests I won't be the last one. We have an opportunity to choose 
> less ambiguous terminology now. Probably not so much later.

I don't think we have a better candidate terminology available yet?

The thing is, pointer events *don't* come from any physical input 
device; they come from a synthesised virtual pointer.

It shouldn't be called MirRelativeInputEvent because the (the x,y axes 
of the event) event is absolute (and the vscroll, hscroll axes are 
relative ☺).

And, as you note, absolute devices like the stylus on a tablet *can* 
produce MirPointerInputEvents; it would be pretty weird if they 
produced RelativeInputEvents.

We *could* have a different model; make everything MirInputDeviceEvent 
and then have a special “device 0” virtual pointer device. I'm not 
sure if that's any better, though.

> 
> Chris:
> I don't think fixed point is necessarily better than floats for 
> input. If you have fixed 24.8 (32-bit) then to avoid overflows you 
> need to remember to always work with 64-bit numbers. And of course, 
> you need to shift in the end to get to your whole numbers. OK, yes 
> there's a performance advantage in doing lots of ops with ints 
> instead of floats, but not as great as it used to be. Can anyone cite 
> a specific case for input where sub-pixel precision is important?...

Sub-pixel precision is important for two cases:

For relative motion events it's flat out necessary - otherwise, it's 
possible to move the mouse at a slow but reasonable speed without 
generating any non-zero input events.

For absolute events it's necessary if you're doing any sort of 
transformation.

Hm. I was suggesting fixed point in part because that's what we get out 
of libinput, but it seems that libinput switched to double since I last 
looked at it.

Since float will still give us 8bits of subpixel precision all the way 
out to 65,000x65,000 pixel outputs that might be enough. The reasons 
why we might want doubles include: that's what we get from libinput, 
and it gives nested servers some headroom.

If we need to we can double later.

« Back to merge proposal