Fix tracking slide zones are not intuitive under certain UI scale/zoom #119971

Sergey Sharybin · 2024-03-27T17:55:48+01:00

Sergey Sharybin commented

2024-03-27 17:55:48 +01:00

This is a regression caused by some previous refactor of the code,
which was preparing it for transition to a tool-based tracking
workflow. Some of the hot zones got tweaked, and a change in the
behavior was done so that when click happens far away from any
slidable marker "widget" all markers gets de-selected (which
matches behavior in 3D viewport).

The pixel tolerance did not apply UI scale factor, and applied
zoom level after squaring (which is wrong calculation of pixel
space in screen space).

This is a regression caused by some previous refactor of the code, which was preparing it for transition to a tool-based tracking workflow. Some of the hot zones got tweaked, and a change in the behavior was done so that when click happens far away from any slidable marker "widget" all markers gets de-selected (which matches behavior in 3D viewport). The pixel tolerance did not apply UI scale factor, and applied zoom level after squaring (which is wrong calculation of pixel space in screen space).

Sergey Sharybin added 1 commit 2024-03-27 17:55:58 +01:00

47459e6ca3 WIP: Fix #119773 : Tracking slide zones are not intuitive

This is a regression caused by some previous refactor of the code,
which was preparing it for transition to a tool-based tracking
workflow. Some of the hot zones got tweaked, and a change in the
behavior was done so that when click happens far away from any
slidable marker "widget" all markers gets de-selected (which
matches behavior in 3D viewport).

The pixel tolerance did not apply UI scale factor, and applied
zoom level after squaring (which is wrong calculation of pixel
space in screen space).

Sergey Sharybin referenced this pull request

2024-03-27 17:57:31 +01:00

Regression: Error in tracker correction #119773

Germano Cavalcante commented

2024-03-27 19:29:06 +01:00

I didn't notice a difference.
The main behavior reported there was that before (3.4), with LMB type selection, you could select within the search region and drag to move the entire marker.
It wasn't exactly like that, but from the size of the previous threshold, it seemed like it worked like that.

Idealizing the selection, in my opinion, it should follow this list of priorities when selecting:

Active marker search gizmos (drag to move or scale search area)
Active marker 4 track points (drag to move a track point)
Active marker rotate gizmo (drag to rotate marker)
Active marker center (drag to move marker)
Non-active markers (select through centers or edges of the markers)
Active marker search area (drag to move all the marker)
Box Select

I didn't notice a difference. The main behavior reported there was that before (3.4), with LMB type selection, you could select within the search region and drag to move the entire marker. It wasn't exactly like that, but from the size of the previous threshold, it seemed like it worked like that. Idealizing the selection, in my opinion, it should follow this list of priorities when selecting: 1. Active marker search gizmos (drag to move or scale search area) 2. Active marker 4 track points (drag to move a track point) 3. Active marker rotate gizmo (drag to rotate marker) 4. Active marker center (drag to move marker) 5. Non-active markers (select through centers or edges of the markers) 6. Active marker search area (drag to move all the marker) 7. Box Select

Sergey Sharybin commented

2024-03-28 10:39:43 +01:00

The main behavior reported there was that before (3.4), with LMB type selection, you could select within the search region and drag to move the entire marker.
It wasn't exactly like that, but from the size of the previous threshold, it seemed like it worked like that.

That was never really an intent as far as I remember. And for moving forward with the tool behavior we are intending to (in the tracking_tools branch) we can not treat the entire search area as intractable region. The reason for that is because the most powerful tool for tweaking has a behavior of "tweak existing markers by nudging their drag zones, or when clicked in the middle of nowhere place a new marker".

So from this perspective we can not go back to the behavior of 3.4, and can not implement the point 6 from your algorithm.

What we can do, however, is to make it so interacting with the draggable zones which are drawn (those little squares) is as intuitive as possible, and does not lead to situations when actual "hot zone" is smaller from what it is drawn.

P.S. The Blender keymap (with RMB selection) is the one which was the most tested and used by the VFX module, and the behavior of it is closest to what so was agreed on. And it never treated an entire search area as an intractable region.

> The main behavior reported there was that before (3.4), with LMB type selection, you could select within the search region and drag to move the entire marker. > It wasn't exactly like that, but from the size of the previous threshold, it seemed like it worked like that. That was never really an intent as far as I remember. And for moving forward with the tool behavior we are intending to (in the `tracking_tools` branch) we can not treat the entire search area as intractable region. The reason for that is because the most powerful tool for tweaking has a behavior of "tweak existing markers by nudging their drag zones, or when clicked in the middle of nowhere place a new marker". So from this perspective we can not go back to the behavior of 3.4, and can not implement the point 6 from your algorithm. What we can do, however, is to make it so interacting with the draggable zones which are drawn (those little squares) is as intuitive as possible, and does not lead to situations when actual "hot zone" is smaller from what it is drawn. P.S. The Blender keymap (with RMB selection) is the one which was the most tested and used by the VFX module, and the behavior of it is closest to what so was agreed on. And it never treated an entire search area as an intractable region.

Germano Cavalcante commented

2024-03-28 13:09:37 +01:00

RMB selection also presentes the same behavior.
It might not be intentional, but it's a pretty noticeable change:

3.4	Patch

I'm not very familiar with the workflow to Movie Clip, if it wasn't intentional and doesn't bring many advantages, the new behavior seems fine for me.

RMB selection also presentes the same behavior. It might not be intentional, but it's a pretty noticeable change: | 3.4 | Patch | | --- | --- | | ![3_4.gif](/attachments/925c8641-aa9c-4f44-822f-bc5a783f3e18) | ![4_2.gif](/attachments/dc13a57f-b0cc-4e21-8466-fa88570bd021) | I'm not very familiar with the workflow to Movie Clip, if it wasn't intentional and doesn't bring many advantages, the new behavior seems fine for me.

4_2.gif

266 KiB

3_4.gif

481 KiB

Sergey Sharybin commented

2024-03-28 16:28:22 +01:00

Ah, I was talking about LMB click-drag with RMB selection setting. RMB click-drag with RMB selection indeed used to behave the way you describe. And that is what is no longer behavig the same. It kind of similar to using click-drag transform of plane in 3D view: for markers in 3.4 it was similar to click-drag transform of solid plane, and now it is more similar to click-drag transform of plane with Wire shading (where initializing click-drag from inside of plane actually deselects everything).

I don't rememeber explicit decision on this behavior, will check with the artists in the module.

Until then it would be nice to fix things which we know do not behave to their expectations. To me one of such things is the behavior of dragging the drag zones (the squares and triangles, which, depending on a zoom level would not initiate proper interaction). With this patch to me the situation seems much more intuitive about the drag zones. But would be nice if someone who is not on retina display can verify that the issue is better (or, at least, not worse).

Ah, I was talking about LMB click-drag with RMB selection setting. RMB click-drag with RMB selection indeed used to behave the way you describe. And that is what is no longer behavig the same. It kind of similar to using click-drag transform of plane in 3D view: for markers in 3.4 it was similar to click-drag transform of solid plane, and now it is more similar to click-drag transform of plane with Wire shading (where initializing click-drag from inside of plane actually deselects everything). I don't rememeber explicit decision on this behavior, will check with the artists in the module. Until then it would be nice to fix things which we know do not behave to their expectations. To me one of such things is the behavior of dragging the drag zones (the squares and triangles, which, depending on a zoom level would not initiate proper interaction). With this patch to me the situation seems much more intuitive about the drag zones. But would be nice if someone who is not on retina display can verify that the issue is better (or, at least, not worse).

Germano Cavalcante commented

2024-03-28 23:30:30 +01:00

Test again but I don't notice any difference. Not even at the selection threshold (it looks the same).

But one thing I noticed, which may not be intuitive with RMB selection, is that, when clicking and dragging on any "selectable" point, the marker will move (independent of the gizmo). But if you click and drag a visible but not selectable part, nothing happens.

In 3.4, clicking and dragging on these parts also moved the marker.
The fact that it no longer moves can be considered a regression.

Test again but I don't notice any difference. Not even at the selection threshold (it looks the same). But one thing I noticed, which may not be intuitive with RMB selection, is that, when clicking and dragging on any "selectable" point, the marker will move (independent of the gizmo). But if you click and drag a visible but not selectable part, nothing happens. ![GIF.gif](/attachments/8e98f925-01b7-430c-abd8-612d1472468f) In 3.4, clicking and dragging on these parts also moved the marker. The fact that it no longer moves can be considered a regression.

GIF.gif

360 KiB

Sergey Sharybin changed title from ~~WIP: Fix #119773: Tracking slide zones are not intuitive~~ to Fix tracking slide zones are not intuitive under certain UI scale/zoom

2024-03-29 11:31:09 +01:00

Sergey Sharybin commented

2024-03-29 11:36:47 +01:00

Test again but I don't notice any difference. Not even at the selection threshold (it looks the same).

Ok, thanks for testing. I've reduced the scope of the PR, and retitled it. To me it does fix some confusion with retina and UI scale of 1.25. So think it is still good to land, even if it does not have affect on all possible configurations.

But one thing I noticed, which may not be intuitive with RMB selection, is that, when clicking and dragging on any "selectable" point.

Please be more specific when describing such situations, as it is not clear from the GIF. Is it RMB selection and RMB click-drag, or RMB selection and LMB click-drag?

Also, the recording with the patch applied?

> Test again but I don't notice any difference. Not even at the selection threshold (it looks the same). Ok, thanks for testing. I've reduced the scope of the PR, and retitled it. To me it does fix some confusion with retina and UI scale of 1.25. So think it is still good to land, even if it does not have affect on all possible configurations. > But one thing I noticed, which may not be intuitive with RMB selection, is that, when clicking and dragging on any "selectable" point. Please be more specific when describing such situations, as it is not clear from the GIF. Is it RMB selection and RMB click-drag, or RMB selection and LMB click-drag? Also, the recording with the patch applied?

Germano Cavalcante commented

2024-03-29 12:59:24 +01:00

The last GIF shows RMB click-drag with the patch applied.

Sergey Sharybin referenced this pull request

2024-04-08 15:33:16 +02:00

Regression: Error in tracker correction #119773

Sergey Sharybin added 1 commit 2024-04-22 14:37:35 +02:00

0cdb73aff7 Merge branch 'main' into fix_119773

Sergey Sharybin merged commit a48f685e2e into main

2024-04-22 14:44:52 +02:00

Sergey Sharybin referenced this issue from a commit

2024-04-22 14:44:53 +02:00