[cairo] [PATCH cairo] Drop the experimental skia backend

Bryce Harrington bryce at osg.samsung.com
Wed Aug 23 05:32:46 UTC 2017


On Tue, Aug 22, 2017 at 10:15:50AM +0100, Chris Wilson wrote:
> Quoting Bryce Harrington (2017-08-21 22:47:21)
> > As has been stated in the README, skia is not API stable and is not
> > available packaged, versioned forms, resulting in it being a continually
> > moving target.  So the cairo skia backend has to be updated continually
> > as the skia API morphs, which means in practice that Cairo's skia
> > backend will always work only with a specific snapshot and lacking a
> > high degree of maintenance activity will always be badly out of date.
> > The last time the cairo skia backend was updated was in 2014, and had
> > not been updated very regularly prior to that.
> > 
> > While this was an interesting experiment, it is probably better to
> > recommend that people interested in Skia capabilities just use Skia
> > directly.
> 
> ? It's target is you, the cairo developer, to compare against the
> things that skia does better whilst being constrained to the same pdl
> as cairo.  Hence experimental. Carrying it should have very little
> maintenance burden (since it is not marked as being maintained), yet
> reduce the cost of such experiments by allowing/encouraging
> collaboration
>
> Skia is smarter at handling splines, tight generation of rasterisers and
> sources (benefiting from having its pixman integration). In short, it
> does a lot better than Cairo in many circumstances; where Cairo used to
> have an advantage was areas such as decomposing paths in faster
> primitives, pixman had more acceleration paths.

Thanks for commenting on the patch.

I hear your point, and certainly there is much to learn from skia as
that project is further ahead in some areas.

However, with skia providing no stable interface, anyone that does want
to use the skia backend will need to bring it up to date.  So it
actually has a large maintenance burden, just that no one is doing it.

The skia backend seems more appropriate to a feature branch, or even a
separate repository.  It is dead, broken, unused code.

Bryce


More information about the cairo mailing list