@Alexandr Zinovev (raa), this is caused by rBfa63515c3758: Fix: Use "round" instead of "floor" in snapping UI to pixels.

The issue is caused by rB5abae51. Assigning to @Alexander Romanov (a.romanov) for further investigation.

Can this be reverted to the previous behavior before the release? I depend on this very often in my work.

We have a BF Blender:_regressions tag just for them, no need to increase priority here. ;)

Developer note:

I can't think of a single use case where handling each vertex is more preferable than island during translate operation. But I can bring a lot use cases for handling whole island in hard surface area, including jewelry modeling.

@Germano Cavalcante (mano-wii) I’d bet change in behavior is due to rB21f376780941f986e99?

The reason why saving multi-layer layer with F3 gives different name is because Blender uses passes names for EXR passes. But you can call passes arbitrary in EXR, could also be "mammonth's banana". So not sure how this indicates a problem?

Hm, this special handling for Combined->Image+Alpha is really a PITA...

This is yet another bug caused by no-functional-changes commit :(

@Aaron Carlisle (Blendify) ffmpeg gets the length right because the duration (in frames) has doubled as well as the tbr. If you let Blender change the scene rate to whatever ffmpeg tells it, the length in elapsed time is correct.

If there were an issue, it would be a regression since 01fa4fb6 but I suspect the duplicated timebase is correct for paff-encoded video, see also tickets #3339 and #5378. In any case, there is most likely a bug in blender as FFmpeg always detects the correct length of the clip, no matter the timebase

The bug does not occur anymore in the latest nightly (blender-2.78-56d3cc9341-linux-glibc219-x86_64).

@Howard Trickey (howardt) guess that one is for you? Thanks :)

This works! Thank you very much!

Okay, the bell rang loud here so i checkout one commit before "fd7e9f7 Cycles: Fix pointiness attribute giving wrong results with autosplit" and this worked again. So the culprit is found and the task attached to the right person :P

Did some more investigation and extracted a simplified testcase from victor. It consist only one tree + material. The hang goes away if you either disable multires or cut both pointiness routes !

To be more precise:
I disabled renderability of multires/subsurf for some "critical"
objects ( GEO_tree_sculpt and GEO_rocked_detailed ) and the sychronize is way faster an i came to render again.
Also: Exactly whats stallling is only the "synchronize" part.

Bisected it back to rB6f92604 , @Sergey Sharybin (sergey) seems there's a data race in the meta data, can you take a peek?

Hi Julian,

Hmmm, after quite some investigation I conclude this is wrong usage of our popup code. It's a similar issue as T49199, but much trickier.

@Julian Eisel (Severin), another one caused by rB4559229.

If you have a closer look then you'll see that the list is only covering revisions from 7c53260 to 417847c and can not be covering this bugfix. This list will be revisited tomorrow before we do final AHOY and surely such a regression fix will be included there.

I saw the meeting notes today and noticed that this fix was not part of the revisions for 2.78a

Fix committed. I rewrote the entire thing since it was difficult to understand, hopefully more clear now what it is going on.

Thanks for the links.

does there exist a diagram that explains the spherical stereo camera model?