Summary: | Animation: MacOS: Frame playback order is offset with respect to frame number with 8-bit integer images | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | schmittsarahe19 |
Component: | Animation | Assignee: | Krita Bugs <krita-bugs-null> |
Status: | CONFIRMED --- | ||
Severity: | minor | CC: | ahab.greybeard, ghevan, irvingtao |
Priority: | NOR | ||
Version: | 4.3.0-beta1 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | macOS | ||
Latest Commit: | Version Fixed In: |
Description
schmittsarahe19
2020-05-29 18:28:32 UTC
Also, when I change the settings of the file from 8-bit integer scRGB (default) to 16-bit integer scRGB (linear), then it will work correctly. 16-bit default file setting works fine as well. This was first noted and discussed at: https://krita-artists.org/t/frame-timing-issue/7678 I happens for the OP with version 4.2.9 and 4.3.0 beta-1. @schmittsarahe19: Can you do Help -> Show system information for bug reports and then copy/paste the output in a comment here? This is cosmetic issue. The first time the highlighted frame changes there is no update on the canvas, that happens until the second time the highlighted frame advances. Changing the image to 16-bit does not fixes the issue. Only happens on macos. but did not test on windows. Here you go! Sorry I haven't been active recently! Krita Version: 4.3.0-beta1 Languages: Hidpi: true Qt Version (compiled): 5.12.8 Version (loaded): 5.12.8 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: darwin Kernel Version: 19.5.0 Pretty Productname: macOS 10.15 Product Type: osx Product Version: 10.15 OpenGL Info Vendor: "Intel Inc." Renderer: "Intel(R) HD Graphics 6000" Version: "4.1 INTEL-14.6.18" Shading language: "4.10" Requested format: QSurfaceFormat(version 3.2, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CoreProfile) Current format: QSurfaceFormat(version 4.1, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CoreProfile) Version: 4.1 Supports deprecated functions false is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: false isQtPreferOpenGLES: true Hardware Information GPU Acceleration: desktop Memory: 4096 Mb Number of Cores: 4 Swap Location: /private/var/folders/sh/ctbsmjf57755c6fzkxg_x0_h0000gn/T Current Settings Current Swap Location: /private/var/folders/sh/ctbsmjf57755c6fzkxg_x0_h0000gn/T Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 30 Use OpenGL: true Use OpenGL Texture Buffer: true Use AMD Vectorization Workaround: false Canvas State: OPENGL_SUCCESS Autosave Interval: 900 Use Backup Files: true Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: false Use Zip64: false Display Information Number of screens: 1 Screen: 0 Name: Color LCD Depth: 24 Scale: 1 Resolution in pixels: 1366x768 Manufacturer: Model: Refresh Rate: 60 Still present in git 8b61f56ebf44924e using krita 5.2.2 on macos sonoma and this is occuring to me on both 8-bit and 16-bit images for me. over 3 years later and it seems this bug is still around ): |