I’ve been working on the Cairo render (core) implementation and I’m so excited on the progresses I’m achieving.
For the moment I’ve not written any code line but I have now a much better idea of what’s the internal design of the current Synfig renderer engine and how can the Cairo engine could be applied.
So far I’ve got one idea this morning that keeps me very excited:
When facing Cairo render implementation we have to deal with the limitations of the Cairo API to produce the effects that Synfig can achieve. Changing from Cairo surface to synfig::Surface forth and back every time the layer is not supported by the Cairo libraries worries me a lot, because it might ruins the wanted Cario speed up achievement.
So my idea is this:
synfig::Surface is a instance of a etl::surface which is a template of a generic surface. This instance is for Color type (RGBA float). What if we create a synfig::CairoSurface class that inherits from the generic etl::surface class and overrides the basic etl::surface painting members by the corresponding Cairo ones? This way the layer can act like this:
The layer receives a etl::surface.
if the pointer casts to synfig::Surface then use the Software render method.
if the pointer casts to synfig::CairoSurface then:
Either use the Cairo native methods or the basic etl::surface methods to write pixels (and by inheritance it would use the write pixels Cairo methods
This way, the layers that are not supported natively by Cairo by a high level Cairo API can be rendered using the Cairo pixel format and the current etl::surface methods. Doing this way, we can avoid the forth and back pixel conversion form Cairo surface (ARGB 4*(2 bytes per channel)) to synfig::Surface (RGBA 4*(16 bytes per channel))
This would imply to include the stride concept on our current etl::surface and use it to access the data in memory. The stride will be zero for a synfig::Surface and the Cairo one for a synfig::CairoSurface.
Does it look reasonable?
Thanks for reading!