I think the distinction between SynfigColor and CairoColor may be a red herring, because the real major distinction between the two rendering systems is that the surface currently stores pixels as an array of Color objects, but cairo expects a pure array of bytes. Even if the array of Color objects is changed to an array of CairoColor objects, the cairo_image_surface<>Surface conversions will still take linear time. It would be better to do this in constant time, by passing around a data pointer.
The best option would be a CairoSurface which stores the surface/context from cairo, and a CairoPen class that accesses this underlying buffer. If that is the goal, I think I've come up with a way to incrementally write the code that implements this, with minimal impact on the rest of Synfig. The inheritance hierarchy tries to touch as little existing code as possible. If we later decide we want a different one, we can convert to it using copy-paste. The idea is to have CairoSurface inherit from synfig::Surface, and CairoPen that inherit from Synfig's pen/alpha_pen class. A possible implementation order is: 1) Implement "virtual value_type *get_data()" and "virtual set_data(value_type *data)" in etl::surface, as well as get_zero_pos()/set_zero_pos(). All they do is return/set the data/zero_pos pointers. Use them instead of accessing the data directly. 2) Change etl::pen to store a pointer to the surface instead of to the data, and use get_data()/set_data() instead of accessing the data directly. 3) Create a CairoSurface that inherits from synfig::Surface. Have it store data as a union of cairo::surface data and etl::surface data, and convert from one to the other whenever the data type requested isn't the one it has. Implement get_data()/set_data(). 4) When initializing a Surface in the render target, create a CairoSurface instead. 5) Create CairoPen/CairoAlphaPen that use the cairo data from the surface, where possible. 6) Convert the remaining methods in CairoSurface/CairoPen to use Cairo. 7) Remove etl::surface data storage from CairoSurface, and undo changes to etl::surface and etl::pen 8) Figure out if another inheritance structure is better The nice thing is that, after any step, Synfig should still compile and run exactly as before (except for a loss of color precision). Once the cairo<>synfig surface bridge code is there, I think the right pattern of inheritance should become more clear. ~Nikita On Sun, May 27, 2012 at 12:59 AM, Carlos Lopez Gonzalez <carloslopezgonza...@yahoo.es> wrote: > Hi! > yesterday I had the first coding session. My first step was to try to create > a ColorBase template (the type name used is the color channel value) and > inherit from it the current Color class and future CairoColor class. > I realized two things: > 1) Create a template for that kind of classes is useless. At the end, each > class has to be instantiated before it were passed down to the surface > template > 2) Surface is currently a template instance from etl::surface<Color, > ColorAcumulator, ColorPrep> and if we want that synfig::Surface supports two > flavors of surface (Synfig and Cairo) It is not possible to handle two > flavors of surface just using the same synfig::Surface. As I would like to > reuse the etl::surface template both instances of the Cairo and Synfig > surfaces would always be independent classes. > So I think I have some alternatives: > One is to create a synfig::SynfigSurface in replacement of the current > synfig::Surface and re-implement synfig::Surface as a wrapper of both > surfaces using a pointer to each surface (Cairo or Synfig). > Another possibility is to create an ancestor synfig::Surface class form > where the two other classes synfig::SynfigSurface and synfig::CairoSurface > derives from. > Another possibility is to create synfig::CairoSurface inherited from > etl::surface but make it independent. Then each member function that uses > synfig::Surface should be overloaded (and so rewritten) to use > synfig::CairoSurface instead of synfig::Surface. > > The idea is to make the code the easier to maintain but at the same time not > a very complex and long change to do. > The requisite is to allow use a cairo surface with the current methods of > painting so initially all the render works without big changes. > > Any other idea? > Thanks! > ________________________________ > De: Carlos Lopez Gonzalez <carloslopezgonza...@yahoo.es> > Para: "synfig-devl@lists.sourceforge.net" > <synfig-devl@lists.sourceforge.net> > Enviado: Viernes 25 de Mayo de 2012 18:59 > > Asunto: Re: [Synfig-devl] Cairo implementation roadmap > > Hi! > the second part of the documentation for Cairo migration is out. > > https://docs.google.com/document/d/1ASQa2GzgA1p8erciEADK0mKWnvKMorAdg3-KCPyV2uw/edit > > It might need some polishing and review of some concepts but basically the > ideas are there. > All comments and joining to start coding are welcome. > I'll leave a week or so before start committing code. Please take your time > to correct some mistakes on planning I might have and let me know as soon as > possible! > > Cheers! > > ________________________________ > De: Carlos Lopez Gonzalez <carloslopezgonza...@yahoo.es> > Para: "synfig-devl@lists.sourceforge.net" > <synfig-devl@lists.sourceforge.net> > Enviado: Domingo 20 de Mayo de 2012 11:53 > Asunto: Re: [Synfig-devl] Cairo implementation roadmap > > So far the first step is basically finished [1]. Probably some small changes > are needed and/or some areas better explained. > Please take a look and submit comments about its readability and > comprehension. > Some of the second phase of this roadmap might change once the current > render system is understood by anyone. > Now we are in a critical point. Each decision taken by now will affect the > final result. > The next steps are: > a) Read and check the current render system workflow. Polish its > description. > b) Propose integration of Cairo render describing the > modifications/additions needed in the code and the new flow diagram. > > Once those steps are done and agreed the coding phase will start. > Cheers! > [1] https://docs.google.com/document/d/1NTS5ywi_khAj-14cYfc9KLmUMDNnh3fKooZ-m3nBwgU/edit > > ________________________________ > De: Carlos López González <genet...@gmail.com> > Para: synfig-devl@lists.sourceforge.net > Enviado: Viernes 11 de Mayo de 2012 11:11 > Asunto: [Synfig-devl] Cairo implementation roadmap > > Hi! > I would like to keep you informed about the progresses of the Cairo render > implementation. > > So far I've been reading code the last days and finally I started to have a > better idea of how does the current render system works. From my point of > view it is absolutely needed to fully understand the current one before > attempt to code the next one. > > After people has returned from the 2012 LGM, the idea of use GEGL as > replacement for current Synfig's raster operation has taken more value so it > is worth to keep a slot to it here. > > So my roadmap (without due date) for the revamping of the Synfig's render > system is this: > > 1) Write down the current render system flow diagram. It would be enough > detailed to be able to know how the data is transferred from memory to the > final render place and its data type conversions. At the same time it should > be as simple as possible to allow to understand it to a person without deep > code knowledge. > > 2) Taking in mind the following problems/solutions (see below) create a new > flow diagram to implement the new render system: > > a) Use Cairo draw primitives and raster manipulation when possible. > b) Cairo color data is not the same than some sources and target datas. A > data conversion might be needed or alternatively the non supported types > discarded. Use Cairo member functions to render to specific targets when > available (png, screen, pdf, etc.) > c) Current blend methods are not fully supported by Cairo library. Something > has to be done on this. > d) If possible try to use GEGL on raster operations not supported by Cairo > as alternative to current render system. Maybe blend methods can be done > always by a GEGL operation? > > 3) Once defined the new flow diagram for the new render system, divide the > tasks that can be done in parallel between the brave coders (aka myself, > nikitakit and eldruin - and anyone who want to join! - ) and implement it. > > 4) During earlier phases of step 3) there should be defined a benchmarking > system and quality to maintain the goodness of the implementation of the new > render system. > > I'll take charge of the task 1) for the current render system. Nikitakit is > willing to research about blend methods to see how far can we get with Cairo > (and maybe GEGL?). I would like to count with nikitakit and eldruin for the > next steps and with you who are reading for testing purposes. > > Let's see what happen! > Cheers! > -- > 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 > > > > > > ------------------------------------------------------------------------------ > 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 > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
