Incorrect cursor pos when `framebuffer_size/window_size` isnt an integer ratio

[gabe-lee]

TL;DR: zgui (Dear ImGui) rounds the ratio between the framebuffer size and the window size up to the next integer when calculating cursor collisions with gui elements, leading to a mismatch of true cursor position and gui collision when the true ratio isn't an integer value.

(This issue may be an upstream issue with Dear ImGui, but I was unsure so I'm adding here first)

I just got the triangle_wgpu demo up and running on my machine, Linux (Wayland) 2880x1800 res @ 1.75 screen scale

I immediately noticed zgui not calculating the mouse position correctly for the purposes of determining whether a gui element was hovered. The issue was less noticeable on the left side of the window and more extreme on the right side. I ran some tests and found that due to my Wayland screen scaling factor the mouse position that zgui (Dear ImGui) was reporting was way off.

Using the zgui demo window mouse pos and some debug prints I discovered an issue, results below.

1.75 Scaled Wayland, mouse top-left

   fb size = 2800x1400
  win size = 1600x800
 win scale = 1.75x1.75
 win mouse = 2x0
zgui mouse = 4x0

1.75 Scaled Wayland, mouse bot-right

   fb size = 2800x1400
  win size = 1600x800
 win scale = 1.75x1.75
 win mouse = 1600x397
zgui mouse = 3200x794

I then tweaked some settings to see if I could get a usable experience, and discovered that when the framebuffer was the same size as the window size, the mouse was exactly correct (at the cost of either an uncomfortably small gui or a blurry framebuffer due to rounding)

1.00 Scaled Wayland (or 1.75 scaled and zglfw.windowHintTyped(.scale_framebuffer, true);), mouse bot-right

   fb size = 1600x800
  win size = 1600x800
 win scale = 1.0x1.0
 win mouse = 1546x371
zgui mouse = 1546x371

I tried going up to 2.0 scaling and the issue was also fixed

2.0 Scaled Wayland, mouse bot-right

   fb size = 3200x1600
  win size = 1600x800
 win scale = 2.0x2.0
 win mouse = 1402x501
zgui mouse = 2804x1002

And finally I went up to 2.5 scaling, expecting the disparity to be in the other direction, but found the exact same problem as before at a larger scale

2.5 Scaled Wayland, mouse bot-right

   fb size = 2500x1250
  win size = 1000x500
 win scale = 2.5x2.5
 win mouse = 978x474
zgui mouse = 2934x1422

I then discovered that zgui or Dear ImGui was rounding up the scale factor between the framebuffer size and window size to the next integer, and using THAT scaled mouse position to determine gui collision, making it nearly unusable at any non-integer ratio between framebuffer and window size:

                   EXPECTED        |      ACTUAL
2.50 scaling: 978x  * 2.50 = 2445x | 978x  * 3 = 2934x
1.75 scaling: 1600x * 1.75 = 2800x | 1600x * 2 = 3200x

Screenshot: Scale 1.0, mouse bottom right

Screenshot: Scale 1.75, mouse bottom right

Screenshot: Scale 1.75, mouse top left

Screenshot: Scale 1.75, dragging gui left edge near left side of screen

Screenshot: Scale 1.75, dragging gui left edge near right side of screen

[hazeycode]

Thanks for the detailed report.

FWIW I'm not able to reproduce this on X11.

[gabe-lee]

Thanks for the detailed report.

FWIW I'm not able to reproduce this on X11.

Yeah, its my understanding that the only platforms that can have a fractional ratio between framebuffer and window are Wayland and MacOS.

For anyone that suffers from this issue, giving your GLFW window the hint:
zglfw.windowHintTyped(.scale_framebuffer, false);
can be a temporary workaround if you really want to use Dear ImGui. The downside is your framebuffer will be slightly blurry because it will have to round the pixels to the nearest true value.

[So1aric]

Would you like to upstream the issue to Dear ImGui?

[hazeycode]

Would you like to upstream the issue to Dear ImGui?

I don't think is an issue with imgui itself and we're a little bit behind the latest release which has fixes we probably want for the wgpu backend (we can't upgrade until we update zgpu to use a newer version of Dawn). These changes fix the issue with fractional DPI scaling on the glfw_wgpu backend.