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 > NEED_WORKAROUND one, and the NO_ALPHA_MAP, NO_CONVOLUTION_FILTER, and > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
