cklosters
commented
1 year ago Bug 1: When dragging the app window to a newly connected monitor, the GUI become unusually large.
start up the Hello World demo without the secondary display connected
connect the secondary display
drag the app window to the secondary displayI don't consider this to be a bug because the system is unaware of the DPI of the new connected display. Display information is gathered only on start-up of the render service, including display DPI and scaling, which is used for computing independent scaling factors per display. If a new display is connected at runtime, it is not indexed because the runtime environment is not notified of a new connected display. Therefore the current scaling factor will be applied, if I'm not mistaken. I looked into a callback when a display is connected - disconnected, but couldn't find a good cross platform solution.
If you want to see what's going on, put a breakpoint in IMGuiService::onWindowEvent(const WindowEvent& windowEvent).
Bug 2 (only on MacOS): The size of ImGUI windows is much larger in relation to the app window on the secondary/lower resolution display. This is especially a problem when the ImGUI window gets larger than the app window itself: in this case it becomes impossible to manually resize the ImGUI window.`This looks related to ImGUI, not NAP specific, because the scaling works for individual elements and the text. From what I can tell, ImGUI doesn't scale the window coordinates based on the newly calculated GUI scaling factor for that display. Unfortunately I can't repro this because I don't have a mac computer with 2 displays (retina & regular). You can try and debug the situation by putting a breakpoint in void IMGuiService::onWindowEvent(const WindowEvent& windowEvent) and take it from there.
Note: you should be able to resize the window by dragging it up / left until you find the resize handle.
Bug 3: When placing the app window around the halfway point between the secondary display and the first display, the GUI becomes unusually large:When a window is moved NAP uses SDL to find the display that contains the window. It either belongs to window X or Y, based on the center of the window. From the SDL documentation:
Returns the index of the display containing the center of the window on success or a negative error code on failure; call [SDL_GetError](https://wiki.libsdl.org/SDL_GetError)() for more information.
We don't partially scale windows, and I don't know of many apps that do. So depending on where you position your window, NAP will use the scaling factor of window X or Y. I therefore do not consider this to be a bug.
Hi NAP team!
We found a few issues related to the DPI-dependent GUI scaling in NAP 0.5. The bugs below were encountered when using a high resolution primary display (Retina or 4K) and a lower resolution secondary display (Full HD). This is a situation that is relatively common for our users (who might use an external display with their MacBook). The bugs have also been reproduced on Windows unless noted otherwise.
Bug 1: When dragging the app window to a newly connected monitor, the GUI become unusually large.
Bug 2 (only on MacOS): The size of ImGUI windows is much larger in relation to the app window on the secondary/lower resolution display. This is especially a problem when the ImGUI window gets larger than the app window itself: in this case it becomes impossible to manually resize the ImGUI window.
After starting up the Hello World demo:
After dragging the app window to the secondary display:
Bug 3: When placing the app window around the halfway point between the secondary display and the first display, the GUI becomes unusually large: