drag-to-pan usually gets stuck

[0ion9]

I have drag-to-pan bound as suggested in input.conf:

MBTN_RIGHT script-binding image-viewer/drag-to-pan

Usually this binding does not work -- ie. rightclicking or rightdragging doesn't do anything visible. However, operating the mousewheel to zoom in/out and then quickly rightdragging allows drag-to-pan to work. After that one operation, I must again perform the mousewheel -> drag dance if I want to pan again.

My conclusion is that cursor-centric-zoom (or a sideeffect of it) sets some part of mpv state in a way that allows drag-to-pan to work, but this state 'times out' (maybe something that is automatically reset by MPV). Reading the code, the only idea that occurs to me is the table["event"] == "down" check.

'pan follows cursor', which makes the same check, doesn't appear to work correctly, but fails in a slightly different, more usable way (it works as a oneshot operation that, as soon as the click comes in, takes the relative mouse position within the window as the point within the image to pan to, eg. clicking 0,0 in the window pans to the top left of image and the operation immediately ends)

MPV event API has changed in some subtle way, perhaps?

EDIT: it's also worth noting that other mpv scripts using dragging work completely normally -- eg, mpv_crop_script. I haven't yet found another script that tries to bind dragging directly (rather than within a distinct mode), but if you know of one, I'm happy to test it.

EDIT2: You'd think that 'window-dragging' might impact this, but window-dragging=yes or no, neither have any effect on the problem.

EDIT3: That's enough debugging for a bit. My current best guess is that there is some other valid state for table["event"] that should be caught.

mpv version: 0.29.0-75-gda1073c247

[occivink]

I just tried it with master and it works as expected. You may be right with your guess that the 'complex' key binding is not fully reported, the manual mentions that it's a possibility (https://mpv.io/manual/master/#lua-scripting-complex). Which platform are you on?

Actually judging by the symptoms it looks like it's the mouse_move keybinding that does not work, but it's used by the osc so I can't imagine that being not reliable.

Can you try this short script, and report what it prints to the console? Just move the mouse around and press the right mouse button.

utils = require "mp.utils"
mp.add_forced_key_binding("mouse_move", "test_move", function()
print(mp.get_mouse_pos())
end)
mp.add_forced_key_binding("MBTN_RIGHT", "test_press", function(event)
print(utils.format_json(event))
end, {complex=true})

[jgreco]

I don't know if it's related to 0ion9's troubles, but for me drag-to-pan typically only works if the initiating click is in the upper left quadrant of an image. If the image is zoomed such that the lower right corner of the image is in the upper left of the window, then I can click there to drag and the drag will follow across the full extent of the screen, but initiating drags in the lower right of the window doesn't work.

I've been meaning to investigate this more, but haven't gotten around to it yet. Maybe it's unrelated but if so it suggests to me there might be something quite screwy going on in mpv's handling of these sort of mouse events.

(this is on OSX for me)

[occivink]

Ok I was just testing around and it seems like the OSC is intercepting mouse movement, such that the script never gets the events. @0ion9 can you confirm that you have the OSC enabled, and whether disabling it (osc=no) fixes it?
@jgreco also it only seems to capture events in the bottom half of the window, is that what you're referring to?

I'm not sure if there's a better fix for it

[jgreco]

@occivink I can confirm, the OSC being enabled seems to be responsible, at least for my problem. Thanks.

[jgreco]

I'm not sure if there's a better fix for it

As a work-around to the OSC intercepting mouse events, in my branch of mpv-image-viewer I've added a line to disable the OSC when an image is loaded using script-message osc-visibility never: jgreco@402466a

This is basically the equivalent of osc=no in mpv.conf, as recommended. Disabling the OSC seems like a perfectly adequate fix to me since the OSC isn't very useful for images. Though maybe a comment could be added to that config option explaining that the OSC interferes with mouse events.

[0ion9]

The output of that seems sensible to me -- coords vary continously as I move, and button press reports a down then an up.
pastebin link -- 440+ lines

EDIT: aah, suddenly comments.. Hold on, I'll try to check the OSC. I do want OSC for movies (and maybe animated gifs..) so your solution sounds good jgreco.)

EDIT2: No. OSC was already off, and turning it on doesn't make things any worse either.

EDIT3: Stripping down mpv scripts, this appears to actually be caused by easycrop.lua (which does bind mouse_move immediately, which seems incorrect to me -- should be bound only after the invocation keybind is pressed.). No problem, mpv_crop_script is generally better, so I shouldn't have left easycrop in anyway.

BTW: osc=yes is still way better than original conditions for me -- when OSC is up, drag is somewhat impaired, when it's hidden, drag is normal.

Configuring OSC minmousemove option to be much higher (default is 0) might be useful here. I can't tell yet whether 'deadzonesize' is also relevant.

@jgreco:
MPV does handle Animated PNG files, which inconveniently also have the extension png that you've marked as 'image'. Checking the frame count will probably detect those.

EDIT4: Increasing deadzonesize to 1.0 seems to be effective in preventing OSC interference. I also set minmousemove to 100, but this might be too insensitive.

[sammoth]

Not sure if this is related to the issues in this discussion, but when I click to drag or scroll to zoom using the features of this script, it will not work correctly unless the mouse has moved at least 1 pixel over the mpv window since mpv started. If it hasn't, the drag will move the image suddenly out of frame, and the zoom will always be centred on the top left corner of the image. I assume that when the mouse hasn't been moved, mpv doesn't pick up the actual position of the mouse on startup?

[occivink]

Yeah, I wasn't aware of this but it looks like mp.get_mouse_pos() reports a bogus 0, 0 if you haven't moved the mouse yet. A solution to that would be for mpv to initialize the mouse position to INT_MIN, INT_MIN or something.
If it really matters to you you can report a bug to mpv or even submit a PR.

[dumblob]

I am now testing mouse pan with both osc=no and osd-bar=no and it works perfectly in a fullscreen view (f by default in mpv). But once I switch from fullscreen to windowed (again by pressing f) the panning by mouse does not work any more and instead it moves the whole window without changing its content.

Anybody any ideas how to fix this?

[butteria]

@dumblob the whole window? to me, right-click doesn't work just like what metioned above, you can try to bind the function with 'ctrl+MBTN_RIGHT' instead of 'MBTN_RIGHT', or add this code 'mp.commandv("script-message", "osc-visibility" ,"never")' before 'mp.add_forced_key_binding("mouse_move", "image-viewer-mouse-move", function() moved = true end)'. i fix it but i don't know the reason. maybe it's the confliction betwenn bulit-in mouse button and osc. because i use 'h' to trigger the funtion and it works too.

[dumblob]

@butteria I forgot to mention I have tested panning with MBTN_LEFT script-binding drag-to-pan in input.conf.

Now I have tried it with MBTN_RIGHT script-binding drag-to-pan and it works as expected even in a non-fullscreen window.

Therefore I would call this (and similar) a special bug as mpv seems to harcode some behavior of certain keys (be it on mouse or keyboard or combination thereof).

Any ideas how to circumvent this "buggy" behavior? I would appreciate even very hacky solutions or workarounds 😉.

[dumblob]

Note that mp.commandv("script-message", "osc-visibility" ,"never") trick should not apply to my case as I have disabled osc altogether by osc=no in mpv.conf.

That said I have tried this trick and it does not change any of the behavior I was observing without this trick. Thanks anyway @butteria .

Any other ideas?

[dumblob]

Finally I found out that window-dragging=no in mpv.conf (or --no-window-dragging on command line) disables moving the window and thus allows the panning to work also in non-fullscreen mode. So my problem is solved 😉.

Thanks everyone for your help!