On Mon, 31 Dec 2012 00:45:24 +0200 Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> On Sun, 30 Dec 2012 15:54:56 +0100 > Uli Schlachter <psyc...@znc.in> 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 _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman