(Obvious thinking is change to BKE_libblock_alloc(), of course, but… what?)

Lots of investigations already, with very little results…

Seems like rB556942ec0782c5641c removed Z pass for non-render image nodes, not sure why…

Works fast. I hope someone review it someday. Its great for creating procedural textures ("Compositor nodetree" is better for this purpose than "texture nodetree" anyway).

Looks good to me, thanks for the patch!

even so, there is a certain behavior that has changed between the two versions, which means old files won't render the same way, and needs to incorporate new ways to work around them and without any new benefits!

This is a known limitation of old dependency graph, which is addressed by the new dependency graph.

Do not set priority of tasks yourself, especially not to high priorities!

And can you find out if this algorithm will improve? If the post process did DOF as well as the cycles, it would be very noticeable, but for the time being it is practically not applicable.

This is indeed a limitation of current Defocus node. The way it works is it calculates blur radius based on image depth and then applies variable size Bokeh blur. Such approach can not deal with such cases.

I think you are merely hitting the limits of post-processing DoF effect here… 'jagging' is actually merely blur disappearing at points where very out-of-focus pixels are neighbors of perfectly on focus plane ones, don't think post-processing can handle that situation better. Would be TODO anyway, imho, not a bug. @Sergey Sharybin (sergey) shall know more about that, though?

I have found that the builds after June 4th address the texture to scale distortion bug.

(for the records the original claim that clamping is the issue could be solved with P494, but RNA is already clamping the values before we get to the compositor, so this patch is uneeded)

This is not related to the directional blur node. Here is an even simpler file using another node:

Confirmed. Note to other testers on how to test it:

• Load file, enable auto-run scripts
• Switch viewport to rendered
• The viewport has nothing rendered.

The title is based on initial observations.
It is definitely a bug so I will leave it to developers to figure it out.

I see that too, and all I have to do is go Converter > Math and it renders corrupted. Even before I hook it up.
Title maybe should be changed to "....cause corrupted backdrop image"

Decided to play with the texture node before plugging it into Scale offset

In T51705#438514, @Aaron Carlisle (Blendify) wrote:

Please try with a build from builder.blender.org/download

Sorry about that!
Note taken.

There is no need of blend file.

Please try with a build from builder.blender.org/download

I have same crash with Win7 64 bit and ATI HD4670

In T51705#438461, @Joel Godin (FloridaJo) wrote:

Do you mean like this?

Yes, that's the setup that crashes Blender.
It was mentioned from another user I just replicated it on my machine.

Thanks for the report but it would be helpful if you add a blend-file to the report that demonstrates the issue at hand.

Do you mean like this?

Brought behavior back to how it was before. But i find this all weak, and some cleaner design (which follows artists' expectations instead of dictating them how to use something) is really needed in compositor.

@Aaron Carlisle (Blendify), so "squished" part i think we can investigate (as in "resolution" if you wish).