[cairo] Cairo and GdiPlus or two win32 backends

[Carl Worth]

On Sun, 06 Feb 2005 14:05:22 +0100, Hans Breuer wrote:
> On 06.02.2005 06:45, Owen Taylor wrote:
> > There's already a vector-based backend in CVS, the PDF backend. 
> Which produces similar wrong results for the logical operators
> at the moment (or better does not handle them at all).

There aren't any logical operators at all. All of the Porter/Duff
compositing operators are defined in the same terms and together form
an algebraically-complete set.

> > While in a few cases operations done with temporary surfaces could
> > be represented as logical operations on path, doing optimizations
> > in that area is hard because logical operations on vector paths are hard
> > to implement efficiently and robustly.

Owen's hit the nail on the head there. Until we can accurately compute
"path intersects path" we certainly won't be putting anything into the
backend that requires it.

> >  - Small patches are easier to get in than big patches
> >  
> Sure, but that's what I started with. The longer patches are rejected
> usually the more they need to grow ;-)

Patch size alone isn't the primary criteria here. But logical
indivisibility of patches really does help a lot. If you submit a
patch that say, "here's a rework of subsystem X, and some obvious bug
fixes for systems Y and Z", I would definitely like the see the bug
fixes as separate patches so we can get them committed while we're
still looking at the bigger rework.

And the same goes whether someone is submitting patches or committing
directly to CVS.

> > In terms of your big patch ... I don't see any point in having two
> > win32 backends for Cairo. I think we have to just figure out a plan
> > for how to evolve the single win32 backend to do what everybody needs
> > and merge the relevant parts of your code into that.

This sounds like the best plan to me. I haven't heard a compelling
argument for having two different win32 backends in cairo, (nor do I
hear anybody making that argument).

> My plan is something like: let the different backends grow independently
> (with different top priorities) and at some point in time if all tasks
> can be fulfilled by one of them simply drop the other.

I don't know what the advantage would be of deliberately setting up
competition between two different backend implementations.

> Constantly having to merge these experimental highly fluid backends
> would give m ore confusion and bugs than benefits. Even more if one
> is to be kept beside public version control.

If we'll all work together on one backend in CVS, there wouldn't be any
constant merge between divergent code bases.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050207/1cd22a8c/attachment.pgp