On Thu, May 6, 2010 at 12:20 AM, Siarhei Siamashka <span dir="ltr"><<a href="mailto:siarhei.siamashka@gmail.com">siarhei.siamashka@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Friday 30 April 2010, Robert O'Callahan wrote:<br><br><div class="im">
> Also I think it's generally a bad idea for an API to just do something<br>
> random in certain special cases.<br>
<br>
</div>People familiar with C programming language and 'memcpy' function should not<br>
be surprised too much.</blockquote><div><br>People familiar with C are used to pain, it's true :-)<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Undefined behavior is ok as long as it is clearly<br>
documented. And especially if it also helps to have better performance and<br>
avoid redundant complexity.<br></blockquote><div><br>Maybe so, but in this case I don't think it does. I think pixman and cairo could just support self-copies without adding much complexity or hurting performance.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> I can't think of any reasonable behaviour other than to make self-copies<br>
> just work. It's not that hard for the general case; just detect the<br>
> self-copy and use a temporary buffer.<br>
<br>
</div>AFAIK there are some plans to support sub-images eventually, and it will make<br>
self-copy detection somewhat more tricky.<br></blockquote><div><br>We'd just need an internal API to get the true underlying surface, right?<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Also, what is going to happen if an application deliberately performs some<br>
operations inside of all the same image, but with non-overlapping pixel areas?<br>
Will it be penalized with the use of a temporary buffer just because this<br>
simple self-copy detection will be triggered?<br></blockquote><div><br>An application shouldn't be doing that; applications should not rely on undefined behavior. If you want applications to be able to do that reliably, then we do need to define behavior for self-copy.<br>
<br>Exposing APIs with random behavior is bad. Applications coming to rely on particular details of that random behavior is worse.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
> Some simple cases (i.e., the cases I<br><div class="im">
> care about!) can easily be optimized to avoid the temporary buffer.<br>
<br>
</div>Yes, but simple cases can probably use simple solutions.<br>
<br>
What are you going to actually do with a complete (and complex) self-copy<br>
aware implementation when it is done? It might be an overkill just for a<br>
simple scrolling.<br></blockquote><div><br>It doesn't have to be complex. See Matt's patch.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Is there a practical use case for self-copy aware OVER compositing?<br></blockquote><div> </div></div>I don't know. But if there isn't, then no-one's going to hit a slow path.<br clear="all"><br>Rob<br>-- <br>
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>