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

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

Added subscriber: @snuq

#62644 was marked as duplicate of this issue

Added subscriber: @ZedDB

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)'

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.

Added subscriber: @brecht

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

@brecht high prio or no?

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.

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.

@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).

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.

Added subscriber: @hedgehog90-3

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

Added subscriber: @Funkster-3

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.

@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.

Added subscriber: @iss

Added subscriber: @EnzioProbst

Changed status from 'Open' to: 'Resolved'

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

@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.

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.

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.

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...

Added subscriber: @xingyzt

Removed subscriber: @xingyzt

Added subscriber: @pixtur

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 guess there wasn't proper improvement task at the moment this was closed.

This should be fixed in future.

Added subscriber: @Emi_Martinez

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

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!

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.

Added subscriber: @STANN.co

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?

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