[Bf-committers] Tiles status

[Jeroen Bakker]

Hi

On 05/05/2012 12:48 AM, Campbell Barton wrote:
> Hi Jeroen,
>
> Can you give some details on how the old compo code will be kept? -
> ifdef'd? or disconnect it but dont remove the C files for a while?,
> have as some runtime switch?
In the file node_composite_tree.c the function ntreeCompositExecTree is 
changed to execute the compositor using the new system (COM_execute). 
All other execution code of the old compositor is not modified.

I don't favor to have a switch between the two compositors, but this can 
be realized with ease (and has been tested).

The old compositor engine is inside the node_composite_tree.c file. The 
node implementations are in the node_composite_<node>.c files. when 
cleaning up these files will be cleaned to only hold node editing stuff. 
all node execution stuff will be removed.


>
>
> Heres some feedback on things that may be helpful to do before the
> merge (keep in mind I dont do compositing or know c++, ack!) - so this
> stuff is general.
>
> ---
>
> We had hard to track memory leaks with GHOST and the Game engine,
> would be good if you added:
> WITH_CXX_GUARDEDALLOC ifdef - to all compositor classes. This does an
> opt-in use of guardedalloc (advanced cmake build option) which reports
> unfreed C++ classes, (realize there are other leak detection tools but
> found this a lot more handy to debug with since unfreed memory is
> identified), being opt-in it wont slow down release builds.
I will look into this.
>
> Would be good if you run 3-4 fairly complex node setups with valgrind,
> (overnight perhaps, its slow!) - may need to drop the resolution a
> bit, but should still be useful and detecting un-initialized memory. -
> possibly this isnt an issue, but this is relatively easy to test so
> IMHO its worth it if you didnt already.
We have done such a test when we had some memory/threading -issues 
around Januari. They have all been solved. Perhaps we could do a huge 
setup just to be sure.

>
> This is a bit more work but can be worth it...
> Build with clang-static checker, C++ doesnt work as well as C. but
> still functional IIRC.
> http://wiki.blender.org/index.php/User:Ideasman42/BlenderClang
Didn't know we had such a system in place. Good to know. Perhaps we need 
some help to set this up, but saw that Ubuntu has a software package for 
installing llvm/clang.

Thanks for the feedback.