Stride windows bounds mismatch, DIP related

vvvv gamma bug
1

Hi,

I’m having a hard time dealing with “ClientBounds” mismatch on Stride Windows (Texture, Scene…)

Basically I’m saving the bounds in a document and apply it on project load.

It used to work without any issues in the past (don’t remember exactly when it start to fail), but currently there is something wrong when the screen DIP is different to 100%.

Am I missing something here?

see the attached document.

image
image1528×1528 105 KB

image
image1527×1522 96.2 KB

image
image789×687 11.4 KB

Screen bounds mismatch.vl (7.6 KB)

2

I am pretty sure this never worked reliably with display scaling != 100%.

3

I guess it’s a problem of Rectangle it does not have dpi pin, so you never know witch dpi it was saved on…

4

BTW what is the correct way to define this?

I feel a bit ignorant now

DPI or DIP?

image
image1198×299 7.32 KB

5

Hey @lasal, these are different things!

6

Thank you guys,

in any case it would be helpfull that the devvvvs put a bit of light on this topic, I don’t see a clear way to solve it based on the existing information

7

My current workaround.

not perfect, the translate factor is not consistent along different DPI, the Scale in other hand looks stable

image
image526×836 9.71 KB

8

Ok, finally narrowed it down to these values,

My guess is that the “Client bounds” provided are not including the window elements (Border, Header…), that makes the whole process inconsistent

image
image452×679 8.59 KB

9

The render windows were built at a time where multi monitor scaling wasn’t a thing yet, so the main focus was that the window opens the same way on different machines with different scaling → they save their bounds in device independent pixels.

However that does not work well for multi monitor setups with different scaling factors - what scaling factor to use? For that scenario using device pixels would be much easier. That would however mean to store the scaling factor as well (as @antokhio pointed out) and on open compare it to the current one and adjust accordingly (use stored bounds in device pixel to determine monitor, compare scaling factor and translate the remaining pixels / scale size).

We’ll have a look at this at some point.

10

(Regarding your workaround and the magic numbers - I remember when we internally switched the Stride window implementation from SDL to Windows Forms we ran into a similar issue. The window using client area vs non-client area for different things. I didn’t test it yet but could be that upcoming Stride addresses those issues, see Fix zero-sized window / crash after minimize and restore by xen2 · Pull Request #3300 · stride3d/stride · GitHub)

11

Thank you @Elias for bringing the light to this corner.

I hope we can have soon a solution for multiple monitors with different resolutions and DPI, the current scenario makes sharing projects between users/machines quite tedious.

I see that Imgui is affected by this issue…

Anyway, thanks again.