Slow / choppy mouse event handling in Chrome

Strictly speaking, this is not directly related to WebGL, or specific implementations.
However, I’d expect the issue that I’m seeing to affect a significant amount of applications using WebGL, so posting it here seems like a good idea.

In my application, I’m experiencing “acceptable” frame rates. Even when turning anti-aliasing off, Firefox 4.0 seems to be significantly faster than Chrome 11/12, but I’ll see how things develop with future Chrome builds.

A more serious problem I’ve observed is the following.
In my application, the user can rotate a model using the mouse. This seems to be a fairly common scenario in 3D visualization. The actual application is not vertex/fragment limited - as mentioned, FPS is in the “comfortable zone”.

This is a huge difference though between Chrome and Firefox.

In Firefox, rotating the model with the mouse is
a) responsive: there is no noticeable lag between moving the mouse, and seeing the model rotate
b) smooth: it seems that every frame, the model rotates a few degrees/pixels, further improving the “interactive experience”

In contrast, in Google Chrome:
a) there seems to be a delay of a few hundred milliseconds before the mouse move event is actually dispatched to my code. When moving the mouse left/right, this gives the experience as if the model is attached to the mouse by a string of rubber. There is a small, but very noticeable delay before the model “follows” the movement of the user
2) mouse move events seem to be “aggregated”/“collected”, and only fired every 10/20 frames or so. In effect, the application seems to receive 6 mouse move events per seconds in Chrome, while in Firefox the same event is fired for every frame. This causes a distinct “choppiness” when moving/rotating models on screen with the mouse.

In my application, the WebGL/Canvas3D viewport typically covers the whole browser window, which perhaps exposes these slowdowns more than a smaller viewport would.

Then again, running the exact same code in Firefox does not exhibit any of the issues.

The typical target hardware I’m using is low end: 2010 Mac Mini with NVidia 940M.
However, I’m experiencing the same across a range of Intel/NVidia GPUs, on Windows 7 as well as Windows XP.

Most online WebGL demos using a large viewport and using the mouse to rotate a large model show this issue as well, which to me confirms that the issue is not in my code. For example, the Google “Body Browser” demo clearly shows the difference between Chrome and Firefox 4.

Am I the only seeing this? Is this a known side-effect of the Chrome multi-process model? Perhaps Chrome “optimizes” page responsiveness by “batching” mouse events before dispatching?

Comments welcome…

hmm I see framerates much higher with chrome than firefox (depends on scene complexity/windows size but anywhere from 2-10x FPS)

Have u tried profiling your app with chrome. ctrl-shift-j , click profiles & then the grey dot.
see where its spending the time at.
Also check the console window, stick a console.log( event.mousedata ) in the mouse move & mouse down etc functions, to see if your application is getting the signals

Also IIRC I used to see a bug with windows & nvidia when you had the nvidia application I forget the name, multiview or something where the nvidia icon appears on each window titlebar. If this was enabled the framerate for windows & d3d stuff went to hell whenever the mouse moved.

If I use programmatic animation (rotating the model some small amount every frame), the animation is actually quite smooth in Chrome.

I can reproduce the (negative) effect using a very minimal application, rendering 128 textured polygons, and rotating them based on the location of the mouse. There seems to be none (or hardly any) time spent in my code, which is using a pre-generated VBO for coords/texture coords/coord indices. Neither do I see an unexpected amount of garbage collections.

Again, I see the pattern using the Google Body Browser on a wide range of hardware (all on some variety of Windows though). At the same time, the issues disappear when switching to Firefox. Of course, the body browser demo is using anti-aliasing, so it’s not an apples-to-oranges comparison. Perhaps I’m also “looking for” the effect, and because of that, noticing it more than others.

So far, my feeling is that is has to do with the way that Chrome is processing mouse move events, and not such much with WebGL (or JavaScript VM performance). Still, it’s damn annoying once you’re aware of it, and actually is slowly getting to be a blocker for our application.

did u try

function handleMouseMove(e) {
console.log( e );

move mouse around & look at the console.log, is it instantly updating?
If you click on the MouseEvent-> u will see timeStamp: 1301458134262
which are the msecs since a certain time (perhaps 1970 jan)

Actually, I did try something like this.
I measured the time required to collect/receive 1000 mouse move events.

During the test, I tried as best as I could to move the mouse in the same circular pattern, at the same speed, until 1000 event had been collected. At that point, an alert() would shw the difference between the timestamp of event #1, versus the timestamp of event #1000.

Just to eliminate any noise from differences in mouse movement patterns, I repeated each test 3 times.

Collected timings are as following:

Time to collect 1000 MouseMove events

Firefox 4.0


Mouse event every ~8 ms
Framerate was ~50 FPS during test

Chrome 12 dev channel


Mouse event every ~14 ms
Framerate was ~60 FPS during test

This seems to show that mouse event dispatching happens almost twice as often in Firefox 4 as it does on Chrome 12 dev.
System was a 2010 Mac Mini running Windows 7 SP1.

I am seeing a very similar effect now. In both 2d and WebGL canvases, Firefox (9.0 at the moment, but 5+ behaved identically) only delivers mouse move events when I pause mouse movement. Pause, as opposed to mouse up. All the pending events arrive at this time, as seen both by the animation catching up and logging to the firebug console. Chrome, on the other hand, delivers the mouse move events as they happen, as does IE9 (for 2d canvases).

Has anyone found a cause of or solution to this lag?