cfillion / reaimgui

ReaScript binding and REAPER backend for the Dear ImGui toolkit.
https://forum.cockos.com/showthread.php?t=250419
GNU Lesser General Public License v3.0
59 stars 9 forks source link

Mouse pointer misalignment in a multi-display Linux (sway) environment #16

Closed tkna91 closed 7 months ago

tkna91 commented 9 months ago

In my environment, the mouse pointer target is off as shown here and does not work properly.

Screencast:

https://github.com/cfillion/reaimgui/assets/102382754/7340079a-2630-4dec-87a8-de6421dbb5b9

This seems to occur in a multi-display environment. It did not occur in a single display laptop environment. What should I do?

Environment:

cfillion commented 9 months ago

Is ReaImGui up-to-date? Version 0.8.7.6 should have fixed this HiDPI bug on Linux. Extensions > ReaPack > Synchronize packages.

tkna91 commented 9 months ago

Sorry, I didn't notice. After the update, it was resolved. Thanks for the useful tool!

Screencast:

https://github.com/cfillion/reaimgui/assets/102382754/64d1ffb3-fca6-49f8-a819-20da53474ffe

tkna91 commented 7 months ago

I don't know when it started, but the mouse pointer still seems to shift when the window is initially opened. It stops shifting when the window is moved.

Screencast:

https://github.com/cfillion/reaimgui/assets/102382754/20f64ea5-46f7-4303-b6b6-3e4cd3f07717

cfillion commented 7 months ago

How are you moving the window? When I tried under Sway a few weeks ago, it rejected any attempts by ReaImGui to move its own windows and always placed them at the center of the screen. Probably because of the ongoing Wayland situation where global window coordinates aren't officially a thing.

Is there a setting to have Sway let ReaImGui decide where its own floating window are placed? Or did you use Sway's shortcut for moving windows instead?

From the video, it looks like Sway ignored ReaImGui's initial window placement request, so the actual window position doesn't match what ReaImGui thinks it is.

tkna91 commented 7 months ago

How are you moving the window?

The window should be able to be moved by holding down the $mod key (meta by default) and dragging.

Probably because of the ongoing Wayland situation where global window coordinates aren't officially a thing. Is there a setting to have Sway let ReaImGui decide where its own floating window are placed? Or did you use Sway's shortcut for moving windows instead? From the video, it looks like Sway ignored ReaImGui's initial window placement request, so the actual window position doesn't match what ReaImGui thinks it is.

Yes, as far as I know, there is no standard way (yet) for the software used in sway to remember and restore window locations. Based on the following, it appears that the specification is not yet fixed, even for Wayland as a whole.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264

I thought that when the Modal window positioning: option of REAPER is one of the following, it would not remember the absolute position of the window and prevent the mouse pointer from shifting, but so far this does not seem to be the case.

Screenshot:

20240404-015727_screenshot

Screencast:

https://github.com/cfillion/reaimgui/assets/102382754/e9cdaebb-7d4b-4a4c-9c9c-fbb91e6fee2e

Is it possible to not save the window position (so that the mouse pointer position is not shifted) by referring to the above option?

cfillion commented 7 months ago

I pushed a fix for the position desync after opening a window. Here's a build: reaper_imgui-x86_64.so and imgui.lua.

Based on the following, it appears that the specification is not yet fixed, even for Wayland as a whole.

Yeah, it's crazy to me that Wayland is still missing the very basic feature of letting applications move their windows. Dear ImGui expects to be in full control of the position of its windows across all monitors relative to a global 0,0px point like it is on Windows and macOS.

At least it seems that both KWin and Mutter allow that to some extent, so it's not an issue in KDE and Gnome. (I haven't looked into whether they implement some unofficial Wayland protocol extension or it's just a special exception for X11 apps like REAPER...) Although these two WMs insist on clamping windows to be fully within monitor edges instead of letting Dear ImGui do that itself, so it's not perfect either...

Is it possible to not save the window position (so that the mouse pointer position is not shifted) by referring to the above option?

Dear ImGui has its own way of saving and restoring window positions. It can be disabled by unchecking Preferences > ReaImGui > Restore window position, size, dock state and table settings. Or programatically via {Config,Window,Table}Flags_NoSavedSettings.

(Disabling that option would not help with this issue though, as Sway would still not let Dear ImGui place windows at the default position that it wants. Also WMs without floating windows or floating disabled.)

tkna91 commented 7 months ago

I checked with the following options for Modal window positioning:.

It looks fine.

Screencast:

https://github.com/cfillion/reaimgui/assets/102382754/89b25592-014a-4988-b97d-bb2021999791

tkna91 commented 7 months ago

There may be a problem with that newer version. Pressing down on the cursor key in the search results for nvk_SEARCH seems to cause an error.

ReaScript Error:

Data/scripts/search/data/results.dat:348: attempt to call a nil value (field 'ImGui_ListClipper_IncludeRangeByIndices')

ImGui Error:

(g.CurrentWindowStack.Size == 1) && "Mismatched Begin/BeginChild vs End/EndChild calls: did you forget to call End/EndChild?"

Screencast:

https://github.com/cfillion/reaimgui/assets/102382754/fe73f13a-cb68-424e-ae0d-10e7735b9509

tkna91 commented 7 months ago

Is it more of a problem with the sanitization of nvk_SEARCH ?

tkna91 commented 7 months ago

The following did not fix the problem.

  1. Rename ~/.config/REAPER/Scripts/nvk-ReaScripts/SEARCH/Data/scripts/search/data/results.dat
  2. Reinstall nvk_SEARCH

The results.dat:348 is bytecode so I don't know what is there. @NickvonKaenel What do you think?

tkna91 commented 7 months ago

I was able to decode the following.

$ luac -l -p results.dat | grep \\[348\\]
        203     [348]   GETTABUP        7 0 3   ; _ENV "r"
        204     [348]   GETFIELD        7 7 52  ; "ImGui_ListClipper_IncludeRangeByIndices"
        205     [348]   GETTABUP        8 0 48  ; _ENV "clipper"
        206     [348]   GETTABUP        9 0 16  ; _ENV "Results"
        207     [348]   GETFIELD        9 9 53  ; "Index"
        208     [348]   ADDI            9 9 -1
        209     [348]   MMBINI          9 1 7 0 ; __sub
        210     [348]   GETTABUP        10 0 16 ; _ENV "Results"
        211     [348]   GETFIELD        10 10 53        ; "Index"
        212     [348]   ADDI            10 10 1
        213     [348]   MMBINI          10 1 6 0        ; __add
        214     [348]   CALL            7 4 1   ; 3 in 0 out
$
tkna91 commented 7 months ago

@cfillion Even if it is not a newer version, simply disabling the following options you noted may solve the problem.

Screencast:

https://github.com/cfillion/reaimgui/assets/102382754/2dea35d9-35bf-4013-a3da-9fe1d1f34c6d

nickvonkaenel commented 7 months ago

Here's the relevant part of my code.

if not r.ImGui_ValidatePtr(clipper, 'ImGui_ListClipper*') then clipper = r.ImGui_CreateListClipper(ctx) end r.ImGui_ListClipper_Begin(clipper, #LIST, r.ImGui_GetTextLineHeightWithSpacing(ctx)) if Results.Focus then r.ImGui_ListClipper_IncludeRangeByIndices(clipper, Results.Index - 1, Results.Index + 1) end

I have not tested anything on Linux, so it's very possible there are errors.

tkna91 commented 7 months ago

Some scripts seem to require a new version to make the first click. Screencast:

https://github.com/cfillion/reaimgui/assets/102382754/e4214640-8ab5-4b0b-b4ef-6b322be58ab3

cfillion commented 7 months ago

@NickvonKaenel ListClipper_IncludeRangeByIndices is being renamed to _IncludeItemsByIndex in v0.9 (34d9a7dcb4224a9c272299af3e1b4cc8035c15b3). Is your script using imgui.lua to enable backward compatibility?

The current recommended snippet for public scripts:

local imgui_path = reaper.GetResourcePath() .. '/Scripts/ReaTeam Extensions/API/imgui.lua'
if not reaper.file_exists(imgui_path) then error('ReaImGui is not installed') end
dofile(imgui_path) '0.8.7' -- the version your script was written for

-- from this point, it's safe to use ReaImGui's API in reaper.* (of the version specified above only)

Improved snippet coming soon in v0.9 (the previous one remains supported obviously – this new one adds local per-file version for safe usage in libraries and faster call-less enums):

if not reaper.ImGui_GetBuiltinPath then error('ReaImGui is not installed or older than 0.9') end
package.path = reaper.ImGui_GetBuiltinPath() .. '/?.lua'
local ImGui = require 'imgui' '0.8.7'

-- from this point, it's safe to use anything in the ImGui.* table:
-- it contains the API of the specified version

-- call-less enums: ImGui.WindowFlags_None instead of ImGui.WindowFlags_None()
nickvonkaenel commented 7 months ago

Yeah before I use ImGui_CreateContext I'm calling dofile(r.GetResourcePath() .. '/Scripts/ReaTeam Extensions/API/imgui.lua') ('0.8.5') so that's interesting that it's not working

cfillion commented 7 months ago

Ah I see, the issue is that ListClipper_IncludeRangeByIndices did not exist in ReaImGui v0.8.5, it was added in v0.8.7.

Your script should either request API version 0.8.7 or use the old 0.5.10–0.8.6 name _ForceDisplayRangeByIndices.
...Or so I would normally say if that specific shim wasn't broken in the current release (256b2cbc38330cc7f400d14dd60738678b456892). (Nobody complained in over 6 months so I didn't bother doing a hotfix release.)

That one renamed function is the only breaking change between .5 and .7, so simply correcting the requested API version should work fine.

nickvonkaenel commented 7 months ago

Thanks, I'll get that fixed!

tkna91 commented 7 months ago

In the new version, this problem seems to be less likely to occur. https://github.com/swaywm/sway/issues/7974

After changing to the new version, the first launch puts the problem, but once closed and on subsequent launches, the ReaImGUI related z-ordering of windows no longer seems to be wrong.

Screencast:

https://github.com/cfillion/reaimgui/assets/102382754/548734f4-1b5b-4f9e-bb32-0b566913f3f7

Not that it doesn't happen, strictly speaking, probably due to causes other than the ReaImGUI, but the problem seems to have been greatly reduced insofar as I use it on a daily basis.

Screencast:

https://github.com/cfillion/reaimgui/assets/102382754/8210c0aa-2979-4efe-8228-c4b645da83bf