--0000000000006733020609bc29ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dmitry, I've played a little bit around and you are right. Most likely the "image->immediateLockForReadOnly()" call seems to be the problem... It seems that the recorder never gets the chance to do its duty for long ongoing strokes. But I think I've found a suitable workaround for the problem. Because Krita seems too busy rendering sophisticated brush strokes in time, I tried to reduce the filtering of the Canvas Scaling Mode (Krita Menu -> Settings -> Configure Krita -> Display -> Canvas Acceleration (must be switched on and - in my case - it is rendered with OpenGL) -> Scaling Mode). I've changed the setting from "High Quality Filtering" to "Trilinear Filtering". This has done the trick. Now, we don't observe any white frames or build up errors, even if we use bigger brushes. I can imagine that reducing the value of the setting "Krita Menu -> Settings -> Configure Krita ->Performance -> Advanced -> Limit frames per second while painting" has also an impact on the rendering process, but I've not yet tested it. Florian Am Mi., 1. Nov. 2023 um 08:59 Uhr schrieb Dmitry Kazakov : > Hi, Florian! > > The problem happens a bit higher in the hierarchy. The problem is that th= e > recorder does not wait for the stroke to finish. Instead it just locks th= e > image for read-only in the middle of the action and reads the data. You c= an > 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: eith= er > 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 t= he > updates back in 2018, but never had time to actually implement that. > > On Tue, Oct 31, 2023 at 12:38=E2=80=AFPM Florian Reiser > 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=3D476326). But I think the bug only >> showed up just yet, because with Krita 5.2 we introduced the 10Hz record= ing >> feature. There is a good chance that it has already existed for quite so= me >> 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 wor= k a >> lot. >> >> Thank you very much for your help >> Florian >> > > > -- > Dmitry Kazakov > --0000000000006733020609bc29ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Dmitry,

I've played a little bit aroun= d and you are right. Most likely the=20 "image->immediateLockForReadOnly()" call seems to be the problem... It seems that the recorder never gets the c= hance to do its duty for long ongoing strokes.

But= I think I've found a suitable workaround for the problem. Because Krit= a seems too busy rendering=20 sophisticated brush strokes in time, I tried to reduce the filtering of t= he Canvas Scaling Mode (Krita Menu -> Settings -> Configure Krita -&g= t; Display -> Canvas Acceleration (must be switched on and - in my case = - it is rendered with OpenGL) -> Scaling Mode). I've changed the set= ting from "High Quality Filtering" to "Trilinear Filtering&q= uot;. This has done the trick. Now, we don't observe any white frames o= r build up errors, even if we use bigger brushes.

I can imagine that reducing the value of the sett= ing "Krita Menu -> Settings -> Configure Krita ->Performance -> Advanced -> Limit frames per second while painting&q= uot; has also an impact on the rendering process, but I've not yet test= ed it.

Florian

= Am Mi., 1. Nov. 2023 um 08:59=C2=A0Uhr schrieb Dmitry Kazakov <dimula73@gmail.com>:

Hi, Florian!

The problem happens a bit higher in the hierarchy. The pro= blem is that the recorder does not wait for the stroke to finish. Instead i= t 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(imag= e->projection(), image->bounds());
image->unlock()

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

Alter= natively, we could implement an epoche-based brush updates, but that is a h= uge ton of work. We wanted to implement that to handle tearing in the updat= es back in 2018, but never had time to actually implement that.

On Tue= , Oct 31, 2023 at 12:38=E2=80=AFPM 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=3D476326). But I think the bug on= ly showed up just yet, because with Krita 5.2 we introduced the 10Hz record= ing feature. There is a good chance that it has already existed for quite s= ome time.

Can someone support me to fix it. W= e 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

Dm= itry Kazakov

--0000000000006733020609bc29ca--