From: Joshua B. <jos...@gm...> - 2013-07-25 22:22:16
|
Astounding work Carlos, can't wait to try it out. "Carlos López González" <gen...@gm...> wrote: >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 <gen...@gm...> > >> 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 <gen...@gm...> >> >>> 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 <gen...@gm...> >>> >>>> 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 >Syn...@li... >https://lists.sourceforge.net/lists/listinfo/synfig-devl -- Sent from my Android device with K-9 Mail. Please excuse my brevity. |