Page MenuHome

Fix T68950: Adding lots of edge loops to cylinder produces a crash
ClosedPublic

Authored by Huseyin Karakullukcu (imgeself) on Fri, Aug 23, 9:48 PM.

Details

Summary

Instead of fixed size, IMM_BUFFER_SIZE is adjustable now. The internal buffer can expand if there is a need a bigger buffer. All other behaviors are still the same.

Diff Detail

Repository
rB Blender

Event Timeline

Clément Foucault (fclem) requested changes to this revision.Mon, Aug 26, 2:30 AM

I would prefer that the buffer returns to it's default size if it is too big.

This revision now requires changes to proceed.Mon, Aug 26, 2:30 AM

The buffer size never shrinks, shouldn't the immediate mode buffer expand as neeeded and returns to it's default size on immUnbindProgram?

IMM_BUFFER_SIZE is shrinks on immUnbindProgram

In immBegin, it seems wrong that available_bytes is immediately based off the value produced in the imm_buffer_size = bytes_needed line. Those extra bytes are not available yet, but the rest of the logic assumes they will be and it could actually skip the glBufferData call below depending on the outcome of the if ((bytes_needed + pre_padding) <= available_bytes) conditional.

Since new buffer size will be the same value as bytes_needed, I thought if ((bytes_needed + pre_padding) <= available_bytes) conditional was always going to fail and the code was going to create a new fresh buffer with the new size. It will most of the time but not always. If imm.buffer_offset and pre_padding are 0, the conditional is going to succeed because available_bytes will be equal to bytes_needed and it is going to skip new buffer creation code. You are right @Jesse Y (deadpin), I should handle this case.

Ensure the internal buffer will be recreated after size expand and size shrink. Shrink the internal buffer on immBegin.

Looks good to me. Thanks!

This revision is now accepted and ready to land.Thu, Aug 29, 1:47 PM