Comment 20 for bug 1690719

(In reply to Owen Taylor from comment #4)
> (In reply to Jasper St. Pierre from comment #3)
> > The current theory is that stuff like creating actors, uploading textures to
> > the GPU, etc. all block the main loop. I can readily produce it on my
> > computer, so perhaps yours is just super fast?
>
> Can you describe step by step what you are doing and what you see? The place
> I see it *most* is with the app picker, if I:
>
> A) Click on the app picker grid icon in the overview
> B) Immediately move the mouse cursor away
>
> Then I see the something like:
>
> Mouse cursor freezes for a fraction of a second
> Mouse cursor moves onces
> Mouse cursor freezes again for a smaller fraction of a second
> Mouse cursor moves with a bit of a stutter for the remainder of the
> animation
>

How I reproduce it on this machine (i7-2620M, Intel HD 3000)

1. Open app grid - mouse freezes for ~1-2 s the first time, then "regular" stuttering similar as described below
2. Move the cursor back and forth below the lowest row of icons - completely smooth movement
3. Move the cursor back and forth over the lowest row of icons (hovering them) - lags and stutters *very* visibly

Without the linked clutter patch, step 3 will result in the cursor ending up moving significantly slower (70% of the distance for the same physical movement), as events gets dropped.

Thinking of that patch again, we still might need it in order to not drop events, as libinput might push events faster than we read them even without frame drops in mutter/gnome-shell. If we happen to end up with two pointer motion events in the queue when dispatching libinput all but the last will end up effectively lost. Its just extra visible when there is tasks taking up extra much of the main thread time.