Please follow our bug reporting guidelines and file this report in English.

This option only changes whether you can click and place the current frame indicator before frame 0.

Confirmed

I'm leaning towards removal of this too.

There are several things going on here:

1. There is a F-Curve on the 'nodes["Texture.005"].inputs[0].default_value' setting in the "Active Action" slot of the Compositing Node Tree. This is visible if you disable "Only Selected" in the Graph Editor

I'm currently still having to run blender via --debug-gpu, which makes things really slow. So, I decided to do a little more digging today (after setting up a dedicated copy of the 2.8/gp branches to avoid having to worry about so many leftover build files when changing branches).

Looks like this is another instance of T51521

Please include more information about the problem you're encountering (e.g. a screenshot of the problem).

Please include a simple .blend file which demonstrates this problem.

Confirmed. This crashes here.

It seems to have to do with the OpenGL rendering of the smoke. A rough backtrace without debug symbols shows it is crashing in the graphics drivers, and loading the file with "Load UI" unchecked (and with the sequencer screen layout open)

Cannot reproduce here on Windows 8.1, Nvidia 740M

After a bit of a wild goose chase through the Node and RNA code, I dicovered that the culprit was much more mundane:
In the NLA Editor, there is currently a NLA track with "Solo" mode enabled (i.e. the star icon to the left of the track name). Disabling this will get the animation working again :)

Close as duplicate.

Ok, I've double checked. Officially this isn't a case that the current code was intended to address (i.e. it only fixes the most basic case).

Sounds related to the changes in how DPI is handled.

There is insufficient info in this report to do anything about this report. Please mention at least:

• Operating system version (I'm guessing Windows 10)
• Graphics card/driver version
• A screenshot of the problem
• Version of Blender with this problem (I'm guessing the newly released 2.79; if not, please try a recent build first)

Just a quick note to say that I'll check on this when I manage to get Blender 2.8 building again here (after it mysteriously broke yesterday) :)

Agreed the release notes are a bit misleading on this point. I just dealt with T52747 yesterday, where it's probably not clear that the potential for rig breakage is not exclusive to Rigify, but rather may affect any rig that uses non-uniform IK scaling.

In the Timeline, go to the "Playback" menu and enable the "Property Editors" checkbox.

Thanks! We can close this now :)

Cannot reproduce here.

Assigning to @Howard Trickey (howardt)

Thank you for your report. Unfortunately, we've had to change the way that the IK-stretching with non-uniform scale is working in order to fix several critical bugs the 2.78 method was causing.

Thanks, I'll see what we can do about this :)

There is insufficient information here to do anything about this report.

Ah, I've finally found the keyframes causing the problem:
On the custom property controls (at the bottom of the channels list, outside any groups), each F-Curve only had a single keyframe. The calculation code was adding padding onto those values, increasing the overall length, even though the whole action was already > 1 frame long.

Oh, and I forgot to mention: To increase your framerates, I strongly recommend you to reduce the number of open animation editors per editor to only a single one. Currently you've got all 3 open + the timeline, which does add up :)

This isn't really a bug, as some performance drop is to be expected.

This only applies for the old depsgraph and not the new depsgraph. Since the old depsgraph will be going away soon in 2.8, I don't think it's best that we just leave things as-is now.

In addition to the troubleshooting steps mentioned by @Vuk Gardašević (lijenstina), have you tried posting/searching on any forums (e.g. StackExchange - https://blender.stackexchange.com/) to see if any of the tips mentioned there help?

Confirmed on Windows 8.1 (rB65582e7) with Intuos Pro 5.

Cannot reproduce here on 65582e7, using Windows 8.1 64-bit (i7-4700MQ).

Confirmed. This behaviour looks wrong/incorrect to me.

Indeed, it seems that the new Flip Names behaviour is causing problems here, meaning that this is a duplicate of T52685

IIRC, there isn't really any "ID_NLA" datablock type currently. If it did happen in the past, it would have been a special hack used in 2.4x for either handling context in the IPO Editor, or as a hack for some other issue.

I finally got around to checking on this report again today.

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?