[cairo] is self-copy supposed to work?

[Siarhei Siamashka]

On Friday 30 April 2010, Robert O'Callahan wrote:
> On Fri, Apr 30, 2010 at 11:28 PM, Chris Wilson wrote:
> > Currently self-copy behaviour is underspecified. I think the consensus is
> > that self-modification is undesired...
>
> Maybe so. However, I am dealing with a case where it is desired. I am using
> a surface as backing store, and the simplest way to implement scrolling is
> to do a SOURCE self-copy.

This self-copy problem happens to be discussed here periodically:
http://lists.cairographics.org/archives/cairo/2009-June/017296.html

Indeed, I agree that pixman should contain an optimized SOURCE self-copy
implementation specifically for the purpose of scrolling.

> The alternative strategies all seem to require 
> using additional buffers, which uses more memory and probably isn't as fast
> due to poorer memory locality.

Yes, this is very bad for performance. Especially on the systems with slow
memory.

> Also I think it's generally a bad idea for an API to just do something
> random in certain special cases.

People familiar with C programming language and 'memcpy' function should not
be surprised too much. Undefined behavior is ok as long as it is clearly
documented. And especially if it also helps to have better performance and
avoid redundant complexity.

> I can't think of any reasonable behaviour other than to make self-copies
> just work. It's not that hard for the general case; just detect the 
> self-copy and use a temporary buffer.

AFAIK there are some plans to support sub-images eventually, and it will make
self-copy detection somewhat more tricky.

Also, what is going to happen if an application deliberately performs some
operations inside of all the same image, but with non-overlapping pixel areas?
Will it be penalized with the use of a temporary buffer just because this
simple self-copy detection will be triggered? And a precise self-copy
detection is not so simple on general composite path. For example when
transform and/or complex clipping is involved.

In my opinion the right solution for this problem is a separate function
in addition to (or instead of) 'pixman_blt', with a clearly defined behavior
with the regards to self-copy support.

> Some simple cases (i.e., the cases I 
> care about!) can easily be optimized to avoid the temporary buffer.

Yes, but simple cases can probably use simple solutions.

What are you going to actually do with a complete (and complex) self-copy 
aware implementation when it is done? It might be an overkill just for a
simple scrolling.

Is there a practical use case for self-copy aware OVER compositing?

-- 
Best regards,
Siarhei Siamashka