2012/7/20 Carlos López González <genet...@gmail.com>: > 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 <genet...@gmail.com>: >> 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 <genet...@gmail.com>: >>> 2012/7/9 Nikita Kitaev <nikita...@gmail.com>: >>>> On Sun, Jul 8, 2012 at 10:49 PM, Carlos López González >>>> <genet...@gmail.com> wrote: >>>>> Hi! >>>>> >>>>> 2012/7/9 Nikita Kitaev <nikita...@gmail.com>: >>>>>> 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 >>>> Synfig-devl@lists.sourceforge.net >>>> 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 > Synfig-devl@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/synfig-devl -- http://morevnaproject.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 Synfig-devl@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synfig-devl
