@William Reynish (billreynish) IIRC, you can use the type argument to it too.

My only concern with the marker-area approach for the time scrubbing thing is that it'll get a bit yucky when there are markers present (i.e. all the selection ambiguity problems). That said, Da Vinci Resolve does something similar (except AFAIK it doesn't have the markers to cause conflicts). It's also still more flexible this way than restricting to only click-dragging the line itself.

I'm guessing this is a duplicate of that bug where with multiple unkeyed values, only the first one to get keyed survives the updates post-keying.

@William Reynish (billrey) The main difference with what I was proposing was that you could set the buttons to jump more than a single frame at once (i.e. try setting the thing to 5, 10, or 20), whereas the buttons on the frame number are only really for going a single frame at a time.

Another proposal along the lines of what @Yevgeny Makarov (jenkm) proposed is to expose the jump-size setting (that we used to have in 2.4x IIRC, or more recently the thing in Pablo's addon) between the frame step buttons. So something like:

From discussions with various people over the years, we've all consistently come to the conclusion that all of these things should always be evaluated in radians only, since that's technically how Blender stores + uses all rotation values internally, and it's also what all the math/trig functions in every standard math library work.

What you're seeing here is actually an error code to indicate coordinates that are out of bounds - i.e. #define V2D_IS_CLIPPED 12000 (see UI_view2d.h:37)

Interesting, the FILTER_PART_OBJD(psys->part) in animdata_filter_ds_particles() seems to be borked. A quick workaround for now (if it's an urgent production issue) is to just short-circuit that check (i.e. replace with 1)

Yes, the ones in T60086 are pretty much the same issue (incorrect update tagging). IIRC, the logic for deciding when to tag is a bit borked right now - COW tagging only happens along with relations rebuild/update, and only when F-Curves get added/deleted, or something like that.

What's probably happening in this case is as follows:

1. First, only one of the changed properties got the new values keyframed. All the other changed (but unkeyed) values exist on only on the original datablock at this stage (as set directly by the property buttons)
2. After the first keyframing operation, the depsgraph gets evaluated. Most likely, this is because we tag it to do a copy-on-write flush (i.e. necessary or else the COW-domain data doesn't get refreshed to know that there is now a keyframe on the current frame, causing problems in the UI with the buttons not showing the right colors).
3. To deal with the problem of not being able to keyframe/frame-changed evaluated state values in various operators (e.g. clear transform operators, and a whole bunch of other ones), we introduced a "copy back" step to the depsgraph evaluation to flush the results of the animation evaluation back to the original SDNA data. This allows normal operators to see the depsgraph-evaluated results when simply querying the SDNA state.
4. This is where this bug in particular occurs: Normally there's a write-protection check performed (i.e. see https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/anim_sys.c$1619) that would prevent overwriting. However, here old_value (i.e. SDNA value, unkeyed above) != new_value (i.e. result of animation evaluation, from F-Curves that don't know about this new value, as they don't have keyframes in place to enforce that yet). Hence, the values from the F-Curves get flushed back to SDNA, overwriting the unkeyed values.

It's a known limitation IIRC.

Overall, I'm happy for this to go ahead.

Closing as "TODO" - a known limitation that the tools were not intended to support, but could in future when we have the time to do so.

Hmm... the bAnimViz ones can stay for now. If we restore such functionality, those will be the settings used. The ones on bArmature though are fair game.

Hmm... I didn't really recall adding this. A quick git blame shows that it was introduced in rBa80b7d612947e1d26b10165a37bb603dae527afd by @Bastien Montagne (mont29)

I'm leaning towards completely removing it (i.e. the armature specific ghosting RNA/Py/etc.)

This sounds like a graphics driver bug. I used to have similar issues about a decade ago on my old desktop that had integrated graphics (and it wasn't even one by Intel back then). The only solutions I found for that were:

1. Don't minimise Blender windows ever and/or don't keep Blender open if you're going to be away from the screen for a while (e.g. if the screensaver might pop up, or the machine might go into standby),
2. Save work before switching away from Blender,
3. Disable cursor shadows (this helped with some weird cursor flickering issues when moving over the UI, and also improved interactivity)

@Pablo Vazquez (pablovazquez) Could you recommend any files in particular with quite a few cache files present? I was looking for a test file so that I could check if the cleanups I had in mind would losing any functionality.

Yes, a new filter type for this case makes sense.

The plan here was initially that we'd move all the ghosting settings out of armature into the bAnimViz ones, so that, like Motion Paths, we could have the same set of functionality available for both Objects and Armatures/Bones. That is why they were marked as deprecated. (Unfortunately, within about a month of doing that, "Life" (TM) happened and I didn't get around to putting in place the necessary changes then)

Instead of the flag, it's probably way more future proof to just move to having an "endcap style" enum now - and possibly even having separate ones for start/end caps, as it's effectively inevitable that we'll have to change this.

LGTM

IMO, this is the wrong approach.

@William Reynish (billrey): Looks good. By and large, what you've got there makes sense - I particularly agree that we do want these different draw styles to be able to be turned on/off as needed; indeed it's something that some of the earlier mockups really drove home.

@Samir Osman (Samirosman): That's looking promising. However, as per my previous comments, it's unclear with some of these what frame exactly those things sit on. The arrow like ones are particularly bad in this regard, but to a lesser extent the square (constant) and circle are also not great.

@William Reynish (billrey) Nice idea. Personally, numbers 1 & 2 are the more promising ones there - on an aesthetic level, I like 1 more, but 2 probably communicates what's going on better (as the gradients make subtle differences harder to see). The only potential issue here is regarding performance, but as long as we don't care too much about accurately representing the transition between the keyframes (i.e. no sampling of the curves to find out what's going on, and just using some prebaked effects in fragment shaders) I think we can do it (in which case, 1 is actually more convenient to implement).

1. Looking it again today, I still have serious doubts about the legibility of these markings. They are almost impossible to distinguish and it's also hard to understand what exactly each symbol is trying to convey.

Thanks for the report. This is a known limitation that we've been trying to resolve for a few months now, due to some keymap conflicts. IIRC, we actually have a task open for this already - see T55420

Please follow our submission template and guidelines and make a complete, valid bug report,
with required info, precise description of the issue, precise steps to reproduce it,
small and simple .blend and/or other files to do so if needed, etc.

Note: Just confirmed that this is still happening in HEAD (4f06c7c8389d144394efdda8829f3d01283694d6)

@Clément Foucault (fclem) Assigning to our resident draw engine guru :)

@Charlie Jolly (charlie) Thanks, looks like an easy fix.

Note - rB939a5cb6eec adds the toolbar button for the Annotation tool, but for reasons currently unknown, the events don't seem to get fired correctly here.

Cannot reproduce (Win10, GTX1080Ti, 76ea32d192693ac0d46270dd30c7e50a0bfcea62)

Closing. I fixed it in another, much better way.

@Clément Foucault (fclem) Yep, this solves the crash here. UI draws normally, and Spring files can be loaded.