https://bugs.kde.org/show_bug.cgi?id=369349
Dmitry Kazakov <dimul...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dimul...@gmail.com --- Comment #32 from Dmitry Kazakov <dimul...@gmail.com> --- (In reply to RN from comment #31) > Forcing the visual updates (what the delayed painter is doing) when the > window manager can't keep up with visual updates in the first place is not > going to give the expected result, it would stutter anyway. Don't mix window updates rate, tablet events rate and painting rate. They are three different things. Tablet events rate is the rate we get the tablet events from the driver. In normal situation the events come at rate 1 event per 7-14ms. Long window updates may delay the events and they will start coming in bunches 4-5 events per every 40-50ms. Then we have "painting rate", that is a rate we generate dabs with the stabilizer algorithm and pass them to the painting code. After passing the points to the painting code, the painting code paints and generates window updates, but the updates are not passed to the GPU directly. They first compressed to not overload the pipeline with too many small updates, and only after that are passed to the GPU (on GPUs supporting glFenceSync). This final flow of updates in "painting rate" and it cannot be higher than the GPU can handle. Basically, the flow looks like that: 1) Tablet events come in bunches every 7-50 ms. 2) KisStabilizedEventsSampler delays the flow by 50ms. That allows it to group the evens into 50ms groups and to adjust the time as if the events inside the group were flowing uniformly (e.g. for group of 5 events, the sampler will modify them as if they they were issues every 10ms). 3) These groups of events come to KisStabilizerDelayedPaintHelper, that regroups the groups from the sampler into groups of 20ms (20ms == 40fps, which should be enough for everyone(c)) and passes them to the painting code every 20 ms. Now I see that a thing that can happen is that delayed painter is not synchronized with the sampler. That is, it might happen that the delay helper can have "empty" cycles, where the samples from the sampler are not ready yet. To avoid the problem we should sync the timers of sampler and delay helper to be a multiple of each other. A quite test for this hypothesis might be to set: stabilizerSampleSize=60 stabilizerDelayedPaintInterval=20 That is still not very "sync", but if it makes the things better then we should move into this direction further. Probably, by merging the two timers into one. > In Dmitry's case the timer interval would've grown > until reaching 50ms or more. > The timer is stopped when the stroke ends, and when a new stroke begins the > timer interval starts at some default value (16ms for example, or 1ms like > 2.9.11 although that might be too fast). In feedback control systems theory it is called "proportional regulator". And it it really a bad thing to use, unless there is no other choice. What if the I accidentally have a delay of 200ms? Will all my further strokes be smoothed by 200ms? And if not, then we should do some PI-regulator, which is stable enough and still does the job. It may have quite a lot of unexpected consequences. > Whatever is decided, I think something should be added to the interface > (maybe in Configure Krita -> Tablet Preferences), like spinboxes to set > timer values so that users don't have to go and modify 'kritarc' themselves, > and be able to quickly test different values without having to restart the > program. Someone above mentioned having difficulty doing that, for example. > Regards. I have a feeling that there is some bug in how we handle the events flow. We should first try to fix it, instead of giving the user an option to control such non-obvious property. As a direction of further work, it might be a good idea to have a log of how many events are usually handled in KisStabilizerDelayedPaintHelper::stabilizerDelayedPaint() when isEndStroke is false. If the number of events is always the same, then my theory is probably not correct. If it interleaves with zero like "10,0,11,0,9,0...", then my theory is correct. -- You are receiving this mail because: You are watching all bug changes.