1

I'm trying to record exactly where the mouse moves on a web page (to the pixel). I have the following code, but there are gaps in the resulting data.

var mouse = new Array();
$("html").mousemove(function(e){
    mouse.push(e.pageX + "," + e.pageY);
});

But, when I look at the data that is recorded, this is an example of what I see.

76,2 //start x,y
78,5 //moved right two pixels, down three pixels
78,8 //moved down three pixels

This would preferably look more like:

76,2 //start x,y
77,3 //missing
78,4 //missing
78,5 //moved right two pixels, down three pixels
78,6 //missing
78,7 //missing
78,8 //moved down three pixels

Is there a better way to store pixel by pixel mouse movement data? Are my goals too unrealistic for a web page?

Machavity
  • 30,841
  • 27
  • 92
  • 100
Jim
  • 11,229
  • 20
  • 79
  • 114
  • Why is that kind of "detail" necessary? Can't you discern that kind of detail from the mouse logs? – Jared Farrish Oct 13 '11 at 04:44
  • 1
    The mouse doesn't move across adjacent pixels in the first place - it moves from point to point. If you need to know where it crossed, interpolate by calculating a line (or curve) between the points. – mellamokb Oct 13 '11 at 04:44
  • recording 100% of the pixels is probably not necessary, but I'd like to get at close as possible. – Jim Oct 13 '11 at 04:46

3 Answers3

3

You can only save that information as fast as it's given to you. The mousemove events fires at a rate that is determined by the browser, usually topping at 60hz. Since you can certainly move your pointer faster than 60px/second, you won't be able to fill in the blanks unless you do some kind of interpolation.

That sounds like a good idea to me, imagine the hassle (and performance drag) of having 1920 mousemove events firing at once when you jump the mouse to the other side of the screen - and I don't even think the mouse itself polls fast enough, gaming mice don't go further than 1000hz.

See a live framerate test here: http://jsbin.com/ucevar/

On the interpolation, see this question that implements the Bresenham's line algorithm which you can use to find the missing points. This is a hard problem, the PenUltimate app for the iPad implements some amazing interpolation that makes line drawings look completely natural and fluid, but there is nothing about it on the web.

As for storing the data, just push an array of [x,y] instead of a string. A slow event handler function will also slow down the refresh rate, since events will be dropped when left behind.

Community
  • 1
  • 1
Ricardo Tomasi
  • 34,573
  • 2
  • 55
  • 66
2

The mouse doesn't exist at every pixel when you move it. During the update cycle, it actually jumps from point to point in a smooth manner, so to the eye it looks like it hits every point in between, when in fact it just skips around willy-nilly.

I'd recommend just storing the points where the mouse move event was registered. Each interval between two points creates a line, which can be used for whatever it is you need it for.

And, as far as processing efficiency goes...

Processing efficiency is going to depend on a number of factors. What browser is being used, how much memory the computer has, how well the code is optimized for the data-structure, etc.

Rather than prematurely optimize, write the program and then benchmark the slow parts to find out where your bottlenecks are.

  1. I'd probably create a custom Point object with a bunch of functions on the prototype and see how it performs
  2. if that bogs down too much, I'd switch to using object literals with x and y set.
  3. If that bogs down, I'd switch to using two arrays, one for x and one for y and make sure to always set x and y values together.
  4. If that bogs down, I'd try something new.
  5. goto 4
zzzzBov
  • 174,988
  • 54
  • 320
  • 367
1

Is there a better way to store pixel by pixel mouse movement data?

What are your criteria for "better"?

Are my goals too unrealistic for a web page?

If your goal is to store a new point each time the cursor enters a new pixel, yes. Also note that browser pixels don't necessarily map 1:1 to screen pixels, especially in the case of CRT monitors where they almost certainly don't.

RobG
  • 142,382
  • 31
  • 172
  • 209