It looks like color management slows down the rendering significantly. (~0.5s per frame)
More specifically, this time is spend in IMB_partial_display_buffer_update.

Changing the view transform from Filmic to e.g. Raw results in a noticeable speedup for me.

There's a big difference between times reported and actual times. It renders slower than it says. For example, after the first frame, not counting build time since im rendering a cube, the time reported goes down, but it it's actually the same. Regardless, these are the times on my machine when rendering, but I think they are slower

-The fastest i've made a 4K DCI res render is at 0.11 seconds per frame, using the video sequencer to render a jpeg to jpeg sequence, srgb to srgb. If I use another color management as output it becomes a little bit slower, 0.3 seconds.
-If I use an EXR as input and output in the Sequence editor, the time increases to 0.4 or 0.7 seconds, unless i change the color management of the output to raw, in which case it goes to 0.3 seconds. Using jpg as input but exr as output is 0.1 seconds
-An actual render from eevee, the default cube scene with 1 sample, at the same 4k dci resolution, is about 1 second with filmic, and 0.5 with raw color, regardles of output format. While my viewport in my 4k monitor is realtime and close to 60fps

My takeaway is that the writing is barely an issue, 0.1 seconds per frame at this resolution, regardless of format. But the input, 8bitjpeg vs Full uncompressed EXR/direct render, and the color management, are the slowest parts. The viewport seems to have some kind of real time color management that performs faster

Ideally, there should be unnecesary redundant color management under the hood, like right after rendering but not saving and use the real time color management instead, or when saving to EXR. And for the color management for saved files to be as fast as the one in the viewport. Can that be achieved?

OCIO has two paths:

1. GPU
2. CPU

When rendering, the optimal quality is only possible via the CPU path, hence why during offline rendering it needs to be CPU. Online can be GPU.

Not sure it would account for the slowdown being documented here, but it may be a contributing factor. If it is, a "Lower Quality" checkbox could provide an option perhaps, although I strongly suspect there are broken code paths gobbling up many more cycles than OCIO.

But even if the factors colormanagement and writing were 0, it would still be slower than normal playblack in the viewport.

So - will this be tackled in June before the launch of 2.80? I don't want to annoy anyone, but IMO this is the most severe issue rn. Exporting Eevee animations is about 300 times slower than the viewport (60 fps v 6 seconds per frame) with - for me - no observable quality difference. It's a dealbreaker for me and keeps me from using it. I think lots of people will come to 2.8 because of EEVEE and IMO this could lead to lots of bad first impressions.
So, yeah, please consider fixing this before the release of 2.80, even if it's no crash / bug.

High priority means it's planned to be fixed before the 2.80 release.

Got the same issue, failed to get viewport animation in less that 5 secs per frame at any mode, while rendering took 14 sec per frame.

https://www.youtube.com/watch?v=Xdwvl9JFr2M

Here is test file, around 4 sec to render, almost same time for viewport render.
https://www.dropbox.com/s/0ftuo9pd282fyq6/BQ-ER_60F_2019_PART.zip?dl=0

Conclusion of the discussion so far on blender.chat was to

• remove FSAA (scene->r.mode & R_OSA)
• implement a TAA loop for workbench image rendering (similar to EEVEE) make sure both will work. Note check workbench_render code is (partly) there.
• Add setting to workbench for the number of render samples. (enum with 1, 5, 8, 11, 16, 32 as these are only supported by workbench engine workbench_taa_calculate_num_iterations)

Disabling AA gives a significant boost to rendering speed.
Unfortunately the boosted result isn't as fast as the viewport itself.

It sounds to me that the plan is to "essentially" just switch the Anti-Aliasing options.
I don't know how much that will affect anything, so I have a question about speed:

Will only render a single sample. Only when animation is stopped the rest of the samples are calculated (TAA) upto the num of viewport samples.

You specified this, only for viewport playback.
Is there / Will there be a way to get render playback nearly as fast a viewport?

Like skipping this this part, and adding the "Writes result to disk" part.

So that the only speed difference between viewport playback (frame_skipping disabled), and viewport render,
is the time it takes to write the file to disk and displaying the image in Blender.

@Ovionis (Phigon) There will always be some differences in performance and functionality between rendering in the 3d viewport and using the Viewport Render options (eg color management, Download result and store in Image Editor.

We are currently looking in what can be done in short term keeping in mind the render quality and without introducing new features.
Later we can always add new features to improve blender, but that is a different story.

Viewport rendering is best done as low quality as possible.
If people renders Viewport, they are consigned to the quality of the viewport level.

Yeah, I just don't want to have to screenrecord a real time playback in the viewport anymore ?

One question:
Is there a real solution for the slow View->Viewport Render Animation function?

In the current master (Aug. 01, 2019) it's still much slower than the realtime playback in the viewport.
I've a playback rate around 5 f/s and would expect to render the viewport with the same speed. But when I use "Viewport Render Animation" the render speed "feels" like around 0.5 f/s.

Any idea how to render Viewport Animation Previews with the same speed like the viewport playback speed?
As I remember in Blender 2.7x Viewport Animation Rendering was much faster, even when using AA in the viewport.

Any suggestions how to render the Viewport Animations faster in Blender 2.8?

I hope I didn't misunderstand something in the thread before.

Thank you
Chris

No, you didn't.
There were such a problem.
Also, could it be because of long images saving?

In T60847#742716, @Paul Kotelevets (1D_Inc) wrote:

No, you didn't.
There were such a problem.
Also, could it be because of long images saving?

The same project is twice as fast in Blender 2.79. There I use viewport AA with 8 samples.
The viewport animation speed is twice as fast and OpenGL Animation Rendering renders twice as fast, too in 2.79.

In what shading mode?
There were problem, that final eevee renderind frame took 14 sec, while OGL animation - never less than 5.

It is in solid mode in Blender 2.8.
Solid and Look Dev are same speed here.

The same project has around 10 f/s animation speed in 2.79, and 5 f/s in Blender 2.8 when I use wireframe mode e.g.