Created attachment 117273 [details] gif of the problem STEPS TO REPRODUCE 1. set up a new krita document 2. show the transparent layer (layer 2) in the timeline 3. create a new frame and opacity keyframe for that layer 4. draw on the frame so there's a visible difference than before 5. make some opacity keyframes so krita animates the opacity from frame to frame 6. scroll before and after hitting play to see the difference (as well as watching what happens while it's playing) OBSERVED RESULT [see middle of attachment] EXPECTED RESULT [see beginning of attachment] SOFTWARE/OS VERSIONS Windows: 10 Note: because of the really small file size limit, the gif had to basically be compressed/resized to microscopic proportions so the text is probably hard to read, and you may have to put it into your web browser to zoom in on it
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.