<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Replaying recording surfaces with OVER has far worse performance than when using the SOURCE operator"
href="https://bugs.freedesktop.org/show_bug.cgi?id=88203#c7">Comment # 7</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Replaying recording surfaces with OVER has far worse performance than when using the SOURCE operator"
href="https://bugs.freedesktop.org/show_bug.cgi?id=88203">bug 88203</a>
from <span class="vcard"><a class="email" href="mailto:emanuele.aina@collabora.com" title="Emanuele Aina <emanuele.aina@collabora.com>"> <span class="fn">Emanuele Aina</span></a>
</span></b>
<pre><span class="quote">> There is a problem with using OVER as a shortcut here over existing content.
> The problem is that the command is to blend the final result of the replay
> with the existing content, but the inplace replay with apply its own
> operators with the existing content (when the intent of the replay is to
> apply those only to itself).</span >
Shame, that's what I feared. This means that the documentation is somewhat
misleading: as I read it, I interpreted the recording surfaces as a mechanism
to get delayed execution, for which I would have expected that the replay
operators *would* mess with the target surface.
My understanding is that an alternative way to get the current behaviour is to
always explicitly replay the recorded operations to a temporary surface and
then composite it, but there's no way to get the delayed execution which is
somewhat described in the documentation.
If the point of recording surfaces is not delayed execution, what's their real
use-case?
<span class="quote">> Sorry, the requirement is that the dst->is_clear for OVER to be able to
> replay in place. You could analyse the replay and decide that it doesn't use
> any operators that would mess up inplace though.</span >
This is definitely well above my current understanding of cairo's code, sorry.
:(
I can probably hack my application to use the SOURCE operator and some smart
clipping to avoid the performance hit, but I honestly find the current
behaviour quite surprising.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>