On Mon, 17 Dec 2012 14:13:02 -0500 Søren Sandmann <sandm...@cs.au.dk> wrote:
> From: Søren Sandmann Pedersen <s...@redhat.com> > > The noop iterator is supposedly handling solid images, but currently > it never triggers because a solid image cannot have both an extended > format code of PIXMAN_solid while at the same time having the > FAST_PATH_BITS_IMAGE flag set. > > If these two were to be set at the same time, the > fast_composite_tiled_repeat() fast path would trigger for solid images > (because it triggers for PIXMAN_any formats, which includes > PIXMAN_solid), but for solid images we can usually do better than that > fast path. > > So this patch changes the noop iterator to no longer require the > FAST_PATH_BITS_IMAGE flag and handle both solid fill images and 1x1 > bits images. Isn't this code in noop iterator mostly a duplicate of: http://cgit.freedesktop.org/pixman/tree/pixman/pixman-solid-fill.c?id=pixman-0.28.2#n29 which gets called from general_src_iter_init: http://cgit.freedesktop.org/pixman/tree/pixman/pixman-general.c?id=pixman-0.28.2#n40 At least earlier _pixman_solid_fill_iter_init was used when running cairo perf traces. But not anymore after your patch is applied. Sure, I can see a rationale to handle such simple cases earlier and not pass them through the whole fallbacks chain (where they could potentially and unexpectedly match something less efficient like fast_composite_tiled_repeat). But maybe it's a good idea to also get rid of _pixman_solid_fill_iter_init in this case (unless I'm missing something and it is still in use)? -- Best regards, Siarhei Siamashka _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman