[cairo] [PATCH] pixman: fast path for nearest neighbour scaled compositing operations.

[Siarhei Siamashka]

On Saturday 30 May 2009 20:58:29 ext Soeren Sandmann wrote:
> Hi,
>
> > > > +/*
> > > > + * Check if we actually have source clipping. Just comparing
> > > > pointers + * does not work, so full comparison of regions is needed.
> > > > Source + * clipping is enforced in X server since the fix of
> > > > + * http://bugs.freedesktop.org/show_bug.cgi?id=11620
> > >
> > > Why isn't comparing pointers sufficent for checking source clipping?
> > >
> > > pixman_image_set_source_clipping() does
> > > 	common->src_clip = &common->full_region;
> > > when source_clipping is false.
> >
> > As described in the comment, it just does not work well in X server. X
> > server marks all the images as having source clipping unconditionally and
> > always hits the slow path, hurting performance.
>
> See this mail:
>
>     http://lists.cairographics.org/archives/xorg-devel/2009-May/000819.html
>
> I sent a patch to implement this here:
>
>     http://lists.cairographics.org/archives/xorg-devel/2009-May/000893.html
>
> Unfortunately, that patch doesn't work because a lot of the
> untransformed code paths in pixman assume that they will never be
> called with coordinates outside the sources. This is broken; they need
> to deal with the repeat modes instead.
>
> Clipping in Render and pixman is a mess. The clip-in.c test program
> demonstrates that setting a transformation matrix completely changes
> the interpretation of the clip, even though the transformation is just
> a 0.001, 0.001 translation.
>
> I intend to fix this as part of the refactoring. 

Cool.

Overall, I can't comment much on this issue as I don't know who is using the
feature and in what way they may or may not break.

As long as it is easy to identify when no source clipping is needed in 
fastpath functions, I don't care much about how the source clipping is going
to work. My only concern are potential breakages in the applications which
relied on this feature.

> The plan is 
> essentially move all source clip handling into
> pixman_compute_composite_region(); the rest of the code can then
> forget that clipping even exists, but in return it will need to use
> pixman_walk_composite_region() and deal properly with repeat modes.

I'm not very enthusiastic about relying on pixman_walk_composite_region() too
much. Currently pixman has a hack to avoid passing 1x1 images to it, but it is
not bulletproof and it is quite possible to encounter a real practical case
when the performance would be bad. For example, some websites love to use
tiling of 1xN or Nx1 images to get some nice gradient picture in the
background: http://browser.garage.maemo.org/

> In this particular case, for now please just use
> pixman_region32_equal().

OK

-- 
Best regards,
Siarhei Siamashka