Issue was caused by BKE_vfont_to_curve() modifying curve->nurbs list which
gave threading issues.
Now added BKE_vfont_to_curve_nubase() which operates on a given nurbs list
base which is local in do_makeDispListCurveTypes().
By the looks of it it wouldn't give speed regression because previously it
also was creating nurbs for every font object sharing the same curve data.
Main issue here is that glBuf* calls were invoked from threads different than
main thread. This caused a crash (since those do not have a GL context active).
Fix here is twofold:
* add an ID buffer in buffer pool that handles pbvh buffers and is freed
from main thread when gpu_buffer_pool_free_unused is called.
* do not create glbuffers in derivedmesh creation routine, rather tag nodes
for update and create those in the draw function
(guaranteed to be called from main thread)
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D169
Added an API method to Text datablocks for moving the cursor to a specific line in the
file. This makes it possible to reset the cursor position at the end of the sysinfo
operator.
Issue seems to be caused by thread-unsafe IMB_freeImBuf.
Now use generic BKE_image_release_ibuf to de-reference
image buffer which was acquired from image datablock.
EditFont's use of Curve.len was very confusing, in editmode it
represented the number of characters, in object mode the number of
bytes. add Curve.len_wchar and keep track of both.
Also don't convert the editmode text into utf8 on every keystroke.
Now this is done on exiting editmode or save - to match most other
object types.
This also fixes curves 'body_format' being reported with an invalid size.
Made the system around splines order a bit smarter, so
crating a segment between two splines wouldn't switch
direction if splines are selected in a way that they're
"co-linear".
It is possible to make things even smarter using active
point and so, but that i'd consider a TODO.
Made it so scopes image buffer is displayed without any additional scale
applied on them,
Further tweaks are possible here, but that i'd consider a TODO.
Clarified the tooltip/description on the LatticePoint.co property to make it
clear that it shouldn't be edited, and that LatticePoint.co_deform should be
used instead.
This mode is designed for passive 3D TV: the viewport is split
horizontally - left eye above, right eye below - but the original camera
viewport is squashed in each half (with half the vertical resolution).
This is necessary to restore the aspect ratio in the 3D output because the TV expands each half to the full screen size.
That was nothing really wrong with the old short used for
direction, but that became kinda annoying because of compiler
idiocy which considered direction might have been zero.
Using explicit dual-state flag is more clear anyway.
