Re: [Synfig-devl] Rv: Cairo implementation roadmap

[Zelgadis <kse...@gm...>]

2012/7/20 Carlos López González <gen...@gm...>:
> Hi!
> Here is the summary of the changes that are happening to the Cairo development:
>
> 1) CairoColor: The initial approaching of use four unsigned char
> members for the ARGB channels was wrong. It assumes one endian
> alignment on the data stored. In fact the data stored at the cairo
> surface from the Cairo library is using the native endian storage of 4
> bytes and it maybe little endian or big endian depending on the
> architecture. So I modified the CairoColor internal members to store
> the ARGB values in a uint32_t type and use the bitwise operations to
> set or get the channels. Apart of that two bugs has been fixed on
> premult and demult alpha functions.
>
> 2) Nikitakit wrote a cairo_png target class that allows to export the
> content of cairo_surface_t to a png file. I did some modifications to
> apply the gamma value (hardcoded to 2.2 in Synfig) and it works quite
> well. It is merged on the cairo development branch.
>
> 3) I've written the accelerated_cairorender functions for:
> PasteCanvas
> Layer_Bitmap
> Layer_Composite
>
> It is worth to mention that Layer_Composite accelerated_cairorender is
> used on each layer that doesn't have a accelerated_render defined on
> the layer itself, and only provides a get_color function. The
> accelerated_render (and so the cairorender version) uses a
> Layer_Bitmap to render the context of the layer in a image surface and
> then uses the get_color function to obtain a deformed version of the
> context. So that's the reason I needed to create the Layer_Bitmap
> accelerated_cairorender before the corresponding Layer_Composite one.
>
> The get_cairocolor reads directly the pixel colors in the memory to
> get the color on a certain Point position. Since the surface is a
> cairo_surface_t I need to map the surface to a cairo_surface_t type
> image and from it, get its data pointer, width and height and the
> stride to read the pixel colors directly. But for the case of the
> Layer_Bitmap, the get_color function has to map the cairo_surface_t to
> a CairoSurface class and unmap it back before return the CairoColor to
> the requester of get_cairocolor.
> The map and unmap procedures are time and resource consuming to I have
> to figure out a way to keep the Layer_Bitmap surface data mapped once
> and not everytime the get_color function is called.
>
> In any case the structure is ready to start to port the layers to use
> the cairo library on its render function. I'll start by doing this one
> by one but if anyone is wiling to help working on parallel with me, it
> is more than welcome!


Yay!
It's awesome progress! I'm so excited! ^__^
K.
>
> 2012/7/9 Carlos López González <gen...@gm...>:
>> As probably you have noticed, I've asked to cairo mailing list some
>> explanation about why the write to png is apparently not working.
>> I've re-checked (debug) a sample file to direct manipulation the image
>> surface and apparently the data is correct but the rendered result is
>> wrong.
>> Let's see what's happening with the write to png combined with direct
>> manipulation process.
>> Cheers
>>
>> 2012/7/9 Carlos López González <gen...@gm...>:
>>> 2012/7/9 Nikita Kitaev <nik...@gm...>:
>>>> On Sun, Jul 8, 2012 at 10:49 PM, Carlos López González
>>>> <gen...@gm...> wrote:
>>>>> Hi!
>>>>>
>>>>> 2012/7/9 Nikita Kitaev <nik...@gm...>:
>>>>>> I updated my cairo png target so that it now works with the updates to
>>>>>> the target system (see my branch at nikitakit_new_cairo_core_2).
>>>>>>
>>>>>> To render, run `synfig -t cairo_png file.sif`
>>>>>>
>>>>>> The colors are either shifted or inverted, I haven't figured out the cause yet.
>>>>>
>>>>> O_O But how do we pretend to have some result? There is not any layer
>>>>> already ported to Cairo! What's the content of the sif file you have
>>>>> tested?
>>>>
>>>> Try it yourself! Here's one layer from the sif file I was using to
>>>> test. It actually calls the cairo_png target, renders the file, and
>>>> the render is different from the stock png target. I suspect the
>>>> default get_color() based render is already working.
>>>
>>> That is!!!! When accelerated_cairorender is not defined then it uses
>>> the one from the Layer class. It uses the the get_color via
>>> Layer::accelerated_render!!!
>>>
>>> It is a great surprise because it would allow me to debug the current
>>> initial steps!
>>>
>>>
>>>>
>>>> That's your part of the code, so tell if you think I'm accidentally
>>>> calling the software renderer instead.
>>>>
>>>>> I have a question regarding to one of your changes. Isn't possible to
>>>>> modify the configure file to force to use cairo version 1.12 instead
>>>>> of check it on run time and simply break out the program flow?
>>>>
>>>> Please don't do that quite yet. Ubuntu 12.04 ships with cairo 1.10. At
>>>> the moment I don't want to wrestle with installing a newer cairo.
>>>> (Especially since I saw bug reports where a cairo 1.12 PPA caused core
>>>> gnome packages to crash.)
>>>>
>>>> For an actual release a configuration option might be better. But this
>>>> means the new version of synfig won't run on any Ubuntu versions prior
>>>> to 12.10. We need a better compatibility scenario than requiring users
>>>> to upgrade their OS.
>>>>
>>>> ~Nikita
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Synfig-devl mailing list
>>>> Syn...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/synfig-devl
>>>>
>>>
>>>
>>>
>>> --
>>> Carlos
>>> http://synfig.org
>>
>>
>>
>> --
>> Carlos
>> http://synfig.org
>
>
>
> --
> Carlos
> http://synfig.org
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Synfig-devl mailing list
> Syn...@li...
> https://lists.sourceforge.net/lists/listinfo/synfig-devl



-- 
http://morevnaproject.org/