IsolatedRendering Test Fails on High DPI Display

[padesso]

Summary

When running the unit tests on a system with a high DPI display, such as a Microsoft Surface (3000 x 2000) using the recommended magnification setting of 200%, the IsolatedRendering test fails with an IndexOutOfRangeException. If 150% magnification is selected, the test fails with an unexpected RGBA value value.

How to reproduce

Assuming a high DPI display.
In Windows Display Settings, set magnification to a value greater than 100%.
Build Duality in the develop-3.0 branch to discover unit tests.
Run the IsolatedRendering test.

Workaround

To workaround the issue, a user may:

• use a display that is not high DPI
• turn off magnification in Windows Display Settings
• make the high DPI display not the primary display if using multiple displays

Analysis

It seems this test creates a scene, adds a "ball" object and a camera, specifying a ClearColor on the camera of RGBA(128, 192, 255). The "ball" object is rendered to a texture and the test attempts to pick a clear pixel at [0,0] and also a point at the position of the "ball" object, expecting to not find a pixel with the ClearColor.

When the high DPI display is set to 200% magnification, the height and width in Duality.Drawing.PixelData.cs are calculated with raw pixels instead of scaled pixels. This results in an overrun of Duality.Drawing.PixelData.data because line 74 is multiplying the y coordinate against the unscaled width.

Similarly, when the high DPI display is set to 150% magnification, the height and width in Duality.Drawing.PixelData.cs are calculated with raw pixels instead of scaled pixels and while the overrun is avoided, the test fails because the test expects top pick a color on the "ball" object but picks a ClearColor instead. I expect this is because the lack of compensation for the magnification is not taken into account when either displaying or picking and the pick misses the ball object by the amount the display is scaled.

In researching how to modify the OpenTK backend to accommodate the scaling issues, I ran into a dead end with this being a known issue with OpenTK and SDL:
opentk/opentk#47
https://bugzilla.libsdl.org/show_bug.cgi?id=3281

Attachments

• Logfiles (if available)
  150Pct-Magnification-Log.txt
  200Pct-Magnification-Log.txt