Can confirm this bug still exists in 3.3.0
version: 3.3.0 Alpha, branch: master, commit date: 2022-06-21 08:10, hash: ee78c860b8aa, type: Release
build date: 2022-06-21, 12:12:39
platform: 'Linux-5.17.15-1-MANJARO-x86_64-with-glibc2.35'

But I can reproduce difference in color strip animation when scene strip is enabled/disabled, so I guess this would be enough to investigate.

@forceengine Yes I can check on Linux, but not really debug at least easily. But since you report different OS to be working correctly which implies different settings, can you check if you have disk cache enabled on Linux installation and if issue will happen when you disable it?

In T98287#1363806, @Richard Antalik (ISS) wrote:

I don't understand how can I see the issue from provided still frame in comment above - what frame number is that? Looks like frame 61, which is what I see in preview. Is that incorrect?

If I can reproduce on windows, it would help a lot, because I don't have linux machine with dev environment set up.

I can reproduce the issue. What seems to be happening is that the red color strips have animations that sometimes gets evaluated at the active scene frame and sometimes gets evaluated at the frame of the scene of the scene strip of the clock.
While they should always be evaluated at the frame of the active scene as far as I can tell.

I am checking on Windows, so this could be the reason for me not being able to reproduce. From videos in description it looked to me that issue is flickering of animated color strip. I don't understand how can I see the issue from provided still frame in comment above - what frame number is that? Looks like frame 61, which is what I see in preview. Is that incorrect?

In T98287#1362823, @Omar Emara (OmarSquircleArt) wrote:

It seems the file does not include the images necessary to make the clock, so I can't exactly replicate the sequence. Can you pack into the file or attach the necessary images?

I often see errors mentioned above, but these do not affect image output.

It seems the file does not include the images necessary to make the clock, so I can't exactly replicate the sequence. Can you pack into the file or attach the necessary images?

Somehow strange to declare an obvious malfunction not as a bug... )-;
it's just not doing what it is supposed to do...

Talked to @Sergey Sharybin (sergey), this is not considered a bug for now, but might see improvement in the near future (in that it is appealing to handle plane track differently here in concert with mask handles).

Hm, OK so the reason this happens is that the handles are set to type Auto, and if these are set to Auto, well... they are recalculated even after the plane track matrix has been applied to them, see https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/mask_evaluate.c$898

Ah, get it now, it snaps into place when such a handle is transformed.

On a glance seems fine.

Yes.

The patch affects the DSE selection behavior for all keys (masks, actions, grease pencil). IIRC, it was for consistency between the action editor modes.

@Sergey Sharybin (sergey): not 100% sure the above would be covered by your intentions?

@Philipp Oeser (lichtwerk) this is a case use:
using a second mask in the merge substract mode

From the example above the "meaning" of spline and feather will "flip": area inside feather spline will be white, and wade-out to the mask spline.
This is something we will be working towards to, but until then it is a known limitation.

How would it behave then?

This is a known issue and will hopefully be solved soon (-ish). Talked to @Sergey Sharybin (sergey) about it last weekend.

CC @Sean Kennedy (hype)
CC @Simon Lenz (Amudtogal)
CC @Sebastian Koenig (sebastian_k)

Why is this tagged with Masking ?

Actually I am unsure about the usecase of switching direction on a mask.
Is this useful at all? What for?
Without knowing this, it is kind of hard to judge if the feather should turn "inwards" when switching direction.
(this already sounds like it would be better to not do?)

Ah, indeed we need to return original layer and spline.

TODO: show media and change to design task. Make a patch for the simpler alternative that just fixes the issue that does not require further design considerations.

In D14598#391803, @Sergey Sharybin (sergey) wrote:

Not sure why the original layers and points are used at all. Is it possible to "just" use evaluated layers and points?

Not sure why the original layers and points are used at all. Is it possible to "just" use evaluated layers and points?

This sounds great! All of those are wonderful improvements. Is this in daily builds yet? Any way for a non-compiler like myself to try it out?

I very much like this proposal and think it could solve some usabilty issues!
Feedback from others would be appreciated though. @Sean Kennedy (hype) thoughts? :)

Here are a few more ideas: