Konstantin's weekly report #32

Hello, everyone!

The priority of this month is “Rendering speed optimization” and last week me and Ivan had an initial brainstorm meeting. In fact, most of ideas come from Ivan, I’ve just try to give a quick outline here.

First major performance leak, identified by Ivan, is about the way how current rendering system apply layer transformations.

Imagine if we have a shape layer and it is put into some group, which applies some translation/rotation/scale to it. Then it put into another group with some other translation/rotation/scale.

In current implementation Synfig walks down this hierarchy and uses transformation stack to calculate the required rendering area for shape layer. This is the first pass. Then the shape layer is rendered, Synfig takes the result and walks back by the hierarchy from down to upper level, applying the transformation for EACH group. This is a second pass.

The plan of Ivan is to eliminate redundant transformations on the second pass. On the first pass Synfig will collect all transformation stack and create the transformation matrix, which will be applied to the vector data of shape layer. In this case, the shape layer will be rendered initially RIGHT IN PLACE. And Synfig won’t need to apply time-consuming transformations on the second pass.

Ivan is sure that the same approach could be applied to other layers, like Blur, Twirl, etc. That will change the way how they calculate the result. For example, in case of Blur Layer the blur area is not guaranteed to be a circle anymore - in general case it becomes a scewed ellipse.

We have named this optimization a “Reworked Transformation Stack”.

Second performance leak, identified by Ivan is the excessive triangulation for shapes. In current implementation the triangulation for shapes is done without a consideration of Rendering context. That leads to excessive drawing operation (each shape is a polygon, with too much vertices). Fix of this situation should also deliver the speed boost.

So this is what we planned for optimization at the moment.

In addition to all said above, last week Ivan have been working on finishing the “bone multilink” feature. Finally he have first results to show - now you can quickly link complex shapes to the whole skeleton. The vertex is defined by bone influence area.
See demonstration in this video - http://youtu.be/NY0uYYDxewQ

Last week we also got a fix from Djay - synfig.org/issues/thebuggeni … issues/325 (Color panel now updates when HTML code color is written).

Also, this week we have launched a fundraising campaign for April -
As usual, we appreciate your help in spreading a word.

Thank you!

From what I understand Cairo library can already do this. Just push/pop matrices into the transform stack and the render operations are executed under the current transformation matrix.

For regions and outlines of fixed line width cairo can be used to render the curves directly without the need for subdivision.

For variable width outlines some method would be needed to calculate the curves which describe the outline. That means calculating offset curves to the base spline. Use lib2geom maybe?

The Synfig homepage still has the March campaign on it.

Right. Cairo already does that. But Cairo introduces bottlenecks for raster operations.
By implementing this for Software renderer we are opening a way to implement the same optimizations for raster operations (see my note about the Blur effect).

The problem is that curves in Synfig aren’t strictly a “Splines”. :slight_smile:

Personally I think it is the other way around: Raster operations introduces bottlenecks for cairo render. :wink:

Synfig is supposedly a vector graphics animation program. IMO, the supported raster operations should not hold back further development. We can keep them there as legacy features, but no need to keep optimizing them.

The current transformation matrix can be obtained from the cairo context. That can be used to modify how blurs and other raster operation layers work.

IIRC , they are sequences of bezier segments (which lib2geom can handle). There surely must be a way to calculate the shape of Synfig outlines without the need to subdivide into a lot of straight line segments.

Anyway, if you guys are going to keep the subdivision scheme for outlines then might want to check Adaptive Subdivision of Bezier Curves.