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<Color, ColorAccumulator, ColorPrep> <----------Surface
etl::surface<CairoColor, CairoColor, CairoColorPrep> <-----------CairoSurface
Surface <------------\
<-------- SuperSurface
CairoSurface <-----/
So the SuperSurface is a Surface and a CairoSurface at the same time.
Later we can rename Surface to SynfigSurface and SuperSurface to
Surface, making the interface clean for the layers.
That SuperSurface should decide which ancestor member function to call
based on the render method (that should be passed at creation time).
If the ancestor member uses Color or CairoColor, as parameter, we can
accept Color always and then pass the Color or a calculated CairoColor
based on the render method.
It looks complex to handle but I think it is worth to look at.
Cheers!
2012/6/10 Carlos López González <genet...@gmail.com>
>
> 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 there
> were needed to convert the pixels from one format to Cairo format in several
> places because the render is made on the Synfig surface.
>
> I tried to fix this doing the following steps:
> 1) Define a CairoColor class with the same interface that Color class has.
> Currently is a separated definition but it can be done using a template as
> eldruin is doing it his own branch.
> 2) Using CairoColor define a CairoSurface class that has similar interface
> than the synfig Surface class and so it can be used to render the document
> using a CairoSurface but the SOFTWARE render method. The idea was to make
> both classes handled by one ancestor one and use the ancestor as the class to
> pass to the render routines. In practice it wouldn't be possible unless the
> ancestor class has both CairoSurface and Surface interface members
> implemented as virtual. In any case, the render methods should extract the
> type of surface to decide which interface to use making it not transparent.
> So at the end, it is needed to modify all the render functions to use one or
> other class and the idea of transparency of the CairoColor integration fails.
>
> So I've came up with a new idea. Surface is currently inherited from
> etl::surface<Color, ColorAcumulator, ColorPrep> (all based on Color class).
> What if I extend the Surface class to inherit from etl::surface<Color, ...>
> and also from etl::surface<CairoColor, ...> ?
> This way, this super surface would use one or other interface depending on
> the render method passed at time of creation.
>
> I think that it would solve the interface problems because the distinction
> between one or other color type is handled internally by this super Surface
> class and the layers only need to tell the surface that the geometry has to
> be painted on it. In fact the layers shouldn't need to know the type of color
> that Surface holds.
>
> I need to review this idea deeply. Please stay tuned.
> Cheers!
> --
> 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
