Bug 378158 - Transform mask with Liquify
Summary: Transform mask with Liquify
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Transform (show other bugs)
Version: 3.1.2
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-27 14:13 UTC by Dmitrii Utkin
Modified: 2017-04-06 10:03 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
screencast to reproduce the problem (1.22 MB, video/mp4)
2017-03-27 14:13 UTC, Dmitrii Utkin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitrii Utkin 2017-03-27 14:13:37 UTC
Created attachment 104759 [details]
screencast to reproduce the problem

Transform mask with Liquify does not work as expected.

If you apply liquify to the transform mask and switch transform layer visibility off and on, the layer become transparent when mask's visibility is on.

Also if you try to save when mask's visibility is on (and layer is invisible), you may see the "Waiting for image operation to complete..." dialog with non-working "Cancel operation and Save" button.

At this moment suspicious messages in log may appear, such as:

QObject::killTimer: Timers cannot be stopped from another thread
Comment 1 Dmitry Kazakov 2017-03-29 13:35:42 UTC
Git commit 2071a0701c68caa92eb8115077f8379b3803041e by Dmitry Kazakov.
Committed on 29/03/2017 at 13:34.
Pushed by dkazakov into branch 'kazakov/svg-loading'.

Fix a race condition in KisUpdateScheduler

If spareThreadAppeared() signal comes between `m_d->processingBlocked = true`
and `m_d->processingBlocked = false` lines, then no update will be started
even when we return from the barrier lock call.

In normal case, when the barrier lock is successful, processQueues()
is called in the unlock call, but here it doesn't happen.

M  +3    -1    libs/image/kis_update_scheduler.cpp

https://commits.kde.org/krita/2071a0701c68caa92eb8115077f8379b3803041e
Comment 2 Halla Rempt 2017-04-06 10:03:24 UTC
Git commit 3a793d0208c8b88211764be25b0a942d25a192fa by Boudewijn Rempt, on behalf of Dmitry Kazakov.
Committed on 06/04/2017 at 10:02.
Pushed by rempt into branch 'krita/3.1'.

Fix a race condition in KisUpdateScheduler

If spareThreadAppeared() signal comes between `m_d->processingBlocked = true`
and `m_d->processingBlocked = false` lines, then no update will be started
even when we return from the barrier lock call.

In normal case, when the barrier lock is successful, processQueues()
is called in the unlock call, but here it doesn't happen.

M  +3    -1    libs/image/kis_update_scheduler.cpp

https://commits.kde.org/krita/3a793d0208c8b88211764be25b0a942d25a192fa