[Spice-devel] [PATCH 00/30] Convert cairo canvas to use pixman

[Izik Eidus]

On Thu, 18 Feb 2010 21:58:26 +0100
Alexander Larsson <alexl at redhat.com> wrote:

> This series converts the software based canvas "cairo_canvas" to use
> pixman for rendering instead of cairo. It uses the upstream pixman
> (the latest version, 0.7.16 is needed) thus dropping the dependencies
> on qcairo and qpixman (and additionally cairo is not linked into the
> server at all).
> 
> After the whole series is applied its possible to build spice with
> upstream cairo and pixman 0.7.16. However, if you want to compile and
> run intermediate steps (for instance when bisecting) you need to do
> some extra work:
> 
> Apply this patch to pixman 0.7.16:
> http://people.gnome.org/~alexl/pixman-rops.patch
> 
> Apply this patch to qcairo to use the patchef pixman from above
> instead of qpixman:
> http://people.gnome.org/~alexl/qcairo-noqpixman.patch
> 
> There are a few features missing from this implementation:
> 
> * Wide paths are not supported (including joins and caps)
> This is not a problem because no driver generates them atm
> 
> * Clip paths (i.e. not rect-lists) are not supported
> The win32 driver can theoretically produce these, but i've never
> seen it do so. We should remove that from the win32 driver.
> 
> * Bezier paths are not yet working
> This just needs some work to subdivide them, but i'm not sure we
> actually want to send beziers. It would probably be better to
> subdivide them in the driver so that we get the same subdivision
> as GDI does, if some paths use software fallback and some not.
> 
> In addition to the pixman facilities (compositing, regions, blending,
> scaling, etc) this code adds a bunch of helpers for doing raster
> operations (ROPs), tiling, etc.
> 
> Also, the line drawing is done using the X11 (mi) line rasterizer
> which has been imported and converted for our use.

Hi, I have just finished to walk over the code.
some comments to patch`s that I had i send in reply for each patch,

Genearly this series look great,

I had patch I wanted to finish this weekend -
But instead I will help test this series the weekend to see that we didnt break
anything both from correctness and from performence point of view:
For example the copy_bits and the scaling performenace, nothing that should be
a problem, just to be sure.

So I will take this weekened to agreesivly test it and compare it to the old code
and read the code more carefuly again in the problomatic areas, and we can commit
it after the weekend, how is this sound?

Thanks.