[Bf-committers] Tiles status
ideasman42 at gmail.com
Sat May 5 00:48:46 CEST 2012
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?
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.
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.
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.
If its a hassle to setup on your own system I can test on the system
currently used for http://clang.blenderheads.org/trunk/
cppcheck is less comprehensive but can still find bugs: "make
check_cppcheck' runs on all source but you could keep an eye out for
your own code in the report.
.... these are general things I've been doing after merges, but may
help to find bugs before merge too.
On Sat, May 5, 2012 at 4:02 AM, Jeroen Bakker <j.bakker at atmind.nl> wrote:
> Hello all.
> The testers say tiles is stable, only some crashes have been reported.
> All known crashes have been solved.
> There are some features that just work different in tiles. Some issues
> are feature requests. And some issues can be done after merging. The
> user documentation is still a bit behind, but there is not that much to
> document. UI is 95% the same as the old compositor.
> When merging to trunk, we will leave the old compositor in trunk. Just
> for functional reference and for case we need to roll-back to it. When
> all lights are green to release tiles. The old compositor will be removed.
> We are ready to commit to trunk. How do we proceed?
> There are some projects that can be started after Blender release 2.64 :
> * Buffered compositing: Tiles is not buffered. In some cases the old
> compositor is faster. We can make tiles buffered.
> * 3d compositing: add 3d image planes to the compositor. really nice
> for tracking
> * Canvas compositing: place an input anywhere on the canvas.
> * Update of the glare node: make it more professional :)
> Jeroen & Monique.
> - At Mind -
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers