Cairo Renderer Goals

Development Feature discussions
1

After a conversation with Genete, I thought we should take some time to discuss some of the goals/principles for our migration to a cairo-based renderer.

A new renderer could offer Synfig many benefits:

  1. Speed. This is main reason we’re undertaking this migration in the first place.
  2. Standardization. Bringing in more standard graphics concepts (including those used in cairo) will make it easier for Synfig to integrate with other graphics applications.
  3. Code simplicity/reuse. Having our own rendering infrastructure leads to a larger codebase and makes the project more difficult to maintain.

At the same time, some of Synfig’s unique features are harder to fit into the cairo framework:

  1. HDR colors: Synfig supports color ranges outside of the normal 0-255
  2. High bit depth: Cairo uses 8-bit depth, while Synfig uses floating-point color.
  3. Visually linear color scale (the one that makes Synfig color values differ from virtually every other graphics application)
  4. Blend methods: Cairo has less of them, and some blend methods with the same name behave differently.

I’m interested in knowing which of the features Cairo would bring you’re most interested it, and which of Synfig’s non-standard features are the least important to you. Also, do you think we should keep a plugin system for different renderers, or focus everything around the use of Cairo?

(Please tell me if I’ve missed something here)

Personally, I believe that standardization is the most import feature. I see speed as a consequence of using standard libraries and tools: the more a piece of software is used, the more effort is put into optimizing it. Likewise, using our own software and conventions when they do not offer a clear advantage over standard practices makes Synfig harder to use, and harder to develop.

Out of Synfig’s feature set, I don’t think it will be feasible to support HDR colors with cairo. I’m not sure how important high bit depth is, but I’m tempted to say that it’s less important for animation than for print and cinema. I would remove Synfig’s custom color scale, but rewrite the interpolation function between colors to behave as if the linear color scale were still in place. I like Synfig’s current blend methods, so I wouldn’t want to touch those.

Synfig doesn’t have a large number of developers, so I would rather focus efforts on a single rendering system than have support for multiple ones. I think it would be best to make cairo the only rendering API for Synfig. Then Synfig will be more standardized, easier to support, and easier for new developers to get into. If there’s a need for HDR and high-precision color, I would wrap whatever image buffers we’re currently using in a cairo-like API and pretend that they’re part of cairo.

2

I’ve built up quite a collection of work in Synfig based around the current renderer. If I can’t render those animations in new versions of Synfig Studio and have them looking identical to the way they looked when I created them, I would be a bit upset.

As I understood it, I thought Cairo would be used as the renderer in the Synfig Studio interface, but we’d keep the proper Synfig Renderer in Synfig itself for final renders.

If that’s the case, it doesn’t matter if Cairo doesn’t support everything Synfig Studio does, as the Cairo renderer is there to give you an impression of the finished result while you are working.

In fact, you could add various Cairo rendering options to the Synfig Studio GUI, for instance outlines with a different colour for each layer as you can in Flash.

If you add a Cario renderer option to the Synfig renderer and allow the user to chose which renderer to use for their final render, that’s really great too. Many projects would not use most of the features of the Synfig renderer and using a Cairo renderer to render them would be MUCH faster.

But if you have to replace the Synfig renderer with the Cairo renderer (and I can understand that it would make it much easier for you to maintain), then High bit depth colour is vital for video work (as it stops rather nasty banding on gradients) I can give you examples to show you why if you don’t know what effect this has.

Instead of just guessing what’s important, what I would do if I were you is ask Robert Quattlebaum WHY the features were added to Synfig’s renderer in the first place. Then at least you would have a much better idea based on factual information about why they are there and could make much more informed choices on whether to remove them or not.

Sorry that I sound really awkward and annoying - but I love using Synfig!

3

Thanks DaveJ!

I’m sorry that some of the ideas I had upset you. I’m not proposing to get rid of vital features, only to determine if some features are, in fact, not vital at all.

I have a fairly good idea about the technical reasons some of these were added:
HDR is used so that intermediate layers in a series of blends can have color values outside of the 0…1 range. I don’t know how many people use this in their compositions.
The linear color scale makes the mathematics of animating/interpolating colors easier, but it conceivably has other uses (like adding the RGB values of two colors via converting parameters, or via blend methods for that matter).

What matters more, though, is whether they’re actually used/needed. I thought that the best way to judge was to ask the artists here.

Could you answer another question for me: what render quality do you use for final animations? What about previews?

4

I’m afraid that I have to disagree with you nikitakit. The first purpose of add a new renderer on Synfig feature list is to obtain high render speed on the user interface to improve the user experience. For professional animators, the user interface responsiveness is critical for its business. Specially important is to:
a) Design in real time: user expect to have immediate visual feedback of the render result when the parameter is modified on the screen.
b) Play/timeline scrub in real time: user never want to preview the animation (pop up a window, wait its render & play) to see how the animation looks. User want to do that on the design area.

The final render time can be a bottle neck in some circumstances but there are tools to fight it. It is possible to use multiple (unattended) computers to do that, by splitting the animation in scenes and render them in parallel and of course use 24h/day to do that work. Computer’s time is always cheaper than animator’s time.

So, from the point of view of (any) user, there is not excuse to drop the current Software render. Final user will understand that using Cairo when speed is critical, implies to loose some of the features but what user won’t understand is to loose those features when speed is not critical.

If the code gets more complex to maintain by the introduction of another renderer, our challenge is to keep it more easy to maintain and document, and to re factorize the internals of Synfig to achieve that.

Backward compatibility is obligated from my point of view. Break it is a not good idea I think. So for good or bad for coders, software renderer must be kept and its maintenance has to be done in any case.

Even more, I would like to continue exploring other libraries to give high speed render support for those Synfig’s features that Cairo doesn’t support. For the moment we have started with Cairo but more has to come in (GEGL, OpenGL/VG).

-G

5

No, I was worried I’d upset you! I wouldn’t be able to do anything useful in Synfig without your Inkscape Exporter so I’m glad you’re not mad with me!

All that worries me is that one day I’ll load my sifz files into Synfig and they’ll looking completely different. Occassionally I need to look at Flash files I created over 10 years ago, and they still come into Flash looking identical.

So, in effect, this makes them non-destructive until the final render as no information is being thrown away with rounding/clipping.

I never use colour values outside the 0.0 - 1.0 range when I am creating animations.
However, I do use a value of Amount of >1 when I’m making blurs and glows, but whether this then means HDR is used I don’t know.

This is not important to me; the most important aspect for my work is the fact that high colour precision is maintained right up until the output stage so that gradients, blurs and glows don’t suffer from banding. For me, the colour depth used by Synfig is its biggest current advantage over Flash in terms of the quality of the end result you can produce.

Usually 3, with Anti-Aliasing quality 1. I tend to do Standard Definition stuff at the moment for output to PAL Video. If I got asked to do more HD stuff (I’m only just starting to be asked for HD stuff) then that might change, but 3 is fine for what I do. About two thirds of the time I’ll render to PNG sequences, the rest of the time to AVIs with HuffyUV, but that’s when I’m doing simpler stuff.

I preview in two ways:

To see animation I always use 0.5 - I only ever need to see half quality to see movement.

To see what my animation looks like I’ll render a single frame using the Render Current Frame Only option in the Render dialog.

Very rarely, if I need to see how a short sequence of frames looks, I will preview at 1.0, but almost always it’s 0.5.

Many thanks for your reply - it’s very kind of you. And don’t forget, I don’t do any coding so my opinion shouldn’t count for too much with you guys who do all the hard work!

6

I found this one:

code.google.com/p/fog/
-G