I gave it a short try today. It's definitively interesting, nice work. Questions:

1. Is there already a way to go back to have no active tool?
2. Lamp Place:

You are using this to enable the widget instead of directly mapping RMB to lamp placement. I then wonder if we shouldn't we see the widget of all the select lamps, not only the active one.

3. Transformation widget:

It looks like there is some redundancy with the transformation widgets and the transformation tools. Do we really want to be able to directly transform without the widgets? (short of using shortcuts)

Combined.Combined was introduced in 2.75 along with the multiview changes

Oh ouch. You are right then, no changes to non-multiview EXR should have been introduced, my bad.

Single-layer is perfect now. For multi-layer you introduced a few changes. They may be by design, but I would like to hear from you on these, so they would at least be mentioned in the commit log:

Although this is noticed with Cycles there is a big chance that this has nothing to do with Cycles.

"/* if rendered only one view, we treat as a a non-view render */"

You are introducing a regression for multi-layer Multi-View files that are rendering only one eye.
For example:

Note to self: I'm tagging the scene before adding the object to the collections. I may need to split the object_add_common in a pre and post routines. (I'll try tomorrow).

Ah right. It was one of my tests files for my work on collection and groups, ... so I didn't realize the issue was that. That said armature proxies are broken until I force depsgraph refresh (e.g., save and re-open the file, or add a new object). But it's a separated issue since there is no error printing in this case. It was even more broken before fc10484f7c55 - not even saving/reopening fixes it back then.

I have no idea if this problem is depsgraph related or ID refactor related. So although I assigned it to @Sergey Sharybin (sergey) it may be related to @Bastien Montagne (mont29) too.

Your file breaks my 2.79 release entirely :)
I will test your patch first thing tomorrow morning just to double-check. Particularly for non-multiview cases, to make sure things are still 100%.

Loading multiview images with a single view from other software failed.

This is by design, thus not a bug.

@Aleksander Petkov (AKIRA_SAN) you need to run blender from the cmd, and pipe the output:
blender.exe --debug 1>out.txt 2>err.txt

Final touchups - so I can review it online

• From review: No longer need to change mainb type
• From review: dont use pointer to ViewRender in DNA_*
• From review: Use "e" prefix for enums

@Arto Kitula (akitula) can you see if P486 "fixes" the issue for you?

For the records, we will at some point in the near future have viewports (or at the very least workspaces or windows) with different frames among themselves. So although a viewport may be animating, the others won't be animating necessarily. The visibility of manipulators should respect that (i.e., hide only for the viewports that are animated).

@Campbell Barton (campbellbarton) There is one thing I need to test further, but I updated the patch with yours and @Julian Eisel (Severin)'s suggestion. It became a much bigger patch, but we now have a "ViewRender" struct. Feel free to take another look at it.

• From review: handle rna_workspace_engine_set differently
• Frow review: Rename engine_name > engine_id
• From review: Rename BKE_render_* to BKE_viewrender_*
• From review: Massive changes: own struct for ViewRender data (engine, ...)

Guys, this is the patch with both options.

• Fix doversion for char engine[]
• From review: Use workspace engine only for buttons window preview

Confirmed. Crash is:

Note to self (or @Sergey Sharybin (sergey) if he feels like):
Take a look at render_preview.c::preview_prepare_scene and see if depsgraph is flushing the visibility / disability properly.

• From review: split SETLOOPER usecases

• Testing arcanist 2

In T50845#462076, @xan2622 (xan2622) wrote:

The user can simply create a clone of the current workspace if he/she wants an alternative layout.

And also, @Enrico Valenza (env) / @Joshua Leung (aligorith) if you run with --debug --debug-gpu you will see the exactly shader error the compiler error line is referring to (spoiler alert, shares are > 5k lines)

@Joshua Leung (aligorith) could you bisect it? Clement is on his own hardware and likely is not even running into this.

• Cleanup
• From review: use eval_context to store engine instead of workspace
• From review: use RenderEngineType instead of const char *engine_name

Confirmed the really low times linking times due to branching. I even added a new --debug-gpu-shaders that for now dumps the compiled shaders in the Blender temp session folder.

This is how the splashscreen looks:

@Brecht Van Lommel (brecht) you helped with the patch yesterday (D2849) yet you didn't say your opinion on that. What do you think?

Just to be clear, the concerns raised by @Sergey Sharybin (sergey) are related to having an object used for boolean casting shadows even if you turn it invible.
Same goes for groups or particles, where you often wants to hide the original "group" objects entirely.

For the records, I committed this without the changes @Sergey Sharybin (sergey) was raising concerns about. I'll open a new patch to discuss this.

Guess it's more matter of question whether object visibility affects on "visibility for camera" or "visibility for everything". This patch switched from latter to former one, which could work but is a bit weird. Means, making objects invisible wouldn't really speed up your viewport -- shadow buffers will still be recalculated.

• Rename: hidden > is_visible
• From review: loop cleanup
• From review: BKE_object_is_visible() util

@Clément Foucault (fclem) I will be surprised if you don't get this problem in your Intel as well.

@Campbell Barton (campbellbarton) the slow part was coming from getting the scene layer from collection, and then getting collection id for scene layer. This was running for every collection.
It's not necessarily slow, there is only too many collections a user will have. But it's running as part of the UI code, and I think it doesn't justify.

• Do not use operator in outliner (for now)
• Change icon (use checkbox)

• Another approach, passing collection index to operator

@Campbell Barton (campbellbarton) I need your help here.

Fantastic, thanks @Sergey Sharybin (sergey). It's fixed.

• From review: Python API changes
• From review: collection toggle operator