Hi!!
I've finished port all the layers and fix all the blend methods. Finally,
fixing the blend methods wasn't the easier part but well, it is finally
done.
Unfortunately the old Cairo render method can't live with the new Cairo
render method together to compare them, because the blend methods are
shared and incompatible.
So, I'm going to start to remove the old method everywhere before submit
the new method to your testing. It will be done in a single commit to make
easier to step back in case we need it.
Again, I would like to ship 0.64.1 as soon as possible I finish the
solution of this bug. Please update your development branches.
Keep calm and code Synfig!
2013/7/7 Carlos López González <[email protected]>
> Hi!
> Almost finished!
>
> - Remaning layers: Plant, Time Loop, Stroboscope
> - Pending to fix some blend methods that uses cairo_surface_t* instead
> of cairo_t* (Multiply, etc.) but it will be easy.
> - Pending to allow to use the old Cairo and the new Cairo render
> method by user preference. This will be only temporarily.
> - Pending to complete the documentation for this Cairo change.
>
> After finish it, I would like to release testing binaries for Linux and
> Mac, in order to validate the render system.
> Notice that the idea is to remove the old buggy Cairo render method once
> the new one is validated.
>
> This might happen at the end of July so please, update your development
> branches because I would release this change to the 0.64.01 version.
>
> Let's move!!
> Cheers!
>
>
> 2013/6/25 Carlos López González <[email protected]>
>
>> OK, so finally I decided to do not touch the current Synfig render and
>> fix the bug in the Cairo area only.
>>
>> I'm in the progress of:
>> 1) Rework each layer to support the new Cairo render method by passing a
>> cairo_t pointer instead of a cairo_surface_t pointer. [1]
>> 2) I'm writing a (long) developer document to explain how to proceed with
>> each type of layer to use the cairo_t pointer instead of the
>> cairo_surface_t pointer. [2]
>> 3) Keeping track of the modifications on a spreadsheet to give
>> consistence to the whole process. [3]
>>
>> Everything is in progress so please, be nice when reading the links.
>> Comments are not only welcome, they are needed!!!
>> Cheers!
>>
>> [1] https://github.com/genete/synfig/commits/bug%23450
>> [2]
>> https://docs.google.com/document/d/1Hpwqz5BnqiIRbFiS7lCHVx9tVsu9zm4vX4TqJO1yGvo/edit?usp=sharing
>> [3]
>> https://docs.google.com/spreadsheet/ccc?key=0Ah8g_H3f7qpZdEZ1cUwtWmRTM1Z5NHgzTHVnOVJXMkE&usp=sharing
>>
>>
>> 2013/6/4 Carlos López González <[email protected]>
>>
>>> Hi!
>>> I've been during last days struggling my mind trying to understand
>>> what's the reason that makes the combination of stretch layer with rotate
>>> layer fail in Cairo mode.
>>>
>>> After give a try to an idea of a workaround I've understood that the
>>> problem is bigger. The render Cairo system that I've applied to Synfig is
>>> completely wrong. Please let me explain.
>>>
>>> In Synfig, as you already know, there are two kind of layers:
>>> Primitives: doesn't care on the context content to produce its result.
>>> Non Primitives (filters): needs to read the context content to produce
>>> the result.
>>>
>>> In Synfig, the scale and translate layers are not really filters. They
>>> are transformations. They only modify the render description of the context
>>> applying the inverse of the transformation. I.e. if we need to translate
>>> the context an amount of V (vector) we just modify the viewport (that is
>>> the render description) adding an amount of -V, so the result is that we
>>> are obtaining a translation to the context.
>>> Similar happens to the zoom layer (say amount Z>1). It applies the
>>> inverse of the zoom (1/Z<1) to the render description making it smaller and
>>> so, we zoom in the context when we display the context in the surface that
>>> has not modified its dimensions.
>>>
>>> Also, similar happens to the Stretch layer. The Render description is
>>> inverse stretched and then the context is rendered in a inverse stretched
>>> viewport and so, when displayed on the unmodified surface it effectively
>>> looks stretched.
>>>
>>> So those three layers doesn't read the context to produce the effect.
>>> They modify the render description to make the context render in a inverse
>>> distorted viewport and so, the result is distorted.
>>>
>>> But that doesn't happen with the rotate layer. The render description,
>>> doesn't hold a rotation parameter for the viewport. So, then, the rotate
>>> layer needs to read the pixels of the context to produce the result.
>>>
>>> A note: zoom layer is exactly the same than stretch layer but it has the
>>> amount of zoom is interpreted as scale=exp(zoom) so the scale result is
>>> always positive and greater than zero.
>>>
>>> On contrary, in Cairo, the scale, translation and rotation are handled
>>> as transformation operations to the stuff to draw.
>>>
>>> In Cairo if you want to rotate something around a point OS and after
>>> that you want to rotate it around a point OR, you need to do this:
>>>
>>> push translate OS
>>> push scale
>>> push translate -OS
>>> push translate OR
>>> push rotate
>>> push translate -OR
>>> push geometry A
>>> draw
>>> push geometry B
>>> draw
>>>
>>> And so the effect is that the geometry A is drawn, then the geometry B
>>> and then the operations are applied in the reverse order (first translate
>>> -OR, then rotate, then translate OR, then translate -OS, then scale and
>>> then translate OS), giving the desired result.
>>>
>>> if we use the current synfig render model for stretch and rotate
>>> applying the Cairo model we have problems with the rotate layer.
>>>
>>> I designed the render system with Cairo in the same way than the synfig
>>> model: passing a surface. This implies that the surface is passed between
>>> render calls. Since the surface (I think) doesn't hold the transformations
>>> that are stored in Cairo Context we cannot stack the operations properly
>>> like I explained before, since the Cairo context for the Cairo surface is
>>> destroyed each time. So when a render call is passed from one surface to
>>> other, the cairo transformation stack is lost. (ouch! :-( )
>>>
>>> So form this point I think there are two options:
>>> 1) Add the rotation parameter to the render description and modify the
>>> way that synfig and cairo renders its stuff (taking account the passed
>>> rotation)
>>> or
>>> 2) Leave Synfig as it is, and modify Cairo render to pass the cairo
>>> context between calls to properly render the stuff.
>>>
>>> The first one would benefit both render systems and that implies more
>>> risk (I can break the synfig render). The second one would benefit only to
>>> Cairo and would probably make the render faster, since there is not need to
>>> convert the drawing commands into pixels and use them as source for the
>>> next operation.
>>>
>>> In any case any solution is long :-(
>>>
>>> I'm ashamed by this big blunder, but well. That's life =)
>>>
>>> Opinions?
>>> --
>>> Carlos
>>> http://synfig.org
>>>
>>
>>
>>
>> --
>> Carlos
>> http://synfig.org
>>
>
>
>
> --
> Carlos
> http://synfig.org
>
--
Carlos
http://synfig.org
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Synfig-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synfig-devl
