[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Race condition in one of Kritas internal Data Manager implementations?
From:       Dmitry Kazakov <dimula73 () gmail ! com>
Date:       2023-11-01 7:59:26
Message-ID: CAEkBSfXthqf2DH8OGYXzerfw9NsGSFe5tyJuFmenvFi-SJAcDw () mail ! gmail ! com
[Download RAW message or body]

Hi, Florian!

The problem happens a bit higher in the hierarchy. The problem is that the
recorder does not wait for the stroke to finish. Instead it just locks the
image for read-only in the middle of the action and reads the data. You can
see that in this piece of code:

image->immediateLockForReadOnly();
device->makeCloneFromRough(image->projection(), image->bounds());
image->unlock()

The only wait to avoid white/incomplete frames in the recorder is to make
snapshots "between" the strokes. There are two ways to achieve that: either
use barrierLock() (not-recommended) or create a stroke that makes a copy of
the image. Just like Overview and Channels dockers do. The only problem
with this approach is that the 100ms timing will not be satisfied in this
case. The recorder would wait for the user's stroke to end (which might
easily take more than 100ms) and then just add a frame. It would make the
framerate of the final production not very stable (though I'm not sure if
it is a problem).

Alternatively, we could implement an epoche-based brush updates, but that
is a huge ton of work. We wanted to implement that to handle tearing in the
updates back in 2018, but never had time to actually implement that.

On Tue, Oct 31, 2023 at 12:38 PM Florian Reiser <reiserfm@gmail.com> wrote:

> Hi everyone,
>
> not sure if this is the right channel to ask this. I hope this mail
> reaches some of the right people.
>
> I've created a bug report for the newest Krita Version (
> https://bugs.kde.org/show_bug.cgi?id=476326). But I think the bug only
> showed up just yet, because with Krita 5.2 we introduced the 10Hz recording
> feature. There is a good chance that it has already existed for quite some
> time.
>
> Can someone support me to fix it. We really want to use the new 10Hz
> Feature for one of our projects, it would reduce our post production work a
> lot.
>
> Thank you very much for your help
> Florian
>


-- 
Dmitry Kazakov

[Attachment #3 (text/html)]

<div dir="ltr">Hi, Florian!<div><br></div><div>The problem happens a bit higher in \
the hierarchy. The problem is that the recorder does not wait for the stroke to \
finish. Instead it just locks the image for read-only in the middle of the action and \
reads the data. You can see that in this piece of \
code:</div><div><br></div><div>image-&gt;immediateLockForReadOnly();<br>device-&gt;makeCloneFromRough(image-&gt;projection(), \
image-&gt;bounds());<br>image-&gt;unlock()<br></div><div><br></div><div>The only wait \
to avoid white/incomplete frames in the recorder is to make snapshots \
&quot;between&quot; the strokes. There are two ways to achieve that: either use \
barrierLock() (not-recommended) or create a stroke that makes a copy of the image. \
Just like Overview and Channels dockers do. The only problem with this approach is \
that the 100ms timing will not be satisfied in this case. The recorder would wait for \
the user&#39;s stroke to end (which might easily take more than 100ms) and then just \
add a frame. It would make the framerate of the final production not very stable \
(though I&#39;m not sure if it is a problem).</div><div><br></div><div>Alternatively, \
we could implement an epoche-based brush updates, but that is a huge ton of work. We \
wanted to implement that to handle tearing in the updates back in 2018, but never had \
time to actually implement that.</div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Tue, Oct 31, 2023 at 12:38 PM Florian Reiser &lt;<a \
href="mailto:reiserfm@gmail.com">reiserfm@gmail.com</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi \
everyone,</div><div><br></div><div>not sure if this is the right channel to ask this. \
I hope this mail reaches some of the right people.</div><div><br></div><div>I&#39;ve \
created a bug report for the newest Krita Version (<a \
href="https://bugs.kde.org/show_bug.cgi?id=476326" \
target="_blank">https://bugs.kde.org/show_bug.cgi?id=476326</a>). But I think the bug \
only showed up just yet, because with Krita 5.2 we introduced the 10Hz recording \
feature. There is a good chance that it has already existed for quite some time. \
<br></div><div><br></div><div>Can someone support me to fix it. We really want to use \
the new 10Hz Feature for one of our projects, it would reduce our post production \
work a lot.</div><div><br></div><div>Thank you very much for your \
help</div><div>Florian<br></div></div> </blockquote></div><br \
clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div \
dir="ltr" class="gmail_signature">Dmitry Kazakov</div>



[prev in list] [next in list] [prev in thread] [next in thread]