Bug 402841

Hi Tristan, 
I'm sorry but the attached image is really small (200px) and it's difficult to see the problem. Please, could you upload another example (4MB limit) or provide details on what happens and what you would expect? Thanks :)

(In reply to mvowada from comment #1)
> Hi Tristan, 
> I'm sorry but the attached image is really small (200px) and it's difficult
> to see the problem. Please, could you upload another example (4MB limit) or
> provide details on what happens and what you would expect? Thanks :)

I would've uploaded with a better resolution but the file would go over the limit. I can try to use a better gif and just chop it up into separate pieces

Created attachment 117289 [details]
imgur link to gif

Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.

I confirm that this happens in the 4.1.7 appimage and the Jan 4th nightly build appimage (git 91c359e).

With manual frame 'sweeping', the Layers docker opacity indicator correctly displays the frame opacity (as determined by the opacity curve set up in the Animation Curves docker).

However, after Play has been run, the Layers docker opacity display is then frozen at the opacity of the last manually selected frame and will not track during manual sweeping. It will correctly track if an individual frame is clicked/selected but not during manual sweeping.

This frozen state can be cleared by turning 'off' the layer visibility then the Layer docker opacity indicator will correctly track the frame opacity when manually sweeping. (You do, of course, turn it back on again because having the layer invisible is not much use but the freezing is cleared when the layer is turned off.)

The frozen state returns after a Play has been done.

Created attachment 117303 [details]
Copied from imgur

Git commit aed191675e826f37d1173af49d22b212094c434a by Jouni Pentikäinen.
Committed on 09/01/2019 at 16:12.
Pushed by jounip into branch 'master'.

Always update UI time when changing displayed frame

Before this change, playback for cached vs. uncached frames behaved
slightly differently, causing some frames to never be displayed when
scrubbing.

This also fixes missing UI updates for layer opacity slider when the
property is animated.
Related: bug 401630

M  +3    -3    libs/ui/canvas/kis_animation_player.cpp

https://commits.kde.org/krita/aed191675e826f37d1173af49d22b212094c434a

The fix was reverted, because it breaks playback
https://commits.kde.org/krita/1af5c349f0705fa5c14b3740508994a5352e9e6e

I am setting this back to confirmed as this bug has already been confirmed.

Created attachment 119523 [details]
Test image with opacity curve

Additional info: the render of frames s also incorrect. It is also incorrect in 4.0.0, while 3.3.3 was working correctly both in playback and in rendered image sequence.

You can render the image I provided to image sequence in both Krita versions and see how in the newer version it creates copies of one opacity setting, then there is a visible step and next frames have the lower opacity setting etc. When you render it in 3.3.3, the steps are not visible, every next frame is only slightly lighter than the previous one.

Note: when I enable Transform Mask animation curves in the code, the similar problem is visible. Creating a lot of duplicate frames and merging the layer with Transform Mask creates correct results, and since then frames are simple paint frames, the render is correct.

Possible workaround:

1. Take the layer with opacity keyframes.
2. Add a transparency mask or something similar (doesn't need to change the result in any way).
3. Create duplicate frames on the whole sequence. It's very important, the result will only have the frames that are created in this point.
4. Right-click and choose "Flatten Layer".

Result: you have a lot of semi-transparent frames with correct (I think) transparency settings consistent with previously existing Opacity Keyframes.

I've just had a look at the opacitykeyframes-testimage.kra file from Tymond Comment 10 and I've noticed something that seems significant.
The fault as described did not happen with 4.1.7 or with a recent 4.2.0 pre-alpha. Brief investigation showed that this was because I had Canvas Graphics Acceleration turned off. When I enabled Canvas Graphics Acceleration, the fault returned exactly as described.
Does this observation help to track down the cause and suggest a possible solution?

Turning OpenGL off seems to break animation frame caching so it doesn't generate at all. Opacity keyframes seem to work only when there is no frame caching being used

This should be fixed now as of a combination of commit 2007269642067b388e4b2698afd8bf97b6727051 and commit 12ca3f6656d0452e92f9090da71312eefb774a46 . The issue had to do with a combination of how frame differences were calculated and a data-race issue where cloned images had incorrect references to the image's current time.