[Bf-committers] Large sequencer cleanup

[neXyon]

  Hi Peter!

I haven't tried out your patch yet, but the improvements sound really 
nice! The sequencer definitely needs some love.

About the grandma understanding the code, there's one thing that's 
pretty confusing: all that startofs, anim_startofs, startdisp, 
startstill attributes, all with end instead of start also and length and 
so on. So it would be nice to drop some (most) of these attributes from 
the structs to the least minimum and calculate the dropped ones on the 
fly (as far as I have noticed calc_sequence and calc_sequence_display 
are called so often that the attributes can definitely be calculated 
when they're needed without getting a real performance loss). And then 
it would be nice to have a clear documentation what value/function 
returns what at some place (wiki?).

As part of that recode of cfra to float I wonder if it would be better 
to change cfra to a time value that holds seconds? I guess that's a 
general discussion topic that can even be considered for the whole 
blender code. Well it's just a quick idea, I have no clue what problems 
could arise from that.

One more thing is if you could have a look at the drawseqwave function 
in sequencer_draw.c, you see there that sound_read_sound_buffer is 
called and everytime a quite huge buffer is alloced and freed again. 
Although that's only done for sounds where the raw PCM samples are 
already loaded into RAM it's quite slow and makes it nearly impossible 
to use with even one music strip of 3 minutes length, so I wondered if 
you would be as kind as to add a caching mechanism here too.

Regards,
neXyon

> Hi,
>
> the last three days, I cleaned up / rewrote large parts of the sequencer
> code, to accomplish the following things:
>
> * make cfra a float internally to enable sub-frame precision rendering
>     with speed effects and make the code a lot clearer
> * remove the whole TStripelem mumbo jumbo (is necessary, since cfra is a
>     float now, right?)
> * replacing it with a hashtable based caching system
> * thereby dropping memory usage of the sequencer to a fraction of it's
>     current usage (80 MB without using any caches to approximately 5 MB on
>     a 3 hour timeline)
> * thereby making the cache limitor drop the full imbufs (no more clicking
>     on refresh from time to time anymore)
> * thereby make cutting a lot snappier, since freeing up the imbufs is just
>     about dropping the contents of the current hashtable and not traversing
>     really large arrays of null pointers...
> * prepare the code for multi-core usage (threaded rendering is disabled
>     right now, but the old code was limited to two cores anyways, because of
>     this TStripElem hell)
> * and: make the code so easy to understand, that your grandma will get
>     hold of it (hopefully)
>
> I did some test editing, nothing crashes, no memory leaks, everything
> seems happy, but: can I commit or should I wait some days to let Blender
> 2.53 settle?
>
> Patch is here for reference:
> http://peter.schlaile.de/blender/seq_cache_rewrite.diff
>
> Only thing missing is frame blending in Movie and Image strips on speed
> effect input (which is still largely broken, so most people won't really
> notice...)
>
> This will come back shortly as an option for Movie and Image strips.
> (Which will be able to adapt to different frame rates directly for free
> on the way, since, cfra is now a float :) ...)
>
> Cheers,
> Peter
>
> ----
> Peter Schlaile
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers