Full log is here:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability#Matcap_in_3D_viewport
Implementation notes:
- Matcaps are an extension of Solid draw mode, and don't show in other drawmodes.
(It's mostly intended to aid modeling/sculpt)
- By design, Matcaps are a UI feature, and only stored locally for the UI itself, and
won't affect rendering or materials.
- Currently a set of 16 (GPL licensed) Matcaps have been compiled into Blender.
It doesn't take memory or cpu time, until you use it.
- Brush Icons and Matcaps use same code now, and only get generated/allocated on
actually using it (instead of on startup).
- The current set might get new or different images still, based on user feedback.
- Matcap images are 512x512 pixels, so each image takes 1 Mb memory. Unused matcaps get
freed immediately. The Matcap icon previews (128x128 pixels) stay in memory.
- Loading own matcap image files will be added later. That needs design and code work
to get it stable and memory-friendly.
- The GLSL code uses the ID PreviewImage for matcaps. I tested it using the existing
Material previews, which has its limits... especially for textured previews the
normal-mapped matcap won't look good.
It was caused by own mistake by not noticing externtex is used not
only by render engine. Now this function uses pool passed as argument
rather than using R.pool.
StrokeVertex.point2d() instead of .getPoint(). It is noted that .point2d()
returns a 3-dimensional vector representing a 2D-projected point, with the z
component indicating a normalized depth of the original 3D point, whereas
.getPoint() returns a plain 2-dimensional vector. This fix should have been
done in revision 48510...
Also made fix for callers of Stroke.Resample() not calling stroke.UpdateLength().
Previously normalization will happen per image buffer individually, which
was wrong in cases different faces of the sane mesh uses different images.
Also solved possible threading issues when calculating min.max displacement.
Switch selection from Release to Click, so releasing mouse button
after transform confirmation wouldn't trigger selection operator.
However, needed to disable old Click behavior which used to deselect
everything if click happened outside of any object. It wad bad way
to do such a behavior and shall be re-think and solved in a better
way.
This bug did not appear earlier because the "" default context was actually never used, always NULL context was passed instead. But bpy.app.translations uses "" as default context in its keys (simplifies the hash/comp functions of internal py messages cache)...
So now, Blender prefers NULL (None in python) as default context value, but understands also "" as such.
This will calculate maximal distance automatically and normalize displacement
to it. Before this change normalization will not happen at all in cases max
distance is not set manually.
This affects on "regular" baker only, there are still some fixes to come for
multiresolution baker, but that could be solved separately.
It was caused by image threading safe commit and it was noticeable
only on really multi-core CPU (like dual-socket Xeon stations), was
not visible on core i7 machine.
The reason of slowdown was spinlock around image buffer referencing,
which lead to lots of cores waiting for single core and using image
buffer after it was referenced was not so much longer than doing
reference itself.
The most clear solution here seemed to be introducing Image Pool
which will contain list of loaded and referenced image buffers, so
all threads could skip lock if the pool is used for reading only.
Lock only needed in cases when buffer for requested image user is
missing in the pool. This lock will happen only once per image so
overall amount of locks is much less that it was before.
To operate with pool:
- BKE_image_pool_new() creates new pool
- BKE_image_pool_free() destroys pool and dereferences all image
buffers which were loaded to it
- BKE_image_pool_acquire_ibuf() returns image buffer for given
image and user. Pool could be NULL and in this case fallback to
BKE_image_acquire_ibuf will happen.
This helps to avoid lots to if(poll) checks in image sampling
code.
- BKE_image_pool_release_ibuf releases image buffer. In fact, it
will only do something if pool is NULL, in all other case it'll
equal to DoNothing operation.
