
Originally Posted by
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.
Progress Report:
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/bf...ouse.simba#L52 and https://github.com/SRL/SRL-6/blob/bf...use.simba#L200
AND the fact that both functions add delays (via "wait(W)") such as: https://github.com/SRL/SRL-6/blob/bf...use.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:
Simba 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):
C Code:
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.