Dopesheet Slows Down with Very Many Keys #25306

New Issue

Allan Ecker · 2010-12-19T22:50:46+01:00

Allan Ecker commented

2010-12-19 22:50:46 +01:00

%%%OS: Win7 64-bit
Video: Intel GMA X4500 Integrated
Version: 33775

When very large numbers (>8000 or so) of keys appear on the dopesheet, it starts to chug pretty good on my system, even though the 3D view is able to update smoothly. Presumably this is because the 3D view only needs to access those keys which are near a given frame in time, which can be a pretty small number, but the dopesheet needs to see all of them and get all of their data.

In my case, this is caused by using the animation system as a "recorder" for motions, dragging the mouse from place to place in real time while the animation plays, with keyframe recording turned on. This creates animations very quickly and lets me get for example a three-minute animation of a character in a radio studio done in under two hours. This works wonderfully but I wince at the thought of tweaking things on the dopesheet, because by the time I've done one or two layers it doesn't respond very well.

This is on the borderline between bug and feature request, but it seemed worth mentioning. It would be seriously awesome if someone could go over this section of the code and remove whatever calls are causing those dopesheet icons to add up to big screen update times (it seems really likely that this would be a not-horrible if non-trivial task), because this animation method speeds up animation creation and makes it much more intuitive to do Digital Puppetry.

%%%

%%%OS: Win7 64-bit Video: Intel GMA X4500 Integrated Version: 33775 When very large numbers (>8000 or so) of keys appear on the dopesheet, it starts to chug pretty good on my system, even though the 3D view is able to update smoothly. Presumably this is because the 3D view only needs to access those keys which are near a given frame in time, which can be a pretty small number, but the dopesheet needs to see all of them and get all of their data. In my case, this is caused by using the animation system as a "recorder" for motions, dragging the mouse from place to place in real time while the animation plays, with keyframe recording turned on. This creates animations very quickly and lets me get for example a three-minute animation of a character in a radio studio done in under two hours. This works wonderfully but I wince at the thought of tweaking things on the dopesheet, because by the time I've done one or two layers it doesn't respond very well. This is on the borderline between bug and feature request, but it seemed worth mentioning. It would be seriously awesome if someone could go over this section of the code and remove whatever calls are causing those dopesheet icons to add up to big screen update times (it seems really likely that this would be a not-horrible if non-trivial task), because this animation method speeds up animation creation and makes it much more intuitive to do Digital Puppetry. %%%

Allan Ecker commented

2010-12-19 22:50:46 +01:00

Changed status to: 'Open'

Danny McGrath commented

2010-12-19 23:46:19 +01:00

%%%Curious, but have you ever seen the little arrow/pointer button with the label "Only include channels relating to selected object and data" before?%%%

Allan Ecker commented

2010-12-20 01:32:23 +01:00

%%%As much as I enjoy a good RTFMing, that's an incomplete fix. It definitely improves my situation and I didn't notice that feature, but the chugging still kicks in to some extent when I have these long lengths of high-density keyframes, which presumably could be decimated by a curve-simplification script but I haven't gotten that far along yet...%%%

Allan Ecker commented

2010-12-20 01:45:49 +01:00

%%%However, given that curve-simplification exists, I think I'm willing to more firmly place this in the "feature request" category. Especially now that I'm trying to get a nice, reproducible crash out of my current animation woes...%%%

Joshua Leung commented

2010-12-20 02:07:01 +01:00

%%%Hi,

The dopesheet performance should already be greatly improved from the situation in the 2.4x series.

Do you have the "summary" channel enabled? If so, that is bound to be one of the things that will slow things down, as it will go through finding all the keyframes, which effectively doubles the amount of stuff going on.

Also, if you're only dealing with keyframes from one object, it might be faster to use the "Action Editor" submode instead.

To help debug this, it'd also be great if you could upload such a file. Cheers!%%%

%%%Hi, The dopesheet performance should already be greatly improved from the situation in the 2.4x series. Do you have the "summary" channel enabled? If so, that is bound to be one of the things that will slow things down, as it will go through finding all the keyframes, which effectively doubles the amount of stuff going on. Also, if you're only dealing with keyframes from one object, it might be faster to use the "Action Editor" submode instead. To help debug this, it'd also be great if you could upload such a file. Cheers!%%%

Ton Roosendaal commented

2010-12-21 12:34:10 +01:00

%%%The keys in the Dopesheet are being drawn in opengl, using display-lists (which is what Joshua mentions as speedup). The system you use has Intel gfx, which is infamous for giving bad opengl support in general. If I were you, I'd check this on a different system to compare?

Next to that: the fcurve system could add a tool for curve-fitting, to resample paths to get the minimum amount of key points.
I suggest to close this report as opengl performance issue.%%%

%%%The keys in the Dopesheet are being drawn in opengl, using display-lists (which is what Joshua mentions as speedup). The system you use has Intel gfx, which is infamous for giving bad opengl support in general. If I were you, I'd check this on a different system to compare? Next to that: the fcurve system could add a tool for curve-fitting, to resample paths to get the minimum amount of key points. I suggest to close this report as opengl performance issue.%%%

Ton Roosendaal commented

2010-12-21 12:34:10 +01:00

Changed status from 'Open' to: 'Archived'

Ton Roosendaal closed this issue

2010-12-21 12:34:10 +01:00

warp zone commented

2017-02-23 05:09:33 +01:00

Added subscriber: @WarpZone

warp zone commented

2017-02-23 05:09:33 +01:00

In #25306#103091, @dmcgrath wrote:
%%%Curious, but have you ever seen the little arrow/pointer button with the label "Only include channels relating to selected object and data" before?%%%

Where is that button, Dan? When I googled the phrase "Only include channels relating to selected object and data," the only result I got was this page.

I'm seeing 3 or more seconds of lag literally every time I try to move the playhead in 2.78a. Are you sure this was fixed in 2.4?

How many keys is "too many?" My scene has one character with 67 bones and LocRotScale set every frame for every bone, because otherwise changes I make on one frame always non-intuitively change the model's pose on other frames I already finished editing and then I don't notice it for several undo levels.

Edit: Nevermind, I had a Decimate modifier before the Armature I'd forgotten to Apply.

I'd still like to know what that control is really called so I can look it up. RTFM is hardly a fair response when the thing you want them to R about isn't in TFM.

> In #25306#103091, @dmcgrath wrote: > %%%Curious, but have you ever seen the little arrow/pointer button with the label "Only include channels relating to selected object and data" before?%%% Where is that button, Dan? When I googled the phrase "Only include channels relating to selected object and data," the only result I got was this page. I'm seeing 3 or more seconds of lag literally every time I try to move the playhead in 2.78a. Are you sure this was fixed in 2.4? How many keys is "too many?" My scene has one character with 67 bones and LocRotScale set every frame for every bone, because otherwise changes I make on one frame always non-intuitively change the model's pose on other frames I already finished editing and then I don't notice it for several undo levels. Edit: Nevermind, I had a Decimate modifier before the Armature I'd forgotten to Apply. I'd still like to know what that control is really called so I can look it up. RTFM is hardly a fair response when the thing you want them to R about isn't in TFM.

Danny McGrath commented

2017-02-23 17:08:19 +01:00

@WarpZone Hi, it's been a while, but I think it's the thing I included in the screenshot below. Hope this helps?

@WarpZone Hi, it's been a while, but I think it's the thing I included in the screenshot below. Hope this helps? ![Screenshot_2017-02-23_11-04-47.png](https://archive.blender.org/developer/F494531/Screenshot_2017-02-23_11-04-47.png)

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Dopesheet Slows Down with Very Many Keys #25306