[cairo] bitmasks branch

[Soeren Sandmann]

Benjamin Otte <otte at redhat.com> writes:

> just out of interest: Why do you use negative flags like
> FAST_PATH_NO_PAD_REPEAT instead of positive ones like
> FAST_PATH_PAD_REPEAT?

This is because the flags fields in the fast path tables is really a
list of properties that must be satisfied for the fast path to run. So
when FAST_PATH_NO_PAD_REPEAT is set, it means that the image must not
have a repeat mode of 'pad'. However, when that bit absent, it means
the fast path doesn't _care_ about that particular property. It
doesn't mean that the image _must_ have 'pad'.

If some hypothetical fast path would only work with images that had
'pad' as repeat mode, a new flag FAST_PATH_PAD_REPEAT would be
required; it couldn't rely on the FAST_PATH_NO_PAD_REPEAT not being
set. This is the reason there are both FAST_PATH_COMPONENT_ALPHA and
FAST_PATH_UNIFIED_ALPHA flags even though those properties are
mutually exclusive.

Conceptually, the code in get_image_info() is computing what
properties the given operator and images can satisfy, and then it is
tested whether those properties are a superset of the ones required:

        (info->src_flags & src_flags) == info->src_flags  

> It feels more natural to me to do the second.

I agree in general, but in this case I don't see a way to get around
it.


Thanks,
Soren