Page MenuHome

Clip random marker placement in track/mask - not working in 2.8
Confirmed, NormalPublicBUG


System Information
Windows 10 x64 with nVidia 1080

Blender Version
Broken: 2.80, 2.83 @ be8879718e24e417d299eb298b8a9d4d2ca324ee
Worked: 2.79 (because there was no collapsible floating redo panel)

It's impossible to add a mask (or tracking) using ctrl+left-click in the clip editor.

Exact steps for others to reproduce the error

  • Open the above blend file, or:
    • Start Blender in factory settings.
    • Add a VFX → Motion Tracking workspace.
    • Load a video file into the clip editor.
  • Ctrl+Click in the clip editor to add a marker.
  • Open the redo panel.
  • Ctrl+Click in the clip editor to add a marker, and see that the marker appears at an offset.
  • Ctrl+Click again and see that the position is now correct.
  • Close the redo panel.
  • Ctrl+Click in the clip editor to add a marker, and see that the marker appears at an offset.
  • Ctrl+Click again and see that the position is now correct.

Event Timeline

Philipp Oeser (lichtwerk) lowered the priority of this task from 90 to 50.

With current 2.8 I am not getting this with tracking markers (although the very first seemed to be off), but consistently with masking points.
Has to do with pixel size / UI scale [only happens when I change this in the User Preferences].

Think I can find a fix...

Well, maybe I spoke too soon (regarding finding the fix).

I assume this is related to the HUD/redo thingie somewhat messing with the region size.
To recap: as of rB4722003ca539 it is not as bad as in the video anymore.
What I am seeing now is that the first click goes fine, the second is off, third click and everything after is fine again.

And I can only trigger this if Display Scale in User Preferences is not 1 (1.02 is enough though to make the second click go way off...)

What can be observed is that (I checked in ED_space_clip_get_zoom()and whats returned in ED_clip_point_stable_pos()):

  • ar->v2d.cur values are different for two clicks in the same position (when UI Scale is 1.02)
  • ar->v2d.cur values are the same for two clicks in the same position (when UI Scale is 1.0)
// with UI Scale
ar->v2d.cur 0.029661 0.626059 0.234463 0.673258
ED_clip_point_stable_pos zoom 1.000000 1.000000
ar->v2d.cur 0.000000 1.126000 0.220861 0.686861
ED_clip_point_stable_pos zoom 0.529661 0.941619

// without UI Scale
ar->v2d.cur 0.021716 0.634004 0.233522 0.674200
ED_clip_point_stable_pos zoom 1.000000 1.000000
ar->v2d.cur 0.021716 0.634004 0.233522 0.674200
ED_clip_point_stable_pos zoom 1.000000 1.000000

note: CLIP_OT_add_marker_at_click is always OK (but thats probably because it has no redo and thus no HUD for redo)

@Campbell Barton (campbellbarton) : you were active for the HUD (and I also remember commits regarding the action zones coming in the way - which might be related), could you have a look?

What I noticed is that if the mouse cursor is near the left side of the clip window (the pane itself, not the video clip, you can zoom out and have a really small video clip in the pane to exaggerate this) then the markers are placed at the left side of the video clip. This tends to drift away as you move the mouse cursor to the right.
I would guess that the placement is based on the pane's boundaries (and has some scale factor) and not the actual clip's boundaries.

I've been playing a bit (with the latest build) and I noticed that the problem tends to go away whenever you fold the contextual "Add Marker and Slide" overlay, and returns whenever you unfold it back.
To clarify what I'm talking about I took a short video:

Hi, it's my understanding that the community is gearing up towards a 2.8 beta release and I was wondering if there is any insight regarding this issue?
I'm asking because without tracking or masking, the video editing module has a very limited usability. I did notice (in my recent video above) that the problem goes away whenever you fold the contextual window, and returns whenever you unfold it - so it's probably related to it somehow.
Video showing how the problem disappears and reappears

I tried it with several configurations, but couldn't reproduce it. Toolshelf and Sidebar expanded or collapsed, floating panel expaneded or collapsed, fullscreen or not - I could not reproduce this bug in any case. I am on Linux though. Might be a Windows bug?

@Sebastian Koenig (sebastian_k): You should be able to reproduce with User Preferences > Interface > Display Scale other than 1.0?

Ah indeed. Can only reproduce with mask points though as well, not with tracking markers.

Tzvi (zvi8) added a comment.EditedNov 28 2018, 8:18 PM

Well, I'm using the Windows x64 build of Blender 2.8 (running on windows 10 x64). This behavior perfectly reproducible (as my videos show) - but it does not happen with the 2.7.
It occurs with both masks and tracking markers in my case. Also checked my "Display Scale" - it is set to 1.00
Are there any useful logs I can enable and provide to debug this?

On a hunch, I decided to test one more thing!
I use a dual monitor desktop, my primary is a 4K display and my secondary is a 1080p display.
This problem manifests itself on the 4K display but when I drag Blender into the secondary display and set it to full screen, everything works as expected. Dragging back to the 4K display it goes awry again.

I know that Windows has internally some "scale" factor, because when I drag applications from primary to secondary they rescale themselves accordingly. (otherwise the fonts would appear too large/small)
Can this be responsible to the coordinates drift?

Tzvi (zvi8) added a comment.EditedDec 23 2018, 1:03 PM

Hi Sebastian. I understand you were able to reproduce the issue as well, have you found the cause for the tracking markers not working?
Mind you, I have "Display Scale" set to 1.0 - however it's possible that since I have dual 4K + FHD monitors that Windows presents its own scaling factor?

I have created a new video showing exactly how it behaves strangely on mu dual monitor Windows machine.
Video demonstrating the issues

Also attached a screenshot showing the Blender and Windows scaling factors.

Philipp Oeser (lichtwerk) changed the task status from Unknown Status to Resolved.Dec 28 2018, 11:24 AM

I believe this was fixed by rBe5e885d0ecb9430a73e0a904cdb6035a2ef77e98?
As of today (rBfdc726eb61d15a51d8deddcb6b7b79859ea9950e) I am not able to reproduce this anymore...

Marking as resolved, please everyone, feel free to comment again or reopen if issues persist...

Tzvi (zvi8) changed the task status from Resolved to Unknown Status.Dec 29 2018, 7:01 AM

Hi, excellent work! It seems that this commit fixes it almost entirely!
However, there's still one case where this behavior persists. Whenever the floating panel is collapsed, the first click afterwards still places a marker at an offset. All the following markers are placed correctly.
This indicates that there is still an issue lurking in there.
Here's a quick video demonstrating it.

Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Bug".Tue, Feb 11, 11:32 AM

I can confirm this still happens on current master (rBbe8879718e24e417d299eb298b8a9d4d2ca324ee). Whenever the redo panel is opened or closed, the first Ctrl+Click will be in the wrong position.