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

Hi! This is a summary of the current situation: 1) Layers NOT YET implemented: - CurveGradient - FilledRect - Metaballs - Noise - NooiseDistort - Plant - RadialBlur - SimpleCircle - SpiralGradient - LayerDuplicate - MotionBlur - Julia - Mandelbrot - Layer

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

Fantastic! What a breakthrough in Cairo implementation! :) -David 2012-11-19 23:27, Carlos López González skrev: > ... > Software render time: 0.08 seconds > Cairo unoptimized: 1.60 seconds > Cairo after use custom OVERLAY blend method: 0.23 seconds ... ---

Re: [Synfig-devl] Rv: Cairo implementation roadmap. New fork repo

Hi! >From now on, all my commits would go to: https://github.com/genete/synfig Once I finish it or have something usable I'll pull from synfig's repository and eventually merge with the master branch. Cheers! 2012/10/23 Carlos López González > Hi! > finally I broke the bug that was stopping m

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

Hi! finally I broke the bug that was stopping me to continue the progress. Some layers renders by using the slow approaching of use the render function that creates the rendered surface by (sub)sampling the context color at different vector positions. This is done using the get_color from the conte

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

Hi! Finally, after some days of researching I found why the code I wrote worked in the snippet of code and not in the render system. It needed a reset of the matrix transformations before the mask was applied. After that, the door to adapt the blend methods that are supported in Cairo has been com

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

Thanks guys! I'm having troubles with BRIGHTEN mode. Although Cairo has a LIGHTEN operator (that does a ver similar operation) it doesn't remove the source part that is not onto the destination so I need to do an extra operation. Doing the tests in a separated snippet of code it is fair simple to

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

Agreed. You're a legend, Carlos. "Timothée Giet" wrote: >Great! > >Carlos, you rock :) > >2012/10/3 Carlos López González > >> Hi! >> This morning I came out with another simper solution for the STRAIGHT >> method! >> It is very exciting! >> The code I previously figured out was this: >> >> ///

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

Great! Carlos, you rock :) 2012/10/3 Carlos López González > Hi! > This morning I came out with another simper solution for the STRAIGHT > method! > It is very exciting! > The code I previously figured out was this: > > /// OLD CODE > cairo_save(cr); > > // T

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

Hi! This morning I came out with another simper solution for the STRAIGHT method! It is very exciting! The code I previously figured out was this: /// OLD CODE cairo_save(cr); // This part would retrieve the current passed surface and copy it on destimage cairo

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

Thanks Konstantin. Your backing helps a lot. I've finally figured out how to emulate the STRAIGHT blend method operation in Cairo. It is an important milestone because I'm confident on being able to emulate the Synfig's blend methods that aren't directly supported by Cairo just using a combination

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

2012/9/29 Carlos López González : > Hi! > I've added Cairo support for Shade and Bevel layers. > Again the results are very similar but slightly slower. These kind of layers > that manipulate pixels directly doesn't seem to improve much using Cairo > colors. In fact they loose time doing some unwan

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

Hi! I've added Cairo support for Shade and Bevel layers. Again the results are very similar but slightly slower. These kind of layers that manipulate pixels directly doesn't seem to improve much using Cairo colors. In fact they loose time doing some unwanted operations (due premultiplied and due to

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

Hi! so finally I decided to do not try to blend the colors in the CairoColor space. Since a the end, any correction that I can write to make the blend functions work with CairoColors correctly, pass through to convert the unsigned int values to float, then do the blend and then come it back to unsi

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

Hi! all the blending functions that I proudly ported to a template to be used on Color as well as CairoColor are wrong! ^___^'' The won't work for CairoColors! First, the alpha value used for scale up the rest of channels has to be a float betwen 1.0 and 0.0 and so it needs to be scaled down by the

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

Hi! I've been working to be able to render gaussian blurs using Cairo surfaces. I needed to do some changes as you can see in the commits list. It seems to work but for some reason the alpha is washed out. It is like if the alpha value were not accumulated properly... Still don't know the reason. :

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

Hi! After the Warp layer bug hiatus I'm back on the Cairo render road. ^__^ I've been working on implement the Blur layer. Very interesting! This is the summary of changes: 1) I've needed to add a new member function to the etl::surface: void etl::surface::copy(const etl::surface &rhs); to allow

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

Hi, Carlos! 2012/9/1 Carlos López González : > Hi Konstantin, I think that unless you use the text to place it in a exact > position as part of the scene, you won't notice so much the differences > between Software and Cairo Pango as I have mostly emulated the basic > parameters. Well I do place

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

Hi Konstantin, I think that unless you use the text to place it in a exact position as part of the scene, you won't notice so much the differences between Software and Cairo Pango as I have mostly emulated the basic parameters. Also, Pango does a hinting to place the letters in the right pixel to a

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

Hi! Sorry for the late answer. I'm using Text Tool in almost every synfig project - for captions or credits. I also use various parameters like linespacing, character spacing, custom fonts. But I 100% agree with your decision to sacrifice compatibility in favour to the simplicity. Especially consid

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

Hi there! thank you all for the quick feedback on this matter!!. Considering that I agree with all your comments I'll do this: "Implement Text layer using Pango-Cairo libraries with the minimum effort to maximize the emulation of the basic parameters." Also, it is worth to mention that once the G

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

Hi Carlos! On 31 August 2012 10:06, David Rylander wrote: > > Synfig text is not a super great tool. That's a very polite way of putting it ;) I've never been able to use the text tool in Synfig due to the dancing letters issue - I wanted to use it on my Nationwide titles but found I couldn't

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

Hi, no problem for me if the text-tool is not backward compatible, I think I've never used the text tool in synfig yet ;) Keep up the good work! :) Tim 2012/8/31 David Rylander > 2012-08-31 09:34, Carlos López González skrev: > > > > So, I want you guys to tell me if it is worth to do the eff

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

2012-08-31 09:34, Carlos López González skrev: > > So, I want you guys to tell me if it is worth to do the effort of > splice the text into glyphs and lines to allow the emulation of the > spacing in Synfig? I think not. Synfig text is not a super great tool. If we can replace that but with som

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

Hi folks! I need your feedback on some questions: As you probably know, Synfig's Text layer has some particular features. It has the following parameters: 1) Orientation (vector) 2) Horizontal Spacing (real) 3) Vertical Spacing (real) 4) Origin (vector) When Orientation is (0,0) the origin of the

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

Hi David! I'm sorry I didn't approve your post from the mailing list. I promise to check the synfig-devl pending approval list more frequent. Cheers! 2012/8/7 David Jeffery > Hi Carlos! > > The progress on the circle is wonderful news - I'm always interested to > know how the progress on the Ca

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

Hi Carlos! The progress on the circle is wonderful news - I'm always interested to know how the progress on the Cairo renderer is coming along. Just as I was getting into understanding on the Synfig Code I was invited to resubmit a revised pitch for a project (was using initially planning on usin

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

Hi! I've been playing with Pango library meanwhile was implementing the Cairo render to the Layer_Freetype class. I've found the following: 1) Currently I've not found any API in Pango that scales directly the font size vertically. If you're aware of it, please let me know. I know that it is pos

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

Brilliant! You guys are doing an excellent job. Keep it up ^_^ On 26/08/2012 12:24 AM, Yu Chen wrote: Good news. So we will have new Text Layer with power of pango :) ~ yu 2012/8/25 Carlos López González > Hi! after some fighting with autotools due to a s

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

Good news. So we will have new Text Layer with power of pango :) ~ yu 2012/8/25 Carlos López González > Hi! > after some fighting with autotools due to a stupid confusion with FLAGS > instead of CFLAGS I've been able to compile synfig-core with pango and > pangocairo support! > Thanks to Dave

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

Hi! after some fighting with autotools due to a stupid confusion with FLAGS instead of CFLAGS I've been able to compile synfig-core with pango and pangocairo support! Thanks to DaveJ and to Nikitakit (who patiently listened me yesterday)! I hope soon we have texts in Synfig with Cairo (Pango) Cheer

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

Hi! It is more than helpful! I'll give it a try as soon as possible Thanks! 2012/8/24 Dave Jeffery > I know nothing about autotools (as I told you yesterday!) but from what > I've seen in other programs is it something like: > > # Checks for libraries. > PKG_CHECK_MODULES([PANGOCAIRO], [pangocai

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

I know nothing about autotools (as I told you yesterday!) but from what I've seen in other programs is it something like: # Checks for libraries. PKG_CHECK_MODULES([PANGOCAIRO], [pangocairo]) AC_SUBST(PANGOCAIRO_CFLAGS) AC_SUBST(PANGOCAIRO_LIBS) PKG_CHECK_MODULES([PANGO], [pango]) AC_SUBST(PANGO_

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

Hi again! I need you r help guys! Trying to include pango on synfig-core I get trapped in autotools tricks. I guess that pango support for synfigstudio comes from the gtk and gtkmm support. But how do I include pango in the configure.ac section? Thanks! 2012/8/23 Carlos López González > Hi! > I'

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

Hi! I've implemented Cairo render for Translate, Scale, Rotate and Stretch layers. The most interesting one is the Rotate layer that has one average performance of 1,4 times faster than Software. Cheers! 2012/8/19 Carlos López González > Hi! > More news! > I've finished the implementation of the

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

Hi! As well as I can't code as frequent as last past days I would annotate here the discoveries I'm doing for the rest of things pending to implement. Maybe you already know that many of the Synfig's layers provide a system to render based on a math formula. They use a common function called: Col

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

Hi Joshua, welcome to the list. Cheers! 2012/8/16 Joshua > You sir, are a machine. Congratulations on those results. Be sure to > have some more vacations soon :D (also, this is my first post to the > mailing list. Hi all.) > > > -

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

You sir, are a machine. Congratulations on those results. Be sure to have some more vacations soon :D (also, this is my first post to the mailing list. Hi all.) On 16/08/12 02:17, Carlos López González wrote: Don't go yet! there's more! Radial gradients achieved with similar results than linea

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

2012/8/15 Carlos López González : > Don't go yet! there's more! > Radial gradients achieved with similar results than linear ones. > Cheers! Awesome!!! ^__^ yay! K. > 2012/8/15 Carlos López González >> >> So I'm here again to make some clarifications: >> The speed up of 6 times is due to that I

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

2012/8/15 > Congratulation! > > Will this implementation help speed up the UI response? > I hope so! and it is possible that using gl backend it would achieve more speed. > > > Hope Carlos has his another long vacation soon :) > > Cheers > Yu > > -- Sent from my HP Veer > > ---

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

Congratulation!Will this implementation help speed up the UI response?Hope Carlos has his another long vacation soon :)Cheers Yu-- Sent from my HP VeerOn Aug 15, 2012 7:02 PM, Carlos López González wrote: Hi!So this is my last vacations day :(I've started the port of linear gradients to Cairo with

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

Oh, well, it was *me* who misunderstood the meaning ^__^''' I believed that he wanted vacations to me from coding! LOL Cheers! 2012/8/14 Timothée Giet > 2012/8/14 Zelgadis > >> 2012/8/14 Zelgadis : >> > P.S. People, wouldn't it be great if Carlos had opportunity to be on >> > vacations fore

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

2012/8/14 Zelgadis > 2012/8/14 Zelgadis : > > P.S. People, wouldn't it be great if Carlos had opportunity to be on > > vacations forever? ^___^ > > P.P.S. Don't get me wrong - I mean that Carlos is very productive when > he is on vacations. ^__^ > > I think everebody understood it this way ;) Big

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

2012/8/14 Zelgadis : > P.S. People, wouldn't it be great if Carlos had opportunity to be on > vacations forever? ^___^ P.P.S. Don't get me wrong - I mean that Carlos is very productive when he is on vacations. ^__^ -- http://morevnaproject.org/ --

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

Hi! So Region layer is finished. Curiously Cairo is only 3% faster without feather and slower (as expected) with feather. It is interesting to know that Synfig's Software directly push a polygon evaluating the region in several points on a hermite curve. Previously it used the Shape Layer facilitie

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

2012/8/14 Carlos López González : > > > 2012/8/14 Zelgadis >> >> Hi! >> Awesome results! >> >> 2012/8/14 Carlos López González : >> > Hi! >> > Thank you all for the kind comments! ^__^ >> > >> > So I've mostly finished the Layer_Polygon. These are the statistics: >> > >> > Without feather Cairo wi

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

2012/8/14 Zelgadis > Hi! > Awesome results! > > 2012/8/14 Carlos López González : > > Hi! > > Thank you all for the kind comments! ^__^ > > > > So I've mostly finished the Layer_Polygon. These are the statistics: > > > > Without feather Cairo wins being 40% faster (whoohooo!) > > With feather Cai

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

Hi! Awesome results! 2012/8/14 Carlos López González : > Hi! > Thank you all for the kind comments! ^__^ > > So I've mostly finished the Layer_Polygon. These are the statistics: > > Without feather Cairo wins being 40% faster (whoohooo!) > With feather Cairo is mostly average with Synfig's Softwar

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

Hi! Thank you all for the kind comments! ^__^ So I've mostly finished the Layer_Polygon. These are the statistics: Without feather Cairo wins being 40% faster (whoohooo!) With feather Cairo is mostly average with Synfig's Software Also, feathered results aren't in some cases as smooth as in Synf

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

Hi Carlos! On 12 August 2012 12:29, Carlos López González wrote: > Checkerboard Layer finished. It is 20% faster in Cairo than in software. > Congratulations on completing another layer - you are making fantastic progress. The speed increases you are getting sound wonderful. The Checkeboard La

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

Checkerboard Layer finished. It is 20% faster in Cairo than in software. Also it fixes one render artifact that was not noticed before. See attached images and how the rendered by Cairo places correctly the checkerboard in the right place. Synfig's software shifts the checker to the right down a l

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

Congratulations Carlos! You are doing a GREAT job! :) 2012/8/10 Carlos López González > Simple non feathered circles is complete. Cairo is 29% faster with circles. > Cheers! > > > 2012/8/7 Carlos López González > >> Ok, so now working on Circle layer. >> Initially the code will be similar to th

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

Simple non feathered circles is complete. Cairo is 29% faster with circles. Cheers! 2012/8/7 Carlos López González > Ok, so now working on Circle layer. > Initially the code will be similar to the rectangle but I was scratching > my head on how to emulate the feather. Then I discovered that a ci

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

Ok, so now working on Circle layer. Initially the code will be similar to the rectangle but I was scratching my head on how to emulate the feather. Then I discovered that a circle with zero radius will render a feather if requested, what surprised to me initially because I guessed that the feather

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

Rectangle layer done. Initial results for png export looks like cairo_png target is about 15% faster. Also a render artifact from Software Rectangle render is fixed in cairo. ~__^ 2012/7/20 Zelgadis : > 2012/7/20 Carlos López González : >> Hi! >> Here is the summary of the changes that are happen

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

2012/7/20 Carlos López González : > 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

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

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 Ca

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

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

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

2012/7/9 Nikita Kitaev : > On Sun, Jul 8, 2012 at 10:49 PM, Carlos López González > wrote: >> Hi! >> >> 2012/7/9 Nikita Kitaev : >>> 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 `s

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

On Sun, Jul 8, 2012 at 10:49 PM, Carlos López González wrote: > Hi! > > 2012/7/9 Nikita Kitaev : >> 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` >> >> T

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

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? 2012/7/9 Nikita Kitaev : > Please pull my latest changes from nikitakit_new_cairo_core_2. The >

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

Hi! 2012/7/9 Nikita Kitaev : > 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

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

Hi! 2012/7/9 Nikita Kitaev : > Please pull my latest changes from nikitakit_new_cairo_core_2. The > first two commits are essential for the code to compile on my machine > (Ubuntu 12.04). OK, I'll apply them. >The third changes the cairo API calls used in > Context::accelerated_cairorender. (Cal

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

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. There's also two bugfixes in there

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

Please pull my latest changes from nikitakit_new_cairo_core_2. The first two commits are essential for the code to compile on my machine (Ubuntu 12.04). The third changes the cairo API calls used in Context::accelerated_cairorender. (Calling cairo_paint() is simpler than drawing a rectangle the siz

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

Hi! After reading several times your email and make some code reviews I just can agree that you have reason in most of the issues. What was really making me think that way is the influence of the current render system. One of the things that moved me to use start_frame, end_frame and encapsulate e

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

Hi! On Mon, Jul 2, 2012 at 4:47 AM, Carlos López González wrote: > Hi! > > 2012/7/2 Nikita Kitaev : >> Nice, the code's coming together! I played around with it today and >> fixed a couple of compile errors. >> > > Oh, I don't have compile errors on the latest committed version, can I > have some

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

One more log note: Layers have a get_color function that returns a Color for a given point. Currently I'm using it when coding the synfig::render version for CairoSurface and it needs that the Color obtained is converted to CairoColor for each pixel. It is very cost consuming and will be fixed in t

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

Hi! 2012/7/2 Nikita Kitaev : > Nice, the code's coming together! I played around with it today and > fixed a couple of compile errors. > Oh, I don't have compile errors on the latest committed version, can I have some details of what was missing/wrong? > The structure feels good, I just have a f

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

Nice, the code's coming together! I played around with it today and fixed a couple of compile errors. The structure feels good, I just have a few suggestions: 1) start_frame() and end_frame() feel redundant. The purpose they serve in the scanline target is to signal the start and end of data tran

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

More news on the latest commits: The CairoSurface now holds a cairo_surface_t pointer. It is not possible to create the setl::surface part of the CairoSurface by the constructor. The CairoSurface only receives a cairo_surface_t on construction or later through a set_cairo_surface mmember call. To

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

Hi there! Some bits of the latest coding/researching I'm doing: I've started to port Context::accelerated_render to a template framework. Context::accelerated_render has been overloaded to admit Surface and CairoSurface. Then each version should call the template Context::accelerated_render_ (noti

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

Hi! I'm sorry for force the situation to use a generic class that supports both color types. IT IS NOT POSSIBLE TO HANDLE IT IN THE CURRENT SITUATION. Currently, layers rendering methods assume that always Surface is returning Color (in opposite to CairoColor) when asking to Surface. This would mak

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

Ok, finally I figured out the best way to handle the multiple Surface support in Synfig. The idea is that really there is not need to have a CairoSurface. Instead of that it is better to derive the current synfig::Surface from the etl template for Color and also from the etl template from CairoColo

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

Better than extend Surface to derive from the two etl implementations (for Color and for CairoColor) make a new class derived from Surface and CairoSurface. The inheritance diagram could be like this: etl::surface <--Surface etl::surface <---CairoSurface Surface <\

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

Hi! You might have noticed that there are some new commits on the genete_new_cairo_core branch. In the last few days my mind has been boiling facing some problems on the strategy I planned for the Cairo render implementation. One of the things that bugs me more of the original strategy, is that th

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

Reading back your suggestion of use a derived class for CairoSurface I think that it is not a good idea. synfig::Surface has one alpha_pen defined (and used everywhere) that is a class that is constructed based on Color class and ColorPrep. ColorPrep is hard coded to use a Color class so at some po

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

On Mon, May 28, 2012 at 8:13 AM, Carlos López González wrote: > Hi! > I've changed my email address for the synfig-devl mailing list. This is the > new one. > >> Just to make sure we're on the same page, I'll add that it's important >> that every single method in etl::surface use get_data()/set_da

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

Just a few notes of things that I'm seeing when reading the code: 1) generic_pen_row_iterator stores data_ and pitch_as the two only member variables. Both are public. 2) generic_pen defines as public the begin_x(), end_x(), begin_y and end_y() members that returns iterators (pointers) to the data

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

Hi! I've changed my email address for the synfig-devl mailing list. This is the new one. Just to make sure we're on the same page, I'll add that it's important > that every single method in etl::surface use get_data()/set_data() > instead of accessing the data pointer directly. > > Sure. It will b