Comment 21 for bug 1690719

(In reply to Jonas Ådahl from comment #6)
> (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.

I c