Re: Painting an image surface into itself in order to scroll it

On Mon, 31 Dec 2012 00:45:24 +0200
Siarhei Siamashka <[email protected]> wrote:

> On Sun, 30 Dec 2012 15:54:56 +0100
> Uli Schlachter <[email protected]> wrote:
> 
> > Hi,
> > 
> > On 27.12.2012 09:26, Nicholas Allen wrote:
> > > If I create an image surface and then try to scroll it by painting it
> > > into itself then it works as long as I scroll it left, right, or up but
> > > not if I scroll it down.
> > 
> > Having the same surface as both target and source of a drawing operation in 
> > cairo is not allowed. This invokes undefined behavior and will not be supported. 
> > (However, I cannot find a reference for this right now)
> > 
> > So this is not a bug in cairo.
> 
> Well, the issue is a bit tricky and has some history. Cairo seems
> to be handling overlapped copies for xlib backend by preferring
> XCopyArea since:
>     https://bugs.freedesktop.org/show_bug.cgi?id=29250
> It also has self-copy.c and self-copy-overlap.c tests specifically to
> test for this functionality:
>     http://cgit.freedesktop.org/cairo/tree/test?id=1.12.8
> 
> But the image backend (hence adding pixman to CC) does not support this
> yet. There were some attempts at implementing this functionality.
> 
> The older one from me for just pixman_blt function (which is
> actually used for XCopyArea function in X server):
>     http://lists.cairographics.org/archives/cairo/2009-October/018359.html
> The patches are not available in the mailing list archives,
> but looks like they (and some of the others) had been carried
> by the openembedded distro:
>     http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/032015.html
> 
> The other patchset was from Mozilla:
>     http://lists.cairographics.org/archives/cairo/2010-April/019780.html
>     http://lists.cairographics.org/archives/cairo/2010-May/019800.html
>     https://bugzilla.mozilla.org/show_bug.cgi?id=563488
> In my opinion it went a bit overboard by implementing the overlapped
> compositing functionality for all the compositing operations, even
> those where it makes little sense. For example, the compositing
> operators where the result depends on the pixel data from the
> destination image (for example OVER operator) or when we have
> non-identity transformation matrix set. Those cases were handled by
> allocating an internal temporary copy of the whole image.
> Also unfortunately this patchset did not provide the tests for such
> complex new functionality to the pixman test suite to cover all the
> compositing operators including both transformed and non-transformed
> cases and also complex clipping. The missing tests happened to be the
> main blocker as far as I remember, and Mozilla people just did not have
> time to implement them.
> 
> > > It seems cairo has a bug that this is not possible with just one image
> > > surface if you scroll the contents downwards. I can work around it by
> > > creating 2 image surfaces and copying one to the other but I would
> > > expect cairo to be able to handle this with just one surface.
> > 
> > If you don't do the copy to an extra surface, cairo would have to do it for you. 
> > This means that the resulting performance is equally bad. Yes, there could be 
> > shortcuts for the image backend, but I think most other (raster) backends would 
> > have to do the extra copy.
> > 
> > So it is a good thing that this does not actually work. This way you notice that 
> > the results are wrong and can fix it in your code. For example, using two image 
> > surfaces which are swapped avoids one copy and thus saves time in a way that 
> > cairo wouldn't be able to do by itself.
> 
> Yes, it's a good idea to make sure that the library realize that some

s/library/users/

> functionality may be not free and requires something as inefficient as
> internal temporary image copies (which may need extra CPU cycles and
> sometimes a lot of memory).
> 
> But one really good practical use, which can be implemented efficiently
> by the image backend, is simple scrolling. This means SOURCE operator
> only and no transformation matrix. Though complex clipping and different
> types of repeat may be still funny to handle correctly even with this
> limitation.

-- 
Best regards,
Siarhei Siamashka
-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo