In fact, there's no need to get float buffer at all,
conversion could be done in pixel processor level
after interpolation.
It might give slightly worse interpolation results
(which i'm not sure would be visible by eye) but
it gives more than 2x speedup on my laptop on node
setups used for warping image.
--
svn merge -r58988:58989 ^/branches/soc-2011-tomato
This commit includes all the changes made for plane tracker
in tomato branch.
Movie clip editor changes:
- Artist might create a plane track out of multiple point
tracks which belongs to the same track (minimum amount of
point tracks is 4, maximum is not actually limited).
When new plane track is added, it's getting "tracked"
across all point tracks, which makes it stick to the same
plane point tracks belong to.
- After plane track was added, it need to be manually adjusted
in a way it covers feature one might to mask/replace.
General transform tools (G, R, S) or sliding corners with
a mouse could be sued for this. Plane corner which
corresponds to left bottom image corner has got X/Y axis
on it (red is for X axis, green for Y).
- Re-adjusting plane corners makes plane to be "re-tracked"
for the frames sequence between current frame and next
and previous keyframes.
- Kayframes might be removed from the plane, using Shit-X
(Marker Delete) operator. However, currently manual
re-adjustment or "re-track" trigger is needed.
Compositor changes:
- Added new node called Plane Track Deform.
- User selects which plane track to use (for this he need
to select movie clip datablock, object and track names).
- Node gets an image input, which need to be warped into
the plane.
- Node outputs:
* Input image warped into the plane.
* Plane, rasterized to a mask.
Masking changes:
- Mask points might be parented to a plane track, which
makes this point deforming in a way as if it belongs
to the tracked plane.
Some video tutorials are available:
- Coder video: http://www.youtube.com/watch?v=vISEwqNHqe4
- Artist video: https://vimeo.com/71727578
This is mine and Keir's holiday code project :)
- Re-arrange locks, so no actual memory allocation
(which is relatively slow) happens from inside
the lock. operation system will take care of locks
which might be needed there on it's own.
- Use spin lock instead of mutex, since it's just
list operations happens from inside lock, no need
in mutex here.
- Use atomic operations for memory in use and total
used blocks counters.
This makes guarded allocator almost the same speed
as non-guarded one in files from Tube project.
There're still MemHead/MemTail overhead which might
be bad for CPU cache utilization.
TODO: We need smarter 32/64bit compile-time check,
currently i'm afraid only x86 CPU family is
detecting reliably.
* FIX: selecting bookmark or recent file caused UNDO push, also caused issue with the 'Open' and 'Cancel' buttons being grayed out.
Reported by Sergey Sharybin in IRC, many thanks.
Creating new splines via Python API didn't take
curve dimension into account.
Now adding new splines will set 2D/3D flag for
spline according to curve's dimension.
This is getting confused, why bevel is handled different
for 2D and 3D curves?
Anyway, made bevel work for 2D case nice again, but it's
probably nice to unify 2D and 3D cases.
Namely, it caused nodes be adding to the pool multiple times.
Returned spin back, but use it only in cases node valency is
zero. So now valency is decreasing without any locks, then
if it's zero spin lock happens, node color (which indicates
whether node is scheduled or not) happens. Actual new task
creation happens outside of locks.
This might sound a bit complicated, but it's straightforward
code which is free from any thread synchronization latency.
- allow negative index values.
- error when invalid index value are passed in.
- remove last item if no index argument is given.
also change behavior to remove the material slot, it was only clearning by default but the list length remained the same.
Particle system code used global variable to sort hair by orig index,
which is not safe for threading at all.
Replaced this with usage of reentrant version of qsort, which is
now implemented in BLI. It was moved from recast navigation code
to BLI, so more areas could use it (if needed).
This replaces code (pseudo-code):
spin_lock();
update_child_dag_nodes();
schedule_new_nodes();
spin_unlock();
with:
update_child_dag_nodes_with_atomic_ops();
schedule_new_nodes();
The reason for this is that scheduling new nodes implies
mutex lock, and having spin around it is a bad idea.
Alternatives could have been to use spinlock around
child nodes update only, but that would either imply having
either per-node spin-lock or using array to put nodes
ready for update to an array.
Didn't like an alternatives, using atomic operations makes
code much easier to follow, keeps data-flow on cpu nice.
Same atomic ops might be used in other performance-critical
areas later.
Using atomic ops implementation from jemalloc project.
Some places like proxy rebuild didn't increent
custom shape user counter which lead to user
decrement errors later when freeing pose channels.
Try to keep custom object counter relevent, but
some corner cases might still be missing.
