Comment 22 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)

I'm testing with an i5-4200. So considerably faster Haswell graphics, but not much faster overall. It's possible that the differences actually have to do with different input devices and different reporting frequencies or other behaviors - though I don't reproduce anything dramatic either with my laptop's internal touchpad, or switching to a mouse.

> 1. Open app grid - mouse freezes for ~1-2 s the first time, then "regular"
> stuttering similar as described below

1-2s is a lot! - could we be doing some IO in the main thread?

> 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

Do you mean anything different by "lag" and "stutter", or in both cases, do you just mean that the mouse pointer seems to just update rarely.

This is sort of shocking - the amount of drawing and computation being done here should be quite minimal - I have a hard time imaging that we can't do it at 60fps. If I ssh in and take a look at CPU usage when mousing over a row of icons, it's about 33% for gnome-shell. This is definitely way too high - but still not close to what would cause frame drops on its own.

 * What is the CPU usage on your system?
 * What portions of the screen are being redrawn?

> 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.

OK - I think the patch is correct - I reviewed it. But it looks like the effect it will cause is not lagging or stuttering, but instead a feeling of molasses. And of course, if there's a difference between moving over empty space and highlighting icons, that means we're dropping frames, which doesn't make sense to me.

(As far as I remember the code, Clutter will fall back to a timer to batch and compress events to 60fps if there is no drawing going on, but never flushes the queue more than 60 times a second.)

> 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 think "main thread time" is pretty much a red herring as far as that goes - clutter can be sitting idle in the main loop - it's not going to run another batch of events until it gets a frame complete event back from the GPU.