It worked for me on workstation and device (link). 

Current status:

1. Reproduced on veyron_minnie:

1) General mouse moves are slow (not just cursor movements - confirmed with autoclick rings); but mouse moves after a mouse click (mouse drags) are not slow. However, events are not going into any queue in WindowManagerState, EventTargeter or WindowTree most of the time, and even if they do go into queue in some touch-move-sequences it's a normal amount of them. After WindowTree we don't seem to have more event queues in ui/aura.

2) I found that a lot of test images are failing for veyron_minnie so I can't use them for testing. 
- cros sdk version was 9608 so I tried test image 9608 first and that was working correctly (no slow mouse moves) 
- all images were failing for minnie between 9609 and 9666
- 9667 is kinda working cuz mouse moves are not slow but screen keeps flashing
- 9668-9679 are failing for minnie 
- 9680 we are experiencing slow mouse moves. 
Sample failures https://uberchromegw.corp.google.com/i/chromeos/builders/veyron_minnie-release/builds/1213 and https://uberchromegw.corp.google.com/i/chromeos/builders/veyron_minnie-release/builds/1239. James, do you maybe know if these failures are somewhat related?

2. Not reproducible on link and kevin. 

When you say "test images are failing" what do you mean? Do you mean you can't deploy chrome to them?

The failures you link to are not related to mus (the failures are not in our tests). They look like infrastructure or autoupdate errors.

Often go/goldeneye will show a build as "failed" even though it works just fine. I think it just means some of the tests failed, which may be flake. This is super-confusing, I know.

9680 is very old (June 23). When I run "cros chrome-sdk" I'm at 9734.

(sdk veyron_minnie R61-9734.0.0) jamescook@jamescook /w/chrome/src $ 

> General mouse moves are slow (not just cursor movements - confirmed with
> autoclick rings); but mouse moves after a mouse click (mouse drags) are not
> slow.

One key difference between the two is that for mouse move, we do targeting for every event, whereas for click+drag, we do targeting only for mouse-press, and lock the target, so that we don't have to do any more targeting for the subsequent drag events. If we are doing something wrong in the target-queueing, it should be affecting all devices though, so not sure why this only shows up on minnie.

The async-targeting flag (--enable-async-event-targeting) isn't turned on, by any chance, right?

Sorry, by "test images are failing" I meant they show as "fail" on GoldenEye and those two failure links are from there. 

"Often go/goldeneye will show a build as "failed" even though it works just fine."  Ah I see, but if it's a failure like the ones I linked, is it still usable? Or only those ones with just test failures?

Yea I tried with OS 9734 (and cros sdk version 9734) as well and this bug exists.

Are there other differences between minnie and (link and kevin) except that minnie has lower dpi, less ram etc.?

> The async-targeting flag (--enable-async-event-targeting) isn't turned on, by any chance, right?

Yea that flag is not turned on. 

The ones marked "failed" in goldeneye are autotest failurse (system-wide integration tests). Those tests can be flaky and are highly sensitive to infra issues. Probably the builds work fine.

Link and kevin are both high DPI and pretty fast. Minnie is low DPI and pretty slow.

Is this still valid? My understanding is this works now, or am I missing something?

I am not in the office right now and I didn't try it on minnie recently. I remember this problem only happens on minnie. It is because uploading bitmap cursor to driver is really slow, and in mushrome, we do a lot of uploading bitmap cursor when cursor is being moved. I will verify it next week. 

 Issue 792889  has been merged into this issue.

This issue is because two problems:
1. Uploading bitmap cursor is very slow. Probably ozone drm or kernel drm driver has problem on minnie.
2. In mushrome, we upload bitmap cursor repeatedly, when user is moving cursor. 

Those two problems cause this issue together on minnie.

rjkroege@ could you please take a look this issue? Thanks.

+erg in case it's related to some of the cursor work he did.

as for mouse cursor problem, I did nothing special.
The movement is strange from login screen.
Strange means here, a cursor continues moving in few seconds, even though I stop a mouse.

Un-cc-ing me from all bugs on my final day.

I believe that this has been fixed.