I've mixed feelings on this approach:

• On one hand, this patch seems simpler, with less stuff needing to be modified.
• On the other hand, this duplicates functionality, while also regressing Blender back to an earlier design (i.e. the predecessor of the current modifier-based approach), along with all the flaws that that approach had.

After looking at this again, it's not actually as bad as I initially suspected.

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.

Without a test file to demonstrate the sitaution where it's "stuck", I can't say for sure what's going on in that case.

AFAIK, nothing should be touching anything there. Or at least, that particular setting shouldn't be getting cleared explicitly.

IMO, if we *do* add a button for this (and there are valid arguments to be made in favour of that, W.R.T general UX best practices) I'd lean towards making it a simple X in the corner of the splashscreen.
However, as currently proposed, this just adds clutter.

This sounds like it's probably a general Windows bug - perhaps a strange combination of disk driver, internal caching/background threads, and/or potential interference from some third-party shell addon (e.g. dropbox, cloud sync, TortoiseSVN/Git, AV menu entries, etc.) is leading to a delay in things getting updated?

Oh? Does the scheduling now work around the problems where multiple drivers-needing-Py/GIL access causes issues/lockups in some other way?

Indeed, I'd be very surprised if this was related to T51971.

Is this only for the new depsgraph? Testing with the old depsgraph seems fine here.

Here's a first guess at what may be happening (without having checked the file or the Bake Action operator):
It's likely that because the pose gets evaluated again for each bone (in order to compute what effect the visual keying should have), the results of the previous bone in the chain (that got keyed first) will end up influencing the results for latter bones, causing drift in the results. IIRC, there are similar problems with certain operations for the IK constraint.

Looks like you've just got a messed-up Pose Library action.

Just to reiterate a note I made in the commit -- You'll need to manually click on the start and end frame properties of the Stepped FModifier to flush the relevant changes.

Strange... investigating now...

Good news! I just tested the f67c331 buildbot, and it's now possible to run 2.8 and play around with it if I enable the --debug-gpu flag first. However, just running it still segfaults.

In the "Grease Pencil Colors" panel, toggle the Ghost icon of the first item in the list. That toggle disables onion skinning for that color.

1. Woah! Since when did this change to that hideous alphabetical order?!
2. Nice + timely fix!

An update:
So this seems to happen when you move the keyframe past the other keyframes, triggering the keyframe sorting (sort_time_fcurve()) . Disabling that step solves the crash here, but is kindof undesirable in that the curve doesn't get resorted/recalculated.

I'm running into this bug as well with both the Grease Pencil branch (own build) and Buildbot (blender-2.80-f860369-win64.zip).

A small optimisation tip.

Hmm... it's a bit unclear atm what is intended here regarding what modes these will be available in. On one hand, it sounds like you're saying that facemaps will always be available in object mode, but then, in the next paragraph/section, you mention stuff about these activating corresponding bones and allowing tools like keyframing/breakdowner/pose-library/motion paths/etc. to be used as if the bone was selected.

Not a bug.

@Jason schleifer (jasonschleifer) @Luciano Muñoz Sessarego (looch)
You guys might be interested in testing this patch sometime ;)

In its current form, I do not think this patch is fit for inclusion. My main objections are:

1. It's not a good idea to be temporarily changing the context to do things that are not supported in the current context. Yes, it is the hacky way that many many scripts do it, but they do it due to limitations in the PyAPI. We should not however allow such tricks in the core code. If what you want to do isn't supported in the current context, you should delegate the task to be handled later by the correct context at a more convenient time when it is in scope instead (i.e. by sending suitable notifer flags)
2. In terms of the animation tools, it's incorrect to do it this way - What you're doing here is you're creating a temporary context that will use "default" filtering options. These can however be different to what the user actually sees in any animation editors they have open.

There are currently location + rotation keyframes on some of the objects (frames 0 and 33). Try removing all keyframes before fixing the position of all the objects.

One tip is to see if this only happens during particular times of the day. For instance, for years, the SVN/tracker/wiki sites were all slow from about 0200 UTC to 0600 UTC (or some subset of that) as the daily backups were running at those times. Of course, this may not be a factor here - I personally haven't seen it happen with the git server. Then again, I haven't had time to update in a while either ;)

From memory, last time we tried removing it, we ended up putting it back eventually as various studios were using it (including the institute). I'm not sure if anything's changed, but I suspect this is still very much the case. If anything, we should be padding it out to make it even more useful.

At least in the 3D view, there's also the option of just using Image Empties that can be manipulated in these ways. AFAIK, it seems quite similar to the "textured plane" approach you mention, except it's not really "real" geometry that hangs around. That said, I haven't really used these enough to tell if there are some serious downsides to doing this (or whether they're already considered the "better" way of doing this).

Thanks for helping narrow this down to a nice tidy window. It really helped looking for the cause. :)

This is very strange...

As I guessed before opening the file (and confirmed afterwards), it looks like you're running into several things here:

1. If you've got cyclic dependencies, expect to see errors if you do not strictly advanced the timeline in forward order, and/or if you ever cancel transforms.
2. The Transition track assumes that the channels you've got keyed on strips A and B both have the same set of channels to blend between.
3. Make sure that if there are some channels which you only key in a "later" occurring strip that you've got that property keyed in some low-down strip that spans the entire timeline. For example, to avoid trouble with controls glitching out (i.e. usually scaling to zero) you'll typically want to ensure that at the bottom of the stack you've got a "Rest Pose" strip that has a keyframe for the "default" value for every property you have/will keyframe anywhere in that NLA stack, and that this strip is set to extend forward and back.

This is a known issue that's on my todo list for when I get enough time to have another decent look at the NLA evaluation backend.

Technically, the old driver is still there, and should still work perfectly fine.

Doing this, I noticed that you have to zoom out the view at lot more to see the entire bone (when it is created using cm units). It looks like the bone isn't especially thin; it's more that the thickness doesn't automatically scale to match a 100 BU (i.e. 100 BU = 100 "cm", assuming 1 BU = 1 cm) high bone. In other words, BBone sizes are in absolute units (which are not adjusted to deal with the unit scaling stuff).

I looked into this a few weeks back, but only figured out what was going wrong when I saw one of the forums posts somewhere about this.

REVERT THIS!

The problem here is that your various clips have different framerates (i.e. 30fps for the screencast, 25fps for the camcorder, 30fps for the camera, and 26.57fps for the phone).

Hrm... this is strange indeed...

For example:

import bpy

Have you got 'Only Needed' enabled in the user prefs?

@Steffen Mortensen (stifan): Thanks for identifying the problem! Fixes committed to master now :)

I tested this again just now, and overall I think it should be fine to include :)

Indeed, this tool doesn't take NLA tweakmode into account (as it wasn't expected that people should/would be doing a lot of animating that way). But, with a few tweaks in a few places, it should be relatively easy to fix.