From: Obscurity
@Brandon - Now do the same for mouse movements, not just clicks. Store every mouse_event generated in a single mouse movement, along with the click, and you wind up with a lot more.
It's not any different. The above calculations still hold. Consider the delay between each movement.
Delay: None
6505.7 clicks per second
23420520 clicks per hour
562092480 clicks per day
22483699200 bytes
21442.1264648438 megabytes
20.939576625824 gigabytes
Successfully executed.
Delay: 20ms
46.5 clicks per second
167400 clicks per hour
4017600 clicks per day
160704000 bytes
153.25927734375 megabytes
0.149667263031006 gigabytes
Successfully executed.
It says clicks because I was too lazy to change it to "movements" but those are the values for "movements".. See the below programs.
Now consider the fact that SRL uses:
https://github.com/SRL/SRL-6/blob/bf6a423ed448714aa56390a6df564857ad872f51/lib/core/mouse.simba#L52 and
https://github.com/SRL/SRL-6/blob/bf6a423ed448714aa56390a6df564857ad872f51/lib/core/mouse.simba#L200AND the fact that both functions add delays (via "wait(W)") such as:
https://github.com/SRL/SRL-6/blob/bf6a423ed448714aa56390a6df564857ad872f51/lib/core/mouse.simba#L169 between each and every point. PLUS the fact that there is a delay between socket communications when communicating with SMART..
Then it is safe to assume that 20ms is actually quite a small delay compared to what SRL introduces.. It's actually more than reasonable. And the above shows that for 24-hours total usage for such a delay is only 153mb.
ALSO consider the fact that recording movement takes LESS bytes than recording clicks.. Why? Because movement only contains X and Y and whether or not the mouse is down (for dragging of course.. aka 1 byte).
That's exactly 5 bytes per movement (2 words + 1 byte for drag flag).. Whereas the recorded data is using 40 bytes per movement which gives it more than the benefit of the doubt!
Code:
///THE above data uses the same structure as for clicks:
type data = packed record
X, Y: Word; //it makes sense to store mouse info as an "unsigned short" because your mouse position is never less than 0 or greater than 65535.
info: Array[0..31] of byte; //with 32 bytes, you can store client name or whatever..
click: integer; //You can store click (release or press) and (scroll up or down)..
end;
//BUT, in reality it should only be (for movement, but let's ignore that for code-reuse sake):
type data = packed record
X, Y: Word; //it makes sense to store mouse info as an "unsigned short" because your mouse position is never less than 0 or greater than 65535.
Drag: Byte; //flag for whether the mouse is being dragged (mouse button down) while moving.
end;
//for minimal storage and bandwidth usage..
//test code:
trials := 10;
GetClientDimensions(W, H);
ActivateClient();
I := GetSystemTime() + (1000 * trials);
while(GetSystemTime() < I) do
begin
moveMouse(randomRange(0, W), randomRange(0, H)); //using the nasty moveMouse instead of SRL-6 functions.
wait(20);
end;
lock(Pointer(@mutex)); //waits until the dummy window finishes updating the memory map. Synchronisation.
movements := getIntMap(); //Get the amount of movements from the memory map.
//same math as for clicks..
movements / trials; //etc..
Counter (code for the dummy window I created which records the number of movements it received and stores it in a memory map for Simba to read):
LRESULT __stdcall WindowProcedure(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
static unsigned int counter = 0;
static shared_mutex mutex;
switch(message)
{
case WM_CREATE:
{
lock(&mutex);
}
break;
case WM_KEYDOWN: //needed to reset the counter after targeting this window with Simba's cross-hairs..
{
counter = 0;
}
break;
case WM_MOUSEMOVE:
{
printf("Movements: %d\n", ++counter);
}
break;
case WM_DESTROY:
PostQuitMessage(0);
putIntMap(counter);
release(&mutex);
break;
default:
return DefWindowProc (hwnd, message, wParam, lParam);
}
return 0;
}
So the calculations still hold.. In fact, they're actually more reasonable for movements rather than clicks.