| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Replacing the flags isn't thread safe and could lead to bi troubles.
Such things are to be handled by the dependency graph.
|
|
|
|
|
|
Previously this only worked for some datablocks relevant to rendering, now it
can be used to detect if any type of datablock was added or removed (but not
yet to detect if it was modified, we need many more depsgraph tags for that).
Most of the changes are some function parameter changes, the important parts
are the DAG_id_type_tag calls.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D195
|
|
This goes back to ancient era again and such a call isn't
safe for threading and really DAG is to make it sure display
list for dependencies is always there.
|
|
|
|
|
|
|
|
resolves T38079
|
|
|
|
|
|
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.
|
|
|
|
Oversight in own recent commit to avoid allocating a new wchar_t array.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Solved by adding RW lock to BKE_vfont_to_curve.
So now all the threads are allowed to read chars from ghash,
but they'll be locked as soon as one thread would need to load
more chars from font to the ghash.
|
|
|
|
also remove redundant call to wcslen and ensure FT_Init_FreeType runs
once the font loads.
|
|
|
|
|
|
G.is_rendering
|
|
Getting vfont data wasn't safe for threading, because it
was modifying font data which is in bmain and could be
shared by multiple objects.
For now made it so getting vfont uses critical section,
meaning vfont->data is initializing from inside a locked
mutex.
--
svn merge -r58168:58169 ^/branches/soc-2013-depsgraph_mt
|
|
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now data which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
Actually, this commit also contains wrapping runtime curve
members into own structure
This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
|
|
- BLI_strncpy_wchar_from_utf8 wasn't NULL terminating the destination string, caused uninitialized memory use in BPY_python_start().
- BLI_strncpy_wchar_as_utf8 could write one byte past the buffer bounds.
|
|
some areas of the python api, bmesh.
|
|
|
|
|
|
path_util_split_dirstring_2.patch, path_util_split_dirstring_3.patch
from Lawrence D'Oliveiro (ldo)
Get rid of BLI_splitdirstring, replace with calls to BLI_split_dirfile, BLI_split_dir_part and BLI_split_file_part as appropriate.
|
|
|
|
- minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
|
|
|
|
|
|
BKE_utildefines is now unused but keep incase we want to add defines there later.
|
|
|
|
memory for loaded fonts, not store as a temp var in the fonts.
|
|
references in bmesh docs.
|
|
|
|
|
|
|
|
- replace (strcmp(vfont->name, FO_BUILTIN_NAME) == 0) with (BKE_vfont_is_builtin(vfont)).
- reduce some double promotions.
|
|
- don't overwrite the font path with "<builtin>" when the font file cant be found, it caused bad problems when loading files on someone elses systems when paths couldn't be found blender would silently clobber paths (tsk tsk).
- when fonts are freed their temp data is now freed too.
- assigning a new filepath to a font now refreshes the object data.
|
|
|
|
macros which results in calling the function multiple times needlessly.
also added some comments.
|
