Please check if your GPU driver is up-to-date.

I cannot reproduce the bug. Can you try the latest version of Blender, please?

I'm able to reproduce the issue in the version you mentioned, but not in latest master. So, I guess this is fixed already. Please test if it works in tomorrows build.

I was able to reproduce the bug in the version you mention, but not in the latest master. So I guess it is fixed already. Please test if it works in tomorrows build.

I cannot reproduce the issue. I can select them just fine. Which keymap do you use?

Not a bug, in that example you have to increase Max Shape Angle to something greater than 90 degrees.

BLI_listbase_count(tracksbase_src) = 1 and BLI_listbase_count(tracksbase_dst) = 2, but the code seems to assume that both lists have the same length.

@Bastien Montagne (mont29), seems to be a continuation of T59850 :(

Can reproduce.

@William Reynish (billreynish) @Dalai Felinto (dfelinto), what exactly should be sorted when this is enabled?

@Andrei Salamandic (andreymd87) can you provide a simple example .fbx file, please?

@Philipp Oeser (lichtwerk), then please also commit the fix mentioned by sergey.

Thanks. Unfortunately, BKE_curve_copy_data is not called when ID_RECALC_SELECT is used in ED_curve_editnurb_select_pick. However, it is called when ID_RECALC_ALL is used.

The alpha is premultiplied with the color values in IMB_colormanagement_imbuf_to_srgb_texture, even though Alpha is set to "Straight". Is that correct?
There is nothing the gpu can do here, because the color information is lost in the premultiplication.

@Sergey Sharybin (sergey), the issues seems to be that when tagging the curve with ID_RECALC_SELECT, cu->actvert is not copied to the curve-copy in the depsgraph. Is there a place where this just has to be added?

ok, in that case I don't really know at which level this is wrong.

I don't think this is a bug currently, that is just how it works for now.

I could not reproduce it yet.

I can see that there is some selection behavior that I don't understand and that seems buggy. Can you reproduce this in a new file?

In D4916#112455, @Brecht Van Lommel (brecht) wrote:

Forgot the * 2? Otherwise looks good.

• ensure new buffer always has at least len unused bytes

The code looks correct to me, but I still have to learn the new depsgraph API. @Sergey Sharybin (sergey) should say if this is the right usage.

Looks like the issue here is that Output -> Post Processing -> Sequencer is enabled in the properties editor.
Without it, it seems render correctly. Can you confirm that?

I left the define because I was not sure if that variable was used in some other place, I'm new modifying this kind of code, so you mean that I just create a function "static int MAX_PARTICLES_PER_TASK(void)" and call that function instead of using the variable?

Just one minor thing. Other than that seems fine.

• Generally seems like a good idea to use another number than 256. Can you provide a test file that allows us to easily verify the performance increase?
• Please remove the old comment, it does not add any value. Also remove the timing code which should not be part of this patch.
• I think it should not be a define anymore after this change. Just use a normal function call.
• Please run clang-format (make format) on the changes to ensure that the code style is correct.

I cannot reproduce it.
@Tomasz Kaye (bitbutter), can you upload the .blend file please?
Can you reproduce the issue from the default startup file?

Personally I'm wondering why x should be a special case here. Why not have an enum with CURSOR_WRAP_X, CURSOR_WRAP_Y and CURSOR_WRAP_XY and pass it to WM_cursor_grab_enable. That seems much cleaner to me.

hm the unit says "px", so I used it as pixels. I can also just multiply it with the UI scale, yes.

That is certainly a threading issue. I can have these two call stacks at the same time:

rB5ce3f69da438bf2bd58d5039f8a4165f31262e1e

rB5ce3f69da438bf2bd58d5039f8a4165f31262e1e