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.
Description
Event Timeline
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...
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!
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.
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.
