Scene strips in the VSE are excessively slow to playback. #62517

New Issue

hudson barkley · 2019-03-13T01:17:34+01:00

hudson barkley commented

2019-03-13 01:17:34 +01:00

System Information
Operating system: Windows 8.1
Graphics card: Geforce 860m, Geforce 980

Blender Version
Broken: 2.80, 2019-03-10
Worked: 2.79

Short description of error
Scene strips in the vse will play back very slowly. This seems to happen regardless of render engine, or scene preview type in the vse preview settings, tho some settings and engines do provide better performance than others, even the best combination is still terribly slow.
For example: an eevee scene with only a camera and no special effects enabled will play back at 1-2fps in the vse, but animation playback in the 3d viewport will of course be over 30fps.
Note that this is not the same as the slow playback/rendering due to the color transforms, this still happens when the color is set to 'Default' transform and 'None' look.

Exact steps for others to reproduce the error
Create a second Scene
Add that scene to the vse of the first scene
start playback

I have attached a simple .blend file where I have tried to make the playback as efficient as possible... still only get about 2fps. eevee vse test.blend

**System Information** Operating system: Windows 8.1 Graphics card: Geforce 860m, Geforce 980 **Blender Version** Broken: 2.80, 2019-03-10 Worked: 2.79 **Short description of error** Scene strips in the vse will play back very slowly. This seems to happen regardless of render engine, or scene preview type in the vse preview settings, tho some settings and engines do provide better performance than others, even the best combination is still terribly slow. For example: an eevee scene with only a camera and no special effects enabled will play back at 1-2fps in the vse, but animation playback in the 3d viewport will of course be over 30fps. Note that this is not the same as the slow playback/rendering due to the color transforms, this still happens when the color is set to 'Default' transform and 'None' look. **Exact steps for others to reproduce the error** Create a second Scene Add that scene to the vse of the first scene start playback I have attached a simple .blend file where I have tried to make the playback as efficient as possible... still only get about 2fps. [eevee vse test.blend](https://archive.blender.org/developer/F6811867/eevee_vse_test.blend)

hudson barkley commented

2019-03-13 01:17:34 +01:00

Added subscriber: @snuq

blender-admin commented

2019-03-13 01:17:34 +01:00

#62644 was marked as duplicate of this issue

Sebastian Parborg commented

2019-03-13 14:22:21 +01:00

Added subscriber: @ZedDB

Richard Antalik was assigned by Sebastian Parborg

2019-03-13 14:22:21 +01:00

Sebastian Parborg commented

2019-03-13 14:22:21 +01:00

Getting an assert when opening that file (might not be related but I'll report it just in case):
BLI_assert failed: /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm_window.c:2332, WM_opengl_context_activate(), at 'GPU_framebuffer_active_get() == ((void *)0)'

Getting an assert when opening that file (might not be related but I'll report it just in case): `BLI_assert failed: /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm_window.c:2332, WM_opengl_context_activate(), at 'GPU_framebuffer_active_get() == ((void *)0)'`

Richard Antalik commented

2019-03-13 23:19:55 +01:00

Can confirm this (also can not open file).

May be outside of my current ability to fix this, as this will probably require modifications in rendering pipeline itself.

In any case shouldn't this have high priority?
Not sure if this is inconvenience or this actually prevents some work to be done at all.

Can confirm this (also can not open file). May be outside of my current ability to fix this, as this will probably require modifications in rendering pipeline itself. In any case shouldn't this have high priority? Not sure if this is inconvenience or this actually prevents some work to be done at all.

Sebastian Parborg commented

2019-03-13 23:54:58 +01:00

Added subscriber: @brecht

Sebastian Parborg commented

2019-03-13 23:54:58 +01:00

I think we have reserved high priority tasks to severe crashes and widely reported issues ATM.

@brecht high prio or no?

I think we have reserved high priority tasks to severe crashes and widely reported issues ATM. @brecht high prio or no?

Brecht Van Lommel commented

2019-03-14 00:39:16 +01:00

The assert does not affect release builds end users, only debug builds, so would not consider that high priority.

The performance issue is not high priority either I think. There may be some hidden issue here, though I expect a big part is the new viewport and Eevee in particular doing a lot more setup work than the old viewport. For best performance that state could be cached somehow.

The assert does not affect release builds end users, only debug builds, so would not consider that high priority. The performance issue is not high priority either I think. There may be some hidden issue here, though I expect a big part is the new viewport and Eevee in particular doing a lot more setup work than the old viewport. For best performance that state could be cached somehow.

hudson barkley commented

2019-03-14 10:47:15 +01:00

In #62517#639720, @brecht wrote:...I expect a big part is the new viewport and Eevee in particular doing a lot more setup work than the old viewport.

Its not just slower than the old viewport tho, its slower than the CURRENT viewport... and not just a bit slower, like a 50x speed decrease.
Also, its not just eevee, it is horribly slow even when in wireframe render mode, or when using workbench render engine.
As for priority, well, its up to you guys, but this effectively makes scene strips unusable in the vse.

> In #62517#639720, @brecht wrote:...I expect a big part is the new viewport and Eevee in particular doing a lot more setup work than the old viewport. Its not just slower than the old viewport tho, its slower than the CURRENT viewport... and not just a bit slower, like a 50x speed decrease. Also, its not just eevee, it is horribly slow even when in wireframe render mode, or when using workbench render engine. As for priority, well, its up to you guys, but this effectively makes scene strips unusable in the vse.

Richard Antalik commented

2019-03-14 11:35:50 +01:00

@snuq Brecht probably meant that VSE code does not have setup of new viewport in place to allow fast rendering.

I will look into this as I should get familiar with that code.
What I am saying is that I can not promise to resolve this (promptly).

@snuq Brecht probably meant that VSE code does not have setup of new viewport in place to allow fast rendering. I will look into this as I should get familiar with that code. What I am saying is that I can not promise to resolve this (promptly).

hudson barkley commented

2019-03-14 12:25:08 +01:00

In #62517#639880, @iss wrote:
@snuq Brecht probably meant that VSE code does not have setup of new viewport in place to allow fast rendering.

I will look into this as I should get familiar with that code.
What I am saying is that I can not promise to resolve this (promptly).

Sure, sorry if I came off as demanding or rude, I just wanted to make sure the issue was understood fully. I greatly appreciate the massive work that is going into Blender, especially in maintaining and updating the features like the vse that occasionally get forgotten.

> In #62517#639880, @iss wrote: > @snuq Brecht probably meant that VSE code does not have setup of new viewport in place to allow fast rendering. > > I will look into this as I should get familiar with that code. > What I am saying is that I can not promise to resolve this (promptly). Sure, sorry if I came off as demanding or rude, I just wanted to make sure the issue was understood fully. I greatly appreciate the massive work that is going into Blender, especially in maintaining and updating the features like the vse that occasionally get forgotten.

Brecht Van Lommel commented

2019-03-16 12:15:03 +01:00

Added subscriber: @hedgehog90-3

Tom Wilson commented

2019-03-16 12:24:04 +01:00

I'm also experiencing this, but I'm sure I had the same issue back when I first tried 2.8 (December 2018)

Olly Funkster commented

2019-03-18 13:02:25 +01:00

Added subscriber: @Funkster-3

Olly Funkster commented

2019-03-18 13:02:25 +01:00

I've been using sequence strips in 2.8, and haven't noticed a difference in framerate between the sequence strip and the scene it came from. I do have a chunky processor though, and some patches applied.

Richard Antalik commented

2019-03-18 14:33:19 +01:00

@Funkster-3 this is problem with 3D scenes..

I looked into this quickly and it seemed to me that program spent most of the time getting data from GPU. This took about 1s per frame in my case.

I guess this can be done much faster.

@Funkster-3 this is problem with 3D scenes.. I looked into this quickly and it seemed to me that program spent most of the time getting data from GPU. This took about 1s per frame in my case. I guess this can be done much faster.

Richard Antalik was unassigned by Jeroen Bakker

2019-04-28 10:26:03 +02:00

Jeroen Bakker self-assigned this 2019-04-28 10:26:03 +02:00

Jeroen Bakker commented

2019-04-28 10:26:03 +02:00

Added subscriber: @iss

Enzio Probst commented

2019-04-29 17:24:07 +02:00

Added subscriber: @EnzioProbst

Jeroen Bakker commented

2019-04-30 14:16:07 +02:00

Changed status from 'Open' to: 'Resolved'

Jeroen Bakker closed this issue

2019-04-30 14:16:07 +02:00

hudson barkley commented

2019-04-30 22:57:12 +02:00

This seems to not be resolved yet, at least not completely (maybe remove the 'excessively' from the title now? heh).
The latest build is MUCH faster, and actually use-able now, but it is still a lot slower than the viewport.
Even with a very basic camera and cube only scene, lookdev (and solid) mode never gets above 20fps in the vse, and rendered mode about 2fps. viewport for both modes is over 30fps.

Using the 2019-04-30 18:56 build, i think that includes the fixes?

Interestingly enough, there seems to be some kind of overhead going on, not just a division of the performance... the lookdev mode never gets above 20fps even for a super basic scene, but when i load down that scene with enough geometry to actually slow down the viewport under 30fps, the vse view is only down to 10fps

This seems to not be resolved yet, at least not completely (maybe remove the 'excessively' from the title now? heh). The latest build is MUCH faster, and actually use-able now, but it is still a lot slower than the viewport. Even with a very basic camera and cube only scene, lookdev (and solid) mode never gets above 20fps in the vse, and rendered mode about 2fps. viewport for both modes is over 30fps. Using the 2019-04-30 18:56 build, i think that includes the fixes? Interestingly enough, there seems to be some kind of overhead going on, not just a division of the performance... the lookdev mode never gets above 20fps even for a super basic scene, but when i load down that scene with enough geometry to actually slow down the viewport under 30fps, the vse view is only down to 10fps

Jeroen Bakker commented

2019-05-01 09:45:50 +02:00

@snuq When rendering in the viewport every pixels stays on the GPU. The sequencer needs the pixels on the CPU so it transfers everything back to the CPU to do additional sequencer, imaging and color management stuff. when done it transfers the pixels back to the GPU so you can view them. Until the sequencer will be fully migrated to the GPU there will be a slowdown and depends on the actual hardware it runs on.

As a reference machine I use (Ryzen1700 with WX7100), I get 24fps with ease in the VSE even when using wanderer.blend on a debug build in lookdev mode.

@snuq When rendering in the viewport every pixels stays on the GPU. The sequencer needs the pixels on the CPU so it transfers everything back to the CPU to do additional sequencer, imaging and color management stuff. when done it transfers the pixels back to the GPU so you can view them. Until the sequencer will be fully migrated to the GPU there will be a slowdown and depends on the actual hardware it runs on. As a reference machine I use (Ryzen1700 with WX7100), I get 24fps with ease in the VSE even when using `wanderer.blend` on a debug build in lookdev mode.

hudson barkley commented

2019-05-02 00:35:08 +02:00

Upon further comparisons with blender 2.79, i have noticed similar speeds, with 2.8 only being a couple fps slower with the same setup (the 'material' mode in 2.79 playback being 27fps while the 'lookdev' mode in 2.8 being about 23fps). Similarly, the 'solid' mode is a bit slower in 2.8 as well.
If this smallish slowdown is a bug, or simply new features slowing blender down a bit, I don't know enough to say, I figured I could give some hard numbers just in case.

However, there still seems to be a problem with the 'rendered' mode - it is still VERY slow for no apparent reason. A camera-only scene with no special features turned on plays back at 2fps, while the viewport plays back at over 30 of course. This is less of an issue since lookdev mode should cover most use cases, but it seems there is still a bug in there somewhere.

Upon further comparisons with blender 2.79, i have noticed similar speeds, with 2.8 only being a couple fps slower with the same setup (the 'material' mode in 2.79 playback being 27fps while the 'lookdev' mode in 2.8 being about 23fps). Similarly, the 'solid' mode is a bit slower in 2.8 as well. If this smallish slowdown is a bug, or simply new features slowing blender down a bit, I don't know enough to say, I figured I could give some hard numbers just in case. However, there still seems to be a problem with the 'rendered' mode - it is still VERY slow for no apparent reason. A camera-only scene with no special features turned on plays back at 2fps, while the viewport plays back at over 30 of course. This is less of an issue since lookdev mode should cover most use cases, but it seems there is still a bug in there somewhere.

Richard Antalik commented

2019-05-02 05:01:43 +02:00

this may be worth further investigation IMO.

Big issue is, that whole process is single-threaded. This can be resolved with prefetching hopefully to larger than lesser extent.

I can play movie clip(sure 8-bit...) with GLSL color transformation with barely any impact on performance.

I don't know, is the GPU-CPU bandwidth is symmetrical?
Or are 3D renders are significantly larger - 32bit?
Or perhaps reading algorithm from GPU mem is not optimal?

Then question is if it is worth squeezing every bit of performance in this day and age.

this may be worth further investigation IMO. Big issue is, that whole process is single-threaded. This can be resolved with prefetching hopefully to larger than lesser extent. I can play movie clip(sure 8-bit...) with GLSL color transformation with barely any impact on performance. I don't know, is the GPU-CPU bandwidth is symmetrical? Or are 3D renders are significantly larger - 32bit? Or perhaps reading algorithm from GPU mem is not optimal? Then question is if it is worth squeezing every bit of performance in this day and age.

hudson barkley commented

2019-05-05 07:00:42 +02:00

In #62517#669586, @iss wrote:
I don't know, is the GPU-CPU bandwidth is symmetrical?
Or are 3D renders are significantly larger - 32bit?
Or perhaps reading algorithm from GPU mem is not optimal?

Then question is if it is worth squeezing every bit of performance in this day and age.

I would think the process and speed of copying from the gpu to the vse is the same for rendered mode vs lookdev mode, so I wouldnt expect it to have any additional overhead there... or at least it shouldnt?

I was wondering if blender is doing the vse-rendered mode more as if it were doing a render-to-file mode, instead of viewport-render mode, since rendering to a file is much slower (for good reason tho, sure). If this is the case tho, im not sure WHAT it is doing that is slowing it down that much in a completely basic scene.

And I would definitely say its worth squeezing every bit of performance out of it when relating to the vse, Video pros are constantly pushing for higher resolutions still - 4k is common now, 8k is coming fast, and of course the cg will have to keep up with it...

> In #62517#669586, @iss wrote: > I don't know, is the GPU-CPU bandwidth is symmetrical? > Or are 3D renders are significantly larger - 32bit? > Or perhaps reading algorithm from GPU mem is not optimal? > > Then question is if it is worth squeezing every bit of performance in this day and age. I would think the process and speed of copying from the gpu to the vse is the same for rendered mode vs lookdev mode, so I wouldnt expect it to have any additional overhead there... or at least it shouldnt? I was wondering if blender is doing the vse-rendered mode more as if it were doing a render-to-file mode, instead of viewport-render mode, since rendering to a file is much slower (for good reason tho, sure). If this is the case tho, im not sure WHAT it is doing that is slowing it down that much in a completely basic scene. And I would definitely say its worth squeezing every bit of performance out of it when relating to the vse, Video pros are constantly pushing for higher resolutions still - 4k is common now, 8k is coming fast, and of course the cg will have to keep up with it...

Xing Liu commented

2020-05-10 04:39:59 +02:00

Added subscriber: @xingyzt

Xing Liu commented

2020-05-10 04:40:35 +02:00

Removed subscriber: @xingyzt

Thomas Mann commented

2020-08-02 22:26:12 +02:00

Added subscriber: @pixtur

Thomas Mann commented

2020-08-02 22:26:12 +02:00

I'm confused here. Without the Sequencer being able to playback content generated by eevee without fetching it back from GPU memory, the whole point of this component is questionable. If you can edit only already rendered movies files, why do this with a 3d-editing suite if you can't even use 3d compositing?

I understand that this is a enormous task, but I don't understand why this bug has been closed as "resolved" instead of a "duplicate" of a proper improvement task or an honest "won't fix". At least in my opinion, the sequencer should be properly integrated (which would be huge!) or the sequence editor should be extracted into a separate software package.

I'm confused here. Without the Sequencer being able to playback content generated by eevee without fetching it back from GPU memory, the whole point of this component is questionable. If you can edit only already rendered movies files, why do this with a 3d-editing suite if you can't even use 3d compositing? I understand that this is a enormous task, but I don't understand why this bug has been closed as "resolved" instead of a "duplicate" of a proper improvement task or an honest "won't fix". At least in my opinion, the sequencer should be properly integrated (which would be huge!) or the sequence editor should be extracted into a separate software package.

Richard Antalik commented

2020-08-02 22:36:22 +02:00

I guess there wasn't proper improvement task at the moment this was closed.

This should be fixed in future.

I guess there wasn't proper improvement task at the moment this was closed. This should be fixed in future.

Emi Martinez commented

2021-12-04 19:17:06 +01:00

Added subscriber: @Emi_Martinez

Emi Martinez commented

2021-12-04 19:17:06 +01:00

3.0 realease, and this is NOT fixed.
Why is it "closed"???
This bug makes Scene strips in the VSE unusable

3.0 realease, and this is NOT fixed. Why is it "closed"??? This bug makes Scene strips in the VSE unusable

Emi Martinez commented

2021-12-04 19:29:39 +01:00

looks like the VSE render every frame of the Scene (with the composite nodes, motion blur, fx, etc)
Loos like VSE does not use a fast preview like eevee in the viewport, and THIS make extremely SLOW
This must be review!

looks like the VSE render every frame of the Scene (with the composite nodes, motion blur, fx, etc) Loos like VSE does not use a fast preview like eevee in the viewport, and THIS make extremely SLOW This must be review!

Richard Antalik commented

2021-12-06 18:30:20 +01:00

In #62517#1264894, @Emi_Martinez wrote:
looks like the VSE render every frame of the Scene (with the composite nodes, motion blur, fx, etc)

This shouldn't be the case unless you configure preview to use rendered shading. If this is not behaving correctly please create new report.

> In #62517#1264894, @Emi_Martinez wrote: > looks like the VSE render every frame of the Scene (with the composite nodes, motion blur, fx, etc) This shouldn't be the case unless you configure preview to use rendered shading. If this is not behaving correctly please create new report.

jack conradsen commented

2022-05-13 20:27:01 +02:00

Added subscriber: @STANN.co

jack conradsen commented

2022-05-13 20:27:01 +02:00

This is still an issue, using scenes in VSE is/would be a great workflow, but as it is right now it's too lagy to be useful.
If you could use the proxy thing like you can with other video clips that would be helpful as well. Or pre-rendering frames, both seem to not work on scenes right now.

Can this be opened again?

This is still an issue, using scenes in VSE is/would be a great workflow, but as it is right now it's too lagy to be useful. If you could use the proxy thing like you can with other video clips that would be helpful as well. Or pre-rendering frames, both seem to not work on scenes right now. Can this be opened again?

Dmitry commented

2023-05-11 13:38:19 +02:00

I can confirm that scenes in the Rendered or Material Preview mode are very slow.
Allow me suggesting this task should not be closed. I hope that issue will get resolved.
Thanks!

I can confirm that scenes in the Rendered or Material Preview mode are very slow. Allow me suggesting this task should not be closed. I hope that issue will get resolved. Thanks!

Jeroen Bakker commented

2023-05-11 15:00:02 +02:00

@Rockbard from user perspective you're right, although from technical perspective this requires new development as the impact of that requires a large overhaul of how scene strips accesses other scene data and therefore isn't considered a bug.

Dmitry commented

2023-05-11 15:03:25 +02:00

Ah, I see... That's really sad. Hopefully, VSE will get more love soon.
Thanks for getting back to this topic though.

Ah, I see... That's really sad. Hopefully, VSE will get more love soon. Thanks for getting back to this topic though.

👍 1

hudson barkley commented

2023-05-11 19:41:44 +02:00

Honestly, I find it a bit frustrating that this is not considered a bug, since it is clearly unexpected behavior, and severely limits the usefulness of the vse in a lot of ways.
While I can understand that there might be some slowdown, I cant imagine transfer overheads causing this much of an insane slowdown in certain render modes but not others without this being a bug.

Honestly, I find it a bit frustrating that this is not considered a bug, since it is clearly unexpected behavior, and severely limits the usefulness of the vse in a lot of ways. While I can understand that there might be some slowdown, I cant imagine transfer overheads causing this much of an insane slowdown in certain render modes but not others without this being a bug.

❤️ 3

jack conradsen commented

2023-09-22 00:58:10 +02:00

i am still finding this an incredibly big hiccup in my workflow. I have animations with sometimes many different scenes, which i align in the sequencer. But since i am unable to preview stuff the same way i can viewing the scenes diretly, it's not super useful.

My best choice is pre-rendering those scenes and importing.
But this adds the dillema, that i have to render out every scene, and then when all is ready, i have to render my entire sequence again. Effectively i am rendering everything twice with this workflow.

I am curious what other blender developers workflow are to circumvent this, or they don't face this problem or just don't use the sequencer for animation the same way at all.

@snuq When rendering in the viewport every pixels stays on the GPU. The sequencer needs the pixels on the CPU so it transfers everything back to the CPU to do additional sequencer, imaging and color management stuff. when done it transfers the pixels back to the GPU so you can view them. Until the sequencer will be fully migrated to the GPU there will be a slowdown and depends on the actual hardware it runs on.

As a reference machine I use (Ryzen1700 with WX7100), I get 24fps with ease in the VSE even when using wanderer.blend on a debug build in lookdev mode.

If this is the big hiccup. Then i wonder if this is something being worked on at all. At the very least i don't think this "definite" issue should remain closed.

i am still finding this an incredibly big hiccup in my workflow. I have animations with sometimes many different scenes, which i align in the sequencer. But since i am unable to preview stuff the same way i can viewing the scenes diretly, it's not super useful. My best choice is pre-rendering those scenes and importing. But this adds the dillema, that i have to render out every scene, and then when all is ready, i have to render my entire sequence again. Effectively i am rendering everything twice with this workflow. I am curious what other blender developers workflow are to circumvent this, or they don't face this problem or just don't use the sequencer for animation the same way at all. > @snuq When rendering in the viewport every pixels stays on the GPU. The sequencer needs the pixels on the CPU so it transfers everything back to the CPU to do additional sequencer, imaging and color management stuff. when done it transfers the pixels back to the GPU so you can view them. Until the sequencer will be fully migrated to the GPU there will be a slowdown and depends on the actual hardware it runs on. > > As a reference machine I use (Ryzen1700 with WX7100), I get 24fps with ease in the VSE even when using `wanderer.blend` on a debug build in lookdev mode. If this is the big hiccup. Then i wonder if this is something being worked on at all. At the very least i don't think this "definite" issue should remain closed.

👍 1

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

Scene strips in the VSE are excessively slow to playback. #62517