Width and height of heatmap visualisation do not map to system screen resolution

[virtualarchitectures]

Great package! I've just tested v1.4.1 on Windows 10 and noticed that paths and clicks drawn across the horizontal and vertical center lines of my screen appeared off-center in the heatmap visualisation. The lines were shifted toward the bottom and right of the heatmap window.

I checked the SQLite database and confirmed that the logged coordinates are correct. For reference my test resolution was 1920 x 1200. It looks like the heatmap visualisation is set to a fixed resolution or screen ratio.

It's a really useful utility. It would be great if the heatmap visualisation mapped to the target resolution or screen ratio.

[suurjaak]

The coordinates should get mapped to actual screen size. What are the values in the screen_sizes table in your SQLite database?

[virtualarchitectures]

Thanks. Here's an image showing coordinates for the four corners in the SQLite database (Top left, top right, bottom right, bottom left). Clicks Table:

Screen_Sizes Table:

[suurjaak]

So the stored heights, 1536x960, are wrong? That would explain the skewed heatmap.

Can you open the Python console (right-click on InputScope tray icon -> Show Python console) and execute

for i in range(wx.Display.GetCount()): wx.Display(i).Geometry

What does it show?

[virtualarchitectures]

The console returns a single Rect(): wx.Rect(0, 0, 1536, 960) .The values match the values in the screen_sizes table.

[suurjaak]

Just a guess - does your Windows display setting use 125% scaling?

[virtualarchitectures]

I hadn't realised but it does. I have a feeling machines I want to use it on may also have scaling applied. I suspect you'll recommend to simply change the scaling to 100%. I'm not sure I'll necessarily be able to change the scaling on those machines due to user preferences. I'll also be working with multiscreen display setups (though the resolution for each screen should be the same). If you have any further suggestions or recommendations let me know, otherwise that looks like the solution.

[suurjaak]

So far I just haven't taken scaling into account. I should.

Can you open the Python console again and execute the following, line by line:

disp = wx.Display(0)

disp.GetPPI()

mode = disp.GetCurrentMode()

mode.Width, mode.Height, mode.Depth

What does it show?

[virtualarchitectures]

The output was: wx.Size(96, 96) with the mode width, height and depth as (1920, 1200, 32).

[suurjaak]

Excellent, then information on the true resolution is available.

I will issue a new release in the near future.

[suurjaak]

I have now released InputScope v1.5, which takes scaled screen into account. Sorry for the delay.

Can you confirm the new version works properly?

[virtualarchitectures]

Hi @suurjaak Thanks for letting me know. I just tested on a multi-screen setup using two screens and this worked as expected so I think this can be closed as resolved.

I did make some further observations:

1. Moving the mouse between screens of different sizes (extended desktop) changes the smoothness of the moves and seems to effect the playback of moves and clicks (more interrupted moves trace on larger screen, with faster playback of skips). Anecdotally the issue seemed to get worse the further to the right on the second screen (see image where the trace is increasingly sparse to the right). I imagine this is to do with how speed (distance / time ratio) is calculated somewhere. Here's the screen ratios for reference:

2. Unplugging second monitor while input scope is running opens console with error. Not a major issue but worth being aware of.

3. Clearing the database doesn't clear the app_events or screen_size tables. Perhaps that's intended behaviour.

I hope that's useful feedback. If you want further info let me know.

Many thanks for addressing the original issue. Much appreciated.

[P6016]

Excuse me??? What is going on??? I am not communicating with you?? As I’ve mentioned I believe I AM HACKED!! Who are you and what is this email regarding??????

Sent from my iPhone

On Jan 23, 2022, at 6:11 PM, virtualarchitectures @.***> wrote:

 Hi @suurjaak Thanks for letting me know. I just tested on a multi-screen setup using two screens and this worked as expected so I think this can be closed as resolved.

I did make some further observations:

Moving the mouse between screens of different sizes (extended desktop) changes the smoothness of the moves and seems to effect the playback of moves and clicks (more interrupted moves trace on larger screen, with faster playback of skips). Anecdotally the issue seemed to get worse the further to the right on the second screen (see image where the trace is increasingly sparse to the right).

I imagine this is to do with how speed (distance / time ratio) is calculated somewhere. Here's the screen ratios for reference:

Unplugging second monitor while input scope is running opens console with error. Not a major issue but worth being aware of.

Clearing the database doesn't clear the app_events or screen_size tables. Perhaps that's intended behaviour.

I hope that's useful feedback. If you want further info let me know.

Many thanks for addressing the original issue. Much appreciated.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.

[suurjaak]

@P6016 You have subscribed to this issue at some point, that is why you are receiving the notification e-mails. You can just unsubscribe from it again.

[suurjaak]

1. The smoothness of moves being different on the larger screen is to be expected - mouse moves are scaled to heatmap size before insertion and linear movement reduced to a single move, as there would be way too many mouse events otherwise.

But the movement being increasingly sparse further to the right, may be a bug, I will look into it.

2. A popup error definitely should not happen, this needs fixing.

3. It is intended behavior, as rows in app_events and screen_sizes are relatively few in number.

I will keep this issue open until 1 and 2 are resolved.

[suurjaak]

@virtualarchitectures Does the sparse movement bug still persist in the freshly released v1.6?

[suurjaak]

Closing issue due to lack of feedback.