[Pixman] [PATCH] Faster C variant of over_n_8_8888 fast path

Siarhei Siamashka siarhei.siamashka at gmail.com
Wed Sep 15 03:51:24 PDT 2010

On Tuesday 14 September 2010 19:10:00 Soeren Sandmann wrote:
> On the other hand, there are drawbacks to having the check in each
> fast path too:
> - It adds a bunch of both source and binary code that nobody will ever
>   run except through the test suite. It seems kind of pointless to
>   have an optimization for such an uncommon case.
> - The check will happen for each invocation of the composite
>   operation, whereas with the flag, the computation can be cached in
>   the source image.
> I'm not terribly concerned about wasting flag bits. There are still
> 25% of them left. In 0.22 I think we can get rid of the
> NO_ACCESSORS could be collapsed to one NO_CRACK flag.

So it is decided that we are adding a new flag then?

> Or they can be extended to 64 bits.

IMHO, extending to 64 bits should be only done as the last resort. It's going
to be slower of 32-bit systems. How much and whether it is tolerable, that's
another question.

> > > That would allow similar optimizations for the n_8_565 case and
> > > probably the n_8888_8888_ca() case as well.
> > 
> > Yes, and also 'over_n_8888' could make use of this optimization (if C
> > fast path function even gets implemented for it).
> Existing fast path operations that can take advantage of this:
>         n_8_0565
>         n_8_0888
>         n_8_8888
>         n_1_8888
>         n_1_0565
>         n_8888_8888_ca
>         n_8888_0565_ca
>         x888_8_8888     (because x888 is never superluminescent)
> So if the optimization were fully implemented it would be quite a bit
> of dead code.

What about changing 'general_composite_rect' function from static to global 
and using it as a fallback in such cases where the fast path function decides
that "oops, I actually can't or don't want to do this"? At least this may be
also handy for debugging or developing new code when some complex fast path
function is only partially implemented initially.

Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20100915/50a05ad4/attachment.pgp>

More information about the Pixman mailing list