Poor performance in Timeline, Dope Sheet, etc when at the top of the editor. #78995

New Issue

Likkez · 2020-07-16T17:05:10+02:00

Likkez commented

2020-07-16 17:05:10 +02:00

System Information
Operating system: Linux-5.3.0-7648-generic-x86_64-with-Ubuntu-19.10-eoan 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100

Blender Version
Broken: version: 2.79, 2.83, 2.90.0 Alpha, branch: master, commit date: 2020-07-16 14:09, hash: f64710a518
Worked: unknown, possibly never.

Short description of error
Seems like some animation files cause really poor performance in Dope sheet when trying to scroll on top of it. Scrolling down and making the top section not visible seems to fix the performance.
I presume the editors draw keyframes for channels on top of each other without checking if the key already exists.
2020-07-16 17-54-48.mp4

Exact steps for others to reproduce the error

Open attached file
slow.blend
Try to click around on timeline, dope sheet editor.
Open the key dropdown in dope sheet and scroll down. Notice how performance goes back to normal.

**System Information** Operating system: Linux-5.3.0-7648-generic-x86_64-with-Ubuntu-19.10-eoan 64 Bits Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100 **Blender Version** Broken: version: 2.79, 2.83, 2.90.0 Alpha, branch: master, commit date: 2020-07-16 14:09, hash: `f64710a518` Worked: unknown, possibly never. **Short description of error** Seems like some animation files cause really poor performance in Dope sheet when trying to scroll on top of it. Scrolling down and making the top section not visible seems to fix the performance. I presume the editors draw keyframes for channels on top of each other without checking if the key already exists. [2020-07-16 17-54-48.mp4](https://archive.blender.org/developer/F8699405/2020-07-16_17-54-48.mp4) **Exact steps for others to reproduce the error** 1. Open attached file [slow.blend](https://archive.blender.org/developer/F8699391/slow.blend) 2. Try to click around on timeline, dope sheet editor. 3. Open the key dropdown in dope sheet and scroll down. Notice how performance goes back to normal.

Likkez commented

2020-07-16 17:05:10 +02:00

Added subscriber: @Likkez-2

blender-admin commented

2020-07-16 17:05:10 +02:00

#85270 was marked as duplicate of this issue

Richard Antalik commented

2020-07-17 02:42:55 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-07-17 02:42:55 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Richard Antalik commented

2020-07-17 02:42:55 +02:00

I guess it would be nice to make this faster, this doesn't necessarily look like hard to do, and it will be quite useful so I will confirm.

Since this is performance issue that doesn't look very critical we may not consider it to be a bug.

I guess it would be nice to make this faster, this doesn't necessarily look like hard to do, and it will be quite useful so I will confirm. Since this is performance issue that doesn't look very critical we may not consider it to be a bug.

Sybren A. Stüvel commented

2020-07-17 10:50:41 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-07-17 10:50:41 +02:00

Changed status from 'Confirmed' to: 'Needs User Info'

Sybren A. Stüvel commented

2020-07-17 10:50:41 +02:00

@Likkez-2 Please do some testing with older versions of Blender. This will tell us whether it's a regression problem, or whether this performance issue has "always" been in Blender.

Likkez commented

2020-07-17 13:01:57 +02:00

In #78995#980788, @dr.sybren wrote:
@Likkez-2 Please do some testing with older versions of Blender. This will tell us whether it's a regression problem, or whether this performance issue has "always" been in Blender.

Alright, Ive tested on 2.83 and 2.7. The issue seems to always be there but its even worse on those versions since it slows down the viewport together with the dope sheet editor.

2.83:
2020-07-17 13-47-55.mp4

2.7:
2020-07-17 13-57-39.mp4

> In #78995#980788, @dr.sybren wrote: > @Likkez-2 Please do some testing with older versions of Blender. This will tell us whether it's a regression problem, or whether this performance issue has "always" been in Blender. Alright, Ive tested on 2.83 and 2.7. The issue seems to always be there but its even worse on those versions since it slows down the viewport together with the dope sheet editor. 2.83: [2020-07-17 13-47-55.mp4](https://archive.blender.org/developer/F8701425/2020-07-17_13-47-55.mp4) 2.7: [2020-07-17 13-57-39.mp4](https://archive.blender.org/developer/F8701426/2020-07-17_13-57-39.mp4)

Bent Hillerkus commented

2020-07-17 14:00:04 +02:00

Added subscriber: @bent

Sybren A. Stüvel commented

2020-07-21 15:36:18 +02:00

@bent 2.7 is not a version of Blender. I think I can just make out the 2.79 in the title bar.

@Jeroen-Bakker could you take a look at this?

@bent 2.7 is not a version of Blender. I think I can just make out the 2.79 in the title bar. @Jeroen-Bakker could you take a look at this?

Sybren A. Stüvel commented

2020-07-21 15:37:31 +02:00

Added subscriber: @Jeroen-Bakker

Sybren A. Stüvel commented

2020-07-21 15:37:41 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Likkez commented

2020-07-21 21:00:46 +02:00

@dr.sybren My bad. Yes, its 2.79

Jeroen Bakker commented

2020-07-22 11:03:08 +02:00

During my research the curves are converted to samples and back again to find out how to draw the bars. This takes most of the time this is done via the anim_filter.c For animation playback performance we changed this behavior to not happen when only the scene time changes. but we didn't tackle this for editing/working with the editor.

Of course there are many ways how to deal with such a problem:

with D7322: AnimFilter: Iterator we can add an early stop when when we reach the end of the visible region or even other optimizations. We should also consider anim_filter to be CPP to remove the hackish macros.
add a runtime to store the bar sizes to cache the results so we don't need to do this over and over again.
store the bar type (constant vs not constant) per curve-segment (between two keys).

During my research the curves are converted to samples and back again to find out how to draw the bars. This takes most of the time this is done via the `anim_filter.c` For animation playback performance we changed this behavior to not happen when only the scene time changes. but we didn't tackle this for editing/working with the editor. Of course there are many ways how to deal with such a problem: * with [D7322: AnimFilter: Iterator](https://archive.blender.org/developer/D7322) we can add an early stop when when we reach the end of the visible region or even other optimizations. We should also consider anim_filter to be CPP to remove the hackish macros. * add a runtime to store the bar sizes to cache the results so we don't need to do this over and over again. * store the bar type (constant vs not constant) per curve-segment (between two keys).

Likkez commented

2020-07-22 12:53:22 +02:00

@Jeroen-Bakker But how come it lags so much more at the top of the editor? Does it have to convert every single curve there is to draw the top dope sheet keys?

Jeroen Bakker commented

2020-07-22 13:48:38 +02:00

Could be related to the Summary. The summary reflects all filtered curves and can have a lot of data. Not 100% sure as I didn't profiled this intensively.

Sybren A. Stüvel commented

2020-07-27 13:55:19 +02:00

During my research the curves are converted to samples and back again to find out how to draw the bars.

I'll assume that this also happens when you're not researching ;-)

For someone not that familiar with UI drawing code: what are "the bars"?

> During my research the curves are converted to samples and back again to find out how to draw the bars. I'll assume that this also happens when you're not researching ;-) For someone not that familiar with UI drawing code: what are "the bars"?

Sybren A. Stüvel commented

2020-08-06 14:15:56 +02:00

Changed status from 'Confirmed' to: 'Needs User Info'

Sybren A. Stüvel commented

2020-08-06 14:15:56 +02:00

@Likkez-2 could you test this with older versions of Blender to see if this is an issue that was recently introduced, or has been in Blender for longer?

@Likkez-2 could you test this with [older versions of Blender](https://download.blender.org/release/) to see if this is an issue that was recently introduced, or has been in Blender for longer?

Likkez commented

2020-08-06 15:22:11 +02:00

@dr.sybren Yes, I've already done tests in blender 2.83, 2.79 in the reply above. The lag is present in both of these versions. Is there some more specific version you want me to test?

Sybren A. Stüvel commented

2020-09-24 12:31:45 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Sybren A. Stüvel commented

2020-09-24 12:31:45 +02:00

I don't know when someone will have the time to look into this, so I'll mark this as Known Issue for now.

Jeroen Bakker commented

2021-07-09 16:17:05 +02:00

The image above shows the bottle neck.

- draw_summary_channel is the superset of the other channels. So why recalc it 4 times.
- DLRBT_Tree isn't optimized for CPU performance. Perhaps having an array containing the keyframe per visible frame would be quicker and more efficient due to sequential memory access. (loop over the array for drawing). Nodes are scattered around the place and reallocated over and over again.

This is a nice task for a rainy day :-) Isn't this an issue that the blender animation studio has?

![image.png](https://archive.blender.org/developer/F10218122/image.png) The image above shows the bottle neck. * - [ ] draw_summary_channel is the superset of the other channels. So why recalc it 4 times. * - [ ] DLRBT_Tree isn't optimized for CPU performance. Perhaps having an array containing the keyframe per visible frame would be quicker and more efficient due to sequential memory access. (loop over the array for drawing). Nodes are scattered around the place and reallocated over and over again. This is a nice task for a rainy day :-) Isn't this an issue that the blender animation studio has?

Jeroen Bakker commented

2021-07-19 15:01:30 +02:00

An idea is to use list merge. This would remove searching bottleneck. The challenge is that is a different data structure than we currently have, but other parts of blender depends on the existing data structure (pose slide tool for example). In order to optimize the drawing code we should define a better API or use CPP so we don't duplicate logic.

We should also move the _to_keylist code to its own compile unit as it isn't only used for drawing.

An idea is to use list merge. This would remove searching bottleneck. The challenge is that is a different data structure than we currently have, but other parts of blender depends on the existing data structure (pose slide tool for example). In order to optimize the drawing code we should define a better API or use CPP so we don't duplicate logic. We should also move the _to_keylist code to its own compile unit as it isn't only used for drawing.

Jeroen Bakker self-assigned this 2021-07-20 15:56:28 +02:00

blender-admin commented

2021-08-03 08:10:07 +02:00

This issue was referenced by 6f50969406

This issue was referenced by 6f50969406a751ac69d41e792d859d74410ebef6

blender-admin commented

2021-09-10 13:27:26 +02:00

This issue was referenced by 60cfdf0809

This issue was referenced by 60cfdf080929aca61c37439b601b1ef85d51391a

blender-admin commented

2021-09-10 14:26:21 +02:00

This issue was referenced by 7f1fe10595