Movie cache is using global memory limitor, which isn't thread safe
in some of operations, so it required to add mutex around limitor
operations in movie cache.
It's probably could be solved in a way with less locks involved by
using different limitor for different areas (like use own limitor
for clips, own limitor for sequencer and so), but that wouldn't be
so easy to control overall memory usage.
--
svn merge -r50125:50126 ^/branches/soc-2011-tomato
Currently float buffers are always linear, space of byte buffer is defined by
rect_colorspace property.
Replaced logic of IMB_rect_from_float and IMB_float_from_rect to use this
assumptions (before it was special function used in some areas only, now it's
default behavior).
Almost all functions from ImBuf module which are actually used are got rid from
profile flag. Only remained issue is IMB_float_profile_ensure which only used by
CIneon/DPX exporter which is broken for a while already. Need to be fixed
separately.
This also fixed clone brush when cloning byte image on top of float, before
this result would be gamma-corrected twice.
Use OCIO stub file with hardcoded displays, views and color spaces.
Intended to behave in the same way as old implementation, just it's
now more clear code with much fewer ifdef checks.
Also should make it possible to get rid of ibuf's profile flag.
Thanks Brecht van Lommel for this patch!
Before this color space settings in image/movie clip data blocks
defined space in which loaded image buffer is, based on whether
this buffer contains float or byte buffer. This didn't work well
for formats like 16bit PNG, which are in fact non-linear formats
but were represented in Blender as float buffers.
Now image buffer loader is responsible to set up input default
color space for image/movie clip data blocks, which could be
based on format itself only or on particular file properties.
This means image/movie clip data blocks' input colorspace will
be initialized at time first image buffer is loaded.
This also resolves old confusing thing with image buffer's profile
flag, which in could have been non-linear for image buffer which
contained float buffer only -- this happened in mentioned case of
16 bit PNG format, i.e. Now float buffer would always be linear
which should make it easier to get rid of image buffer's profile.
This avoids having bunch of cached images when doing animation rendering,
keeping all the memory available for rendered itself.
This keeps memory usage low when rendering huge edits with mixed
scenes and movie strips.
This should not affect on sped of video encoding, which was confirmed by
some own tests.
--
svn merge -r50051:50052 ^/branches/soc-2011-tomato
- freeing a mask from RNA BKE_libblock_free() twice on the mask.
- loading a new blend file would only free the mask and not unlink it from nodes - it would access freed memory.
In this case sequencer would allocate empty image buffer which used to not to
have assigned color spaces but it was marked as non-linear float.
Assuming black would always be black in sequencer's color space no additional
transformation for display is needed.
Solved by removing NOLINEAR_FLOAT flag from image buffers and using check
image buffer's float_colorspace for NULL when needed to check whether float
buffer is linear or not.
vertices. Previously it would hide particles by creating invalid faces, but this
didn't make the vertices actually disappear.
Also found that it could generated corrupt geometry for cases with faces, which
gave wrong subsurf and could crash in edit mode.
* Non-Progressive UI couldn't be displayed if the device was set to GPU, but User Preferences Device was NULL. (for example when opening .blend file on another computer without GPU capabilities)
* Fix missing update in the Properties editor, when changing compute_device.
This fixes [#32115] OSX and cycles no non-progessive sample input settings appearing in interface.
running BM_CHECK_ELEMENT was taking over 75% of the time to subdivide a mesh, since this only reports errors, and is so slow - only run this on non-release builds.
