Yeah, I see the point. So what do you think should happen with the Toolshelf in the clip editor? Because that is currently very different, conceptually, from the toolshelf in the 3d view.

@Campbell Barton (campbellbarton) What is the reason the mask toolbar has been removed? It certainly does not make masking easier, and it also does not really improve the UI?

I cannot confirm that. For me proxies do work in the 3d view, at least in 2.79 (2.8 seems to have issues). The proxies generated with the clip editor, that is.
The proxies that you generate with the VSE are a different thing and serve a different purpose, as far as I know.
Could it be that you are trying to load proxies from the VSE?

Well, that is true. The problem does remain though, even when picking colors that are within 0..1 range.
Let's say for example, you have 2 meshlights, but with 2 different materials. If you want to pick the emission color from meshlight A to meshlight B form the viewport, you will not get the same color, because the color picker is not picking the reference but the color that was generated by the Display transform.

Updated the Diff again. Now there is only 1 Display menu, that is also visible when in mask mode.

Updated Diff so it applies to current 2.8

This sounds more like an issue with step 9 in your list: zooming out too far.
If you go to View Menu and select "View all", or try "View selected" (after selecting an object in Outliner), does that recenter your view so you can see the objects?

It does work when you are using the Defocus Node, using the Z-Buffer of the current scene. Could be that this is the only node that does actually trigger a render update, but then the Auto Render button would be quite misleading indeed.

Ah, thanks for the clarification! :)

Turns out, I was wrong. The issus got a bit better, but there still is a significant slowdown happening.
I have prepared a file with the default world, no lamps, just the 2 objects (camera and mesh from your file). There are 2 keyframes, on frame 1 it renders fast, and frame 2 it renders slow.
I have tested with latest master as well as 2.79a. So I would say, bug confirmed.

Wow, what a weird file! I can confirm there are differences in render time, but could not figure out why. I tried with not light source, with a different camera, with a different world, with no materials.
Still the same problem, in some rotation it renders really fast, and then, the more I increase the rotation, the render time increases as well.
It also doesnt depend on the camera angle, since rotating the object and the camera together still produce the same issue. However, copying the object and the camera and pasting it in a different file seems to eliminate the problem. Weird!

@Dalai Felinto (dfelinto) I am wondering if it even makes sense to have an EEVEE setup at this point. As far as I can see EEVEE does not have something like a shadow catcher, nor can collections ins view_layers be set to holdout, which is both kind of important for a working setup. So I would first make it use Cycles.

I have managed to make the Setup_Tracking_Scene operator work without errors by disabling the old BI and layer stuff, now I am trying to make the renderlayer setup work again.
However, it seems as if there are some python bindings missing still.
To make the setup work I am planning to have 2 Viewlayers, Background and Foreground (as was already implemented in the new script), with two collections, "background" and "foreground". In the Foreground viewlayer, the background collection will be set to "holdout", in the Background view_layer the foreground collection will be set to indirect only.
I can make the setup work with the outliner View_Layer menu, however I could not find a way to do that via python. Something like bpy.context.scene.view_layers["Background"].collections["foreground"].holdout = True
That or at least something similar does not seem to exist yet.
Or if it does, maybe someone can give me a hint?

I will have a look. Maybe first just kick out all the old stuff so that at least the basic setup of constraints and background images work. Speaking of which, the whole camera background image stuff doesnt seem to work all that great yet. Footage is always drawn in front of objects, no matter the front/back setting in camera background images. Also the colors are completely off in solid mode.

As mentioned before it's a very useful feature, also works great after a bit of testing. So I guess from artist's side it can be committed! :)

The last revision that worked was this: https://developer.blender.org/rB59b4c675361b54b32b6238855fe4a82117cc48c7
Starting with this commit Blender hangs when using a filepath directly: https://developer.blender.org/rB08274433e1bd9db5a2a27e5d2f8862e9cc3f27f0
Maybe @Bastien Montagne (mont29) wants to have a look? :)

This one looks really useful, also works great. :)

It's an interesting feature. But I would want to be able to set the amount of frames that are blended and also to be able to turn it off. I think it could also be an extra operator with separate shortcut, or maybe a mod to G (like the operator modes of knife tools). Or it could be a mode to enable, like proportional editing.

Please attach a blendfile with the bug, otherwise we have no chance of looking into your issue. Also, please provide the information required in the bug report guidelines.

Let me guess: You are not in edit mode when you press "W"? However, that's hard to tell, since you did not attach a blend-file, as required by the bug reporting guidelines ;)

This is not a bug. The renderer has nothing to do with camera solving. The fact that you got different results has to do with slightly different positions of your markers in the 2 different attempts. In fact the position of the tracking markers is your biggest problem.
In the video you had put the markers only on a flat plane, and only in the very center of the frame. That's a problem. Instead you should try to cover as much of the frame as possible, and also different heights, not just a plane. In your example don't just track the markers in the center of your frame, but instead also track for example the scissors, the pencil, the background objects.

I tested it with latest master on elementaryOS 0.4.1. and it renders a nice and round ball.

Did you also try with the most recent version of Blender from builder.blender.org?

Just noticed that also the eyedropper tool to pick other things like parent objects, camera focal distance etc. doesnt work anymore.

@Sergey Sharybin (sergey) Thanks! I tried the patch, but it did not work. Neither the MCE nor the IE can open the image. If I try, it gives me an error: IMB_ibImageFromMemory: unknown fileformat (/home/sebastian/1-38_A002.0000811.dpx)
I'll open a report.

What a pleasant coincidence! I just had the problem a few days ago that I could not load a DPX file into Blender which I got from some other application. I used EXR instead as workaround. But I tried the patch and that actually works (even though the frame itself is flipped)! Here's a frame from the sequence that did not work:

This is most likely the same issue as this one: https://developer.blender.org/T52802
And that one is confirmed and still open, so marking this report as confirmed as well. Not sure what the correct policy here would be though...

Here's a fix that seems to work:

True. I'd also consider this a bug. Not a dramatic one of course, but it is indeed an inconsistency...

That patch works great, thanks a lot! :)
But man, the ToS footage was soo much better than the one I have to deal with right now...

Oh alright, sorry. Thanks a lot for the answer! :)

Yeah, I agree. Also, playblast from viewport should ideally not be affected by filmic.
Although, thinking about it, it probably is not really a bug, but rather a TODO…

Please follow the bug reporting guidelines and make sure you include the following information in your bug report:

Yeah, I am currently suffering from the same problem. I think it's mainly a problem with the very bright intensities of glossy reflections. At least in my case it doesn't need any SSS to produce the issue, just a rather reflective surface. I am facing this problem mostly with metals in scenes with bright lamps. I think the denoiser somehow tries compensate for the brightness differences between the glossy reflection and the much darker surrounding areas, and by overcompensating that brightness differences it makes the problematic areas black. Or something like that. No idea how to solve that but maybe as a workaround the denoiser could just keep the super bright highlights just white?
Here's the above file but without SSS and point lamp, but with a metal surface, still producing a black artefact.

Oh that's right, I did not test previous versions before. Probably never worked, at least not in 2.77 which I just tried.

Yes, here is a file demonstrating the issue (GTX980ti here, on linux).

Yeah, it's true. Not quite sure if it's actually a bug, but it's annoying nonetheless. However, I think we can be sure that it will be more than fixed in 2.8 ;)

I didn't test this yet, but I can see how this can be quite useful, especially in large and complex nodetrees with long noodle connections, where you want to compare the effect of a node input with the original node input value. Visually it is consistent with the red color of the mute node functionality and seems pretty straight forward to use.

At least on a GTX1080 with Cuda on Linux and latest master it does not happen. So probably it's more an issue with AMD Cards, OpenCL or OSX.

Thanks for the report. However, this is very similar to a recent report about custom transform orientations, which turned out not to be a bug. Especially Extrude works totally as intended. See my answer in the other report here: https://developer.blender.org/T52558
It might be a bit counter-intuitive (though thinking bout it I wouldn't even agree to that), but it's not a bug, therefore I am closing this.
Unless you find another case except extrude where custom orientations do not work. If so, please describe in detail where and when it happens.

Yep, turning off AO solves your problem. No bug here, this report can be closed then, I guess...

It seems to me you are trying to open an OBJ file, which for some reason got renamed to .blend. Anyhow, without the attached file we cannot reproduce or test your bug report.
Also, please use the bug reporting guidelines, otherwise the report is considered incomplete.

Yeah, just displaying the finished tiles is totally fine. @Brecht Van Lommel (brecht)'s solution takes up even less space in the interface! Win-win! :)

I replied in the other report as well.
And yeah, I also think it should be changed. It might not be a code bug, but a grammar bug it definitely is. For instance it says it is working on tile 11 from 12, when it is actually working on tile 12 from 12. A bit confusing for the user.

I think that is actually weird as well. If I have 12 tiles in total it would report "Path Tracing Tile 11/12" when working on the very last tile. Isn't that confusing for the user? It says it is working on tile 11 from 12, when it is actually working on tile 12 from 12. So maybe not a bug code wise, but definitely a grammar bug ;)