[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Dmitry Kazakov changed: What|Removed |Added CC||pipboymodel3...@gmail.com --- Comment #66 from Dmitry Kazakov --- *** Bug 416893 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #65 from Dmitry Kazakov --- Git commit ddd2a774f2b45ae6cedac34557be835215a61895 by Dmitry Kazakov. Committed on 02/04/2020 at 09:51. Pushed by dkazakov into branch 'master'. Fix hiccups when zooming with a tablet The hiccups while zooming were happening because of gui controls like sliders and mode combo box being updated too often during the tablet stroke. This patch should also fix the FPS ussies while zooming. Now FPS should be only limited by the underlying GPU (therefore 60+ FPS). M +2-2libs/ui/KisView.cpp M +1-1libs/ui/KisViewManager.cpp M +28 -19 libs/ui/kis_zoom_manager.cc M +6-1libs/ui/kis_zoom_manager.h M +23 -12 libs/widgets/KoZoomAction.cpp M +7-11 libs/widgets/KoZoomAction.h https://invent.kde.org/kde/krita/commit/ddd2a774f2b45ae6cedac34557be835215a61895 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #64 from Alex Mandrei --- Aright,thanks!Sorry for bothering:D -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #63 from Ahab Greybeard --- @Alex: If you want detailed technical (or artistic) discussion and advice on just about any aspect of krita, a good place to go is here: https://forum.kde.org/viewforum.php?f=139 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #62 from Boudewijn Rempt --- No, it's safe. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #61 from Alex Mandrei --- (In reply to Boudewijn Rempt from comment #60) > Then you need to remove the old version -- if it was installed using an > installer, uninstall it. If it was a portable version, remove the folder for > the old version entirely and unpack the zip somewhere. Do not copy anything > from a newer version into an older version. Ok,thanks! Uninstalling the old version won't delete anything stuff like resources etc right? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #60 from Boudewijn Rempt --- Then you need to remove the old version -- if it was installed using an installer, uninstall it. If it was a portable version, remove the folder for the old version entirely and unpack the zip somewhere. Do not copy anything from a newer version into an older version. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #59 from Alex Mandrei --- (In reply to Boudewijn Rempt from comment #58) > On all operating systems it's possible to keep multiple versions of Krita > around. > > On Linux: use the appimage, and just start the one you need > On Windows: download the portable zip version, unpack it somewhere (I use > the desktop) and start the one you want > On MacOS: download the dmg, extract and put the krita.app bundle somewhere > (I use ~/Desktop/v4.2.9/krita.app, for instance) > > If you want, you can use the nightly stable build for Linux and Windows -- > there's no working nightly for macOS yet, but we're working on that. > > * https://binary-factory.kde.org/job/Krita_Stable_Appimage_Build/ > * https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/ Thanks,but well,i want only one version installed tho.Do i just paste the new zip file on the already installed version ,is it ok?I just want to have one version with the fixed bug .Sorry,but im incompetent -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #58 from Boudewijn Rempt --- On all operating systems it's possible to keep multiple versions of Krita around. On Linux: use the appimage, and just start the one you need On Windows: download the portable zip version, unpack it somewhere (I use the desktop) and start the one you want On MacOS: download the dmg, extract and put the krita.app bundle somewhere (I use ~/Desktop/v4.2.9/krita.app, for instance) If you want, you can use the nightly stable build for Linux and Windows -- there's no working nightly for macOS yet, but we're working on that. * https://binary-factory.kde.org/job/Krita_Stable_Appimage_Build/ * https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/ -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #57 from Alex Mandrei --- (In reply to Dmitry Kazakov from comment #54) > I think I can finally close this bug :) Omg,the zoom is 10% better ,thank you a lot!!Much appreciated! I have a little newbie question,if i delete the main directory of krita and just replace it with this new one ,nothing bad will happen right?So i don't have two versions of krita at the same time..Or maybe could i search and replace only the changed files in the directory that i had already,4.2.9? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #56 from Boudewijn Rempt --- Git commit d76898f142f4c20d8422c45a84bb0c37f5aa0eb4 by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 02/04/2020 at 13:09. Pushed by rempt into branch 'krita/4.3'. Fix hiccups when zooming with a tablet The hiccups while zooming were happening because of gui controls like sliders and mode combo box being updated too often during the tablet stroke. This patch should also fix the FPS ussies while zooming. Now FPS should be only limited by the underlying GPU (therefore 60+ FPS). (cherry picked from commit 4d7f3461458d2608130187fb992797f67a0148fc) M +2-2libs/ui/KisView.cpp M +1-1libs/ui/KisViewManager.cpp M +28 -19 libs/ui/kis_zoom_manager.cc M +6-1libs/ui/kis_zoom_manager.h M +23 -12 libs/widgets/KoZoomAction.cpp M +7-11 libs/widgets/KoZoomAction.h https://invent.kde.org/kde/krita/commit/d76898f142f4c20d8422c45a84bb0c37f5aa0eb4 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #55 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #54) > I think I can finally close this bug :) Good job man ;0. Hopefully everything works just fine, I guess this was an annoying thing to deal with, huh? ;0 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Dmitry Kazakov changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #54 from Dmitry Kazakov --- I think I can finally close this bug :) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #53 from Dmitry Kazakov --- Git commit 4d7f3461458d2608130187fb992797f67a0148fc by Dmitry Kazakov. Committed on 02/04/2020 at 12:02. Pushed by dkazakov into branch 'master'. Fix hiccups when zooming with a tablet The hiccups while zooming were happening because of gui controls like sliders and mode combo box being updated too often during the tablet stroke. This patch should also fix the FPS ussies while zooming. Now FPS should be only limited by the underlying GPU (therefore 60+ FPS). M +2-2libs/ui/KisView.cpp M +1-1libs/ui/KisViewManager.cpp M +28 -19 libs/ui/kis_zoom_manager.cc M +6-1libs/ui/kis_zoom_manager.h M +23 -12 libs/widgets/KoZoomAction.cpp M +7-11 libs/widgets/KoZoomAction.h https://invent.kde.org/kde/krita/commit/4d7f3461458d2608130187fb992797f67a0148fc -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #52 from Dmitry Kazakov --- Hi, lempikq! Yes, it should be smoother than in 4.2.7, because in 4.2.7 zoom's FPS was limited to something like 25-30 FPS, and now it is mostly unlimited. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #51 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #50) > Hi, all! > > Could you please check this package? I guess I have fixed the issue. Now > zooming should work even better than in 4.2.7, because FPS is not limited by > anything (basically, it should zoom with 60+FPS). > > https://yadi.sk/d/i2hFbRZYlGCDlw Hi Dmitry, I just tried it, it's smooth as butter maybe even smoother. Actually it might be smoother than the 4.2.7 if it's even possible? xD I'll try it today for a longer period just in case but I had no freeze and no "lag". Thank you! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #50 from Dmitry Kazakov --- Hi, all! Could you please check this package? I guess I have fixed the issue. Now zooming should work even better than in 4.2.7, because FPS is not limited by anything (basically, it should zoom with 60+FPS). https://yadi.sk/d/i2hFbRZYlGCDlw -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 fahmi.kere...@gmail.com changed: What|Removed |Added CC||fahmi.kere...@gmail.com --- Comment #49 from fahmi.kere...@gmail.com --- have you guys tried zooming with mouse? cause ive got exactly this kind of problem, but it only happens when you zoom dragging with a pen tab. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 David Lopes changed: What|Removed |Added CC||davidlopesplay...@gmail.com --- Comment #48 from David Lopes --- Krita Version: 4.2.9 Languages: en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, pt_BR, pt, en_US, en Hidpi: true Qt Version (compiled): 5.12.7 Version (loaded): 5.12.7 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.18363 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce 9600 GSO 512/PCIe/SSE2" Version: "3.3.0" Shading language: "3.30 NVIDIA via Cg compiler" Requested format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format:QSurfaceFormat(version 3.3, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::sRGBColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 3.3 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsAngleD3D11: false isQtPreferAngle: false Hardware Information GPU Acceleration: desktop Memory: 4095 Mb Number of Cores: 2 Swap Location: C:/Users/david/AppData/Local/Temp Current Settings Current Swap Location: C:/Users/david/AppData/Local/Temp Undo Enabled: 1 Undo Stack Limit: 30 Use OpenGL: 1 Use OpenGL Texture Buffer: 1 Use AMD Vectorization Workaround: 0 Canvas State: OPENGL_SUCCESS Autosave Interval: 900 Use Backup Files: 1 Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Use Win8 Pointer Input: 0 Use RightMiddleTabletButton Workaround: 0 Levels of Detail Enabled: 0 Use Zip64: 0 Display Information Number of screens: 1 Screen: 0 Name: \\.\DISPLAY1 Depth: 32 Scale: 1 Resolution in pixels: 1280x1024 Manufacturer: Model: Refresh Rate: 60 i have the same bug, and i use xp-pen star 03 this bug started after 4.2.8 update -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #47 from Ahab Greybeard --- (In reply to Rebecca Breu from comment #46) The line: OpenGLRenderer=none corresponds to Canvas Graphics Acceleration being off. =auto and =desktop are for Preferred Renderer being Auto(OpenGL) and OpenGL with Canvas Graphics Acceleration being on. In my Comment 7, I was wrong about needing a restart for Graphics Acceleration being turned on and off. The state of Canvas Graphics Acceleration is acted on immediately after the OK button is pressed in the Configure Krita window. If Canvas Graphics Acceleration is actually on and kritadisplayrc is edited to have OpenGLRenderer=none, the operation of krita is not affected. If you open the config window, it shows Canvas Graphics Acceleration is off. If you them turn it on and do OK, displayrc is updated (=auto) but it still has lag on zoom. Hence I now have lag on zoom with Canvas Graphics Acceleration apparently ok. This can be fixed by reopening the config window (which shows Canvas Graphics Acceleration is on) and pressing OK. For a single instance as described above, it is possible to have lag on zoom by corruption of kritadisplayrc but it needs user action in the config window as far as I can tell from what I've just seen as described. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Rebecca Breu changed: What|Removed |Added CC||rebe...@rbreu.de --- Comment #46 from Rebecca Breu --- (In reply to Ahab Greybeard from comment #7) > I seem to have fixed this for the appimages on my PC. > > In kritadisplayrc, I had the line OpenGLRenderer=none > > [I must have previously been turning Canvas Graphics Acceleration on and off > to test another bug I'd been looking at. I assume I'd forgotten that a > restart is needed to implement this. > Note that the advisory statement "needs restart" looks like it only applies > to the Preferred Renderer but it applies to any change in those settings.] > > Setting the kritadisplayrc line OpenGLRenderer to be 'auto' or 'desktop' > clears the problem for me. > > Can you go to Settings -> Configure Krita -> Display , make sure Canvas > Graphics Acceleration is ticked and then press OK then restart krita? > > This setting does not cause any zoom-lag problems for version 4.2.6 or > 4.2.7.1 appimages. It affects 4.2.8 and the Dec09 4.3.0 prealpha appimages. I just ran into this problem (Debian, appimage) — suddenly zooming was super laggy on both 4.2.8 and 4.2.9 when it never had been before. Looking in "Settings -> Configure Krita -> Display", it said the renderer was "Auto (OpenGL)", but looking at my kritadisplayrc, OpenGLRenderer was set no none. Editing the file as Ahab said fixed the problem. I have no idea what caused the issue all of a sudden since I've never touched the display settings. The only setting that I changed recently was to allow several instances of Krita, and for the first time ever I was running two intances of Krita at the same time, and that's when I noticed the issue. So *maybe* accessing configs concurrently screwed something up, but I haven't been able to reproduce it so far. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #45 from Alex Mandrei --- (In reply to Alex Mandrei from comment #44) > (In reply to Alex Mandrei from comment #43) > > As with the update for the Krita 4.2.9(i was using the previous version > > before updating) the zooming is choppy ,it freezes anytime I zoom by holding > > control and drag.Zooming works fine by using the navigator docker or by > > using my mouse wheel.I didn't not experience such thing in the previous > > version(s). > > I'm new to this and i don't know what further information i should add:) > > > > There my system info > > Krita > > > > Version: 4.2.9 > > Languages: en_US, en > > Hidpi: true > > > > Qt > > > > Version (compiled): 5.12.7 > > Version (loaded): 5.12.7 > > > > OS Information > > > > Build ABI: x86_64-little_endian-llp64 > > Build CPU: x86_64 > > CPU: x86_64 > > Kernel Type: winnt > > Kernel Version: 10.0.18362 > > Pretty Productname: Windows 10 (10.0) > > Product Type: windows > > Product Version: 10 > > > > OpenGL Info > > > > Vendor: "NVIDIA Corporation" > > Renderer: "GeForce 410M/PCIe/SSE2" > > Version: "4.5.0 NVIDIA 382.05" > > Shading language: "4.50 NVIDIA" > > Requested format: QSurfaceFormat(version 2.0, options > > QFlags(), depthBufferSize -1, redBufferSize > > -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, > > stencilBufferSize -1, samples -1, swapBehavior > > QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace > > QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) > > Current format:QSurfaceFormat(version 4.5, options > > QFlags(DeprecatedFunctions), depthBufferSize > > 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, > > stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer, > > swapInterval 1, colorSpace QSurfaceFormat::sRGBColorSpace, profile > > QSurfaceFormat::CompatibilityProfile) > > Version: 4.5 > > Supports deprecated functions true > > is OpenGL ES: false > > > > QPA OpenGL Detection Info > > supportsDesktopGL: true > > supportsAngleD3D11: true > > isQtPreferAngle: false > > > > Hardware Information > > > > GPU Acceleration: none > > Memory: 4077 Mb > > Number of Cores: 4 > > Swap Location: C:/Users/molne/AppData/Local/Temp > > > > Current Settings > > > > Current Swap Location: C:/Users/molne/AppData/Local/Temp > > Undo Enabled: 1 > > Undo Stack Limit: 30 > > Use OpenGL: 0 > > Use OpenGL Texture Buffer: 1 > > Use AMD Vectorization Workaround: 1 > > Canvas State: OPENGL_SUCCESS > > Autosave Interval: 900 > > Use Backup Files: 1 > > Number of Backups Kept: 1 > > Backup File Suffix: ~ > > Backup Location: Same Folder as the File > > Use Win8 Pointer Input: 0 > > Use RightMiddleTabletButton Workaround: 0 > > Levels of Detail Enabled: 0 > > Use Zip64: 0 > > > > > > Display Information > > Number of screens: 1 > > Screen: 0 > > Name: \\.\DISPLAY1 > > Depth: 32 > > Scale: 1 > > Resolution in pixels: 1680x1050 > > Manufacturer: > > Model: > > Refresh Rate: 60 > > Additional info ,i'm using a One by Wacom tablet(not the new Wacom one > display) and i have the latest drivers installed! I just tried some new settings and ,i enabled canvas acceleration and i put the by angle renderer and it works better now,it doesnt freezes anymore for like 5 seconds anytime i zoom but just zooms very laggy,like,it goes in laggy steps ,it s usable now tho but still bad.. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #44 from Alex Mandrei --- (In reply to Alex Mandrei from comment #43) > As with the update for the Krita 4.2.9(i was using the previous version > before updating) the zooming is choppy ,it freezes anytime I zoom by holding > control and drag.Zooming works fine by using the navigator docker or by > using my mouse wheel.I didn't not experience such thing in the previous > version(s). > I'm new to this and i don't know what further information i should add:) > > There my system info > Krita > > Version: 4.2.9 > Languages: en_US, en > Hidpi: true > > Qt > > Version (compiled): 5.12.7 > Version (loaded): 5.12.7 > > OS Information > > Build ABI: x86_64-little_endian-llp64 > Build CPU: x86_64 > CPU: x86_64 > Kernel Type: winnt > Kernel Version: 10.0.18362 > Pretty Productname: Windows 10 (10.0) > Product Type: windows > Product Version: 10 > > OpenGL Info > > Vendor: "NVIDIA Corporation" > Renderer: "GeForce 410M/PCIe/SSE2" > Version: "4.5.0 NVIDIA 382.05" > Shading language: "4.50 NVIDIA" > Requested format: QSurfaceFormat(version 2.0, options > QFlags(), depthBufferSize -1, redBufferSize > -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, > stencilBufferSize -1, samples -1, swapBehavior > QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace > QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) > Current format:QSurfaceFormat(version 4.5, options > QFlags(DeprecatedFunctions), depthBufferSize > 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, > stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer, > swapInterval 1, colorSpace QSurfaceFormat::sRGBColorSpace, profile > QSurfaceFormat::CompatibilityProfile) > Version: 4.5 > Supports deprecated functions true > is OpenGL ES: false > > QPA OpenGL Detection Info > supportsDesktopGL: true > supportsAngleD3D11: true > isQtPreferAngle: false > > Hardware Information > > GPU Acceleration: none > Memory: 4077 Mb > Number of Cores: 4 > Swap Location: C:/Users/molne/AppData/Local/Temp > > Current Settings > > Current Swap Location: C:/Users/molne/AppData/Local/Temp > Undo Enabled: 1 > Undo Stack Limit: 30 > Use OpenGL: 0 > Use OpenGL Texture Buffer: 1 > Use AMD Vectorization Workaround: 1 > Canvas State: OPENGL_SUCCESS > Autosave Interval: 900 > Use Backup Files: 1 > Number of Backups Kept: 1 > Backup File Suffix: ~ > Backup Location: Same Folder as the File > Use Win8 Pointer Input: 0 > Use RightMiddleTabletButton Workaround: 0 > Levels of Detail Enabled: 0 > Use Zip64: 0 > > > Display Information > Number of screens: 1 > Screen: 0 > Name: \\.\DISPLAY1 > Depth: 32 > Scale: 1 > Resolution in pixels: 1680x1050 > Manufacturer: > Model: > Refresh Rate: 60 Additional info ,i'm using a One by Wacom tablet(not the new Wacom one display) and i have the latest drivers installed! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Alex Mandrei changed: What|Removed |Added CC||mandrei.a...@gmail.com --- Comment #43 from Alex Mandrei --- As with the update for the Krita 4.2.9(i was using the previous version before updating) the zooming is choppy ,it freezes anytime I zoom by holding control and drag.Zooming works fine by using the navigator docker or by using my mouse wheel.I didn't not experience such thing in the previous version(s). I'm new to this and i don't know what further information i should add:) There my system info Krita Version: 4.2.9 Languages: en_US, en Hidpi: true Qt Version (compiled): 5.12.7 Version (loaded): 5.12.7 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.18362 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce 410M/PCIe/SSE2" Version: "4.5.0 NVIDIA 382.05" Shading language: "4.50 NVIDIA" Requested format: QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize -1, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) Current format:QSurfaceFormat(version 4.5, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::sRGBColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.5 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsAngleD3D11: true isQtPreferAngle: false Hardware Information GPU Acceleration: none Memory: 4077 Mb Number of Cores: 4 Swap Location: C:/Users/molne/AppData/Local/Temp Current Settings Current Swap Location: C:/Users/molne/AppData/Local/Temp Undo Enabled: 1 Undo Stack Limit: 30 Use OpenGL: 0 Use OpenGL Texture Buffer: 1 Use AMD Vectorization Workaround: 1 Canvas State: OPENGL_SUCCESS Autosave Interval: 900 Use Backup Files: 1 Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Use Win8 Pointer Input: 0 Use RightMiddleTabletButton Workaround: 0 Levels of Detail Enabled: 0 Use Zip64: 0 Display Information Number of screens: 1 Screen: 0 Name: \\.\DISPLAY1 Depth: 32 Scale: 1 Resolution in pixels: 1680x1050 Manufacturer: Model: Refresh Rate: 60 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #42 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #38) I contacted the xp-pen devs and they can't find anything wrong on their end right now. Their tests were fine without the issue. One more thing from my end, I tried to open the log viewer docker, turned it on and hit ctrl+shift+T to turn on logging and if I use zoom at any level it immediately freezes for seconds, the logging stops too (in the youtube video previously you could see Krita freezing at around 15% zoom and when zooming in very close to 3000% but now the same happenes at any zoom event no matter the %). The log windows stops until the whole Krita unfreezes. There's something that is I guess resolving and it doesn't let the Krita's loop to continue until it's done? (with the loger on, again it doesn't happen with mouse but only with pen, in the previous version with the logger it's fine - well the logging turned on is a little bit choppy but nothing compared to the complete freeze from 4.2.8 and currently from the 4.2.9 nightly builds) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #41 from lemp...@gmail.com --- Actually I was wrong. Egh. I apologize. It's still there. The drivers just go bonkers if I change the display settings. Sorry my bad, is there a way to delete comments here on kde? The latest info from me is: The problem is still there, xp-pen so far can't find a reason why it's a problem with drivers. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #40 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #38) > Well, there was a change in timing of the compressed tablet events. But I > don't know why I cannot reproduce it here. I think we can lock this bug as solved. I've found how to get rid of this problem on my end. I don't know what particularly causes this if it's drivers from xp-pen or if it's something in windows or if it's something in nvidia drivers but here I am having no problem any more. Now the "solution/fix" is strange so brace yourself :0. I have 3 screens, setup in windows is in a row as this: 3 - 1 - 2 (1 - main display, 2 - pen display, 3 - another screen). If I change this setting to literally any other then the problem disappears (basically as long as the pen display is not set as the most to the right everything works just fine). I've tried different set ups such as: 3 - 2 - 1, 3 - 1 + 2 below 1, 3 - 1|2 (sharing one desktop for 1 and 2) - all work just fine. I did not try all options but so far pen display on the far right is the one that creates this problem. I'm so sorry I bother you with this for so long, I literally had no idea that this could cause such a trouble especially considering how it doesn't work just in one position and considering it doesn't work only in krita 4.2.8 and above (this still confuses me, it's really strange it depends on Krita version too). The xp-pen so far couldn't properly reproduce it (well they said they had problem just once but then it did not appear again) but I found this out today so I sent them a new e-mail describing this so I assume they might check this some time later (if at all). Once more I apologize, it's just baffling how it works before 4.2.8 and how in 4.2.8 and later. :-? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #39 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #38) > Well, there was a change in timing of the compressed tablet events. But I > don't know why I cannot reproduce it here. I wish I could do more, I just don't know what if there's even anything for me to do to help out. Maybe if the others with the same problem could let us know if they still having issues or not, but felix had the same problem with freeze and he is on hp laptop I'm guessing it's a convertible so I don't think he has xp-pen. Anyway I let the xp-pen know about this and asked them if they can look into it today, I can't promise anything but I'll see what answer they will give me. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #38 from Dmitry Kazakov --- Well, there was a change in timing of the compressed tablet events. But I don't know why I cannot reproduce it here. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #37 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #36) > Hm... I still can reproduce it only with Instant Preview on. But no slowdown > is visible in Instant Preview mode off. And looking at the video it looks > like the problem on the reporter's computer is not related to IP, because it > also visible on 3000%+ zooms, which is when IP is disabled. > > I have a feeling that it is XP-PEN related. Here I use Wacom for testing. Yeah I thought about it too but I'm still not sure because it's perfectly ok in the previous version of Krita on the same device with the same drivers, isn't that a bit strange if there was no change in krita to this that it works in 4.2.7 but doesn't work properly in 4.2.8? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #36 from Dmitry Kazakov --- Hm... I still can reproduce it only with Instant Preview on. But no slowdown is visible in Instant Preview mode off. And looking at the video it looks like the problem on the reporter's computer is not related to IP, because it also visible on 3000%+ zooms, which is when IP is disabled. I have a feeling that it is XP-PEN related. Here I use Wacom for testing. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #35 from lemp...@gmail.com --- Created attachment 126582 --> https://bugs.kde.org/attachment.cgi?id=126582=edit Sys info from 3.3.2020 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #34 from lemp...@gmail.com --- Created attachment 126581 --> https://bugs.kde.org/attachment.cgi?id=126581=edit Log report bug 430 from 3.3.2020 I had to close an start krita again after recording before I had this log generated so the last log is from after recording and the session before that is from the recording. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #33 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #32) > Looks like the link got outdated: > https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ > > > Though you can use yesterday's package if it is more convenient. Ok, I've made a screen recording with the version you've linked above. https://youtu.be/R9eXihWZr0A Here's the videos description (it's also in the description on youtube). At the bottom of the screen shortcuts can be seen. Choppy zoom is not a bad recording, the zoom icon is a good description of how smooth the video recording is. Anytime the cursor stops for a while when the zoom stops I release the pen (the zoom icon stays until it unfreezes itself after a while). Instant preview mode was turned off for the whole time. Shows both drivers options for windows (win tab and win ink). Notice how fps completely freeze or significantly drop sometimes freeze at 0 sometimes at 100+ fps. To show the difference you can see three options of zoom: 1. ctrl + num+/ ctrl + num- (zooming in steps without using pen works just fine): 00:08, 02:35 2. ctrl + space with pen: 00:16, 02:45 3. ctrl + space with mouse (here the shortcut can't be seen on screen but it's the only time when the zoom is smooth in the recording): 01:13, 03:40 I'll add the bug report logs in a moment. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #32 from Dmitry Kazakov --- Looks like the link got outdated: https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ Though you can use yesterday's package if it is more convenient. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #31 from lemp...@gmail.com --- Created attachment 126579 --> https://bugs.kde.org/attachment.cgi?id=126579=edit Krita 430 prealpha sys info log -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #30 from lemp...@gmail.com --- Created attachment 126578 --> https://bugs.kde.org/attachment.cgi?id=126578=edit 430-prealpha bug report log (In reply to Dmitry Kazakov from comment #29) > Hmmm.. sounds really weird. > > Can you make a screen recording for this specific build of Krita and attach > the log generated by this version? > https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ > lastSuccessfulBuild/artifact/krita-nightly-x64-v4.3.0-prealpha-1279- > g4c27cab0d6.zip > > Does it also make any difference when you switch between ANGLE and openGL > renderers in display settings (needs restart)? The link doesn't work (err: not found). For no I tried yesterday's build you provided the link to 4.3.0 pre-alpha. I attached 2 documents from help (bug report + sys info). If you could pls confirm whether the link you provided today works or not I'll make a recording and attach bug reports from that version too. OpenGL vs Angle renderer makes no difference (I did restart). The only difference so far is when I switch between win tab and win ink in tablet drivers in krita configuration, so far I haven't found other differences. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #29 from Dmitry Kazakov --- Hmmm.. sounds really weird. Can you make a screen recording for this specific build of Krita and attach the log generated by this version? https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/lastSuccessfulBuild/artifact/krita-nightly-x64-v4.3.0-prealpha-1279-g4c27cab0d6.zip Does it also make any difference when you switch between ANGLE and openGL renderers in display settings (needs restart)? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #28 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #27) > Hi, lempikq! > > Could you recheck if the problem appears with Instant Preview **disabled**? > > I have tested on my builds on both Linux and Windows and the results are > consistent: > > 1) Krita-master + Instant Preview -> Light hiccups. > 2) Krita-4.2 + Instant Preview -> Heavy hiccups. > 3) Krita-master + Instant Preview disabled -> works fine > 3) Krita-4.2 + Instant Preview disabled -> works fine Hi to you too :). I don't use instant preview the results were with instant preview turned off. I did check it just in case I believe I mentioned it in one of the descriptions above but to be sure, instant preview makes things worse ;). With instant preview mode if I'm at 100% zoom and try to zoom out it freezes at 50% already, basically about every 25%. I'd love to give you more information I just don't know what else it could be, so far I still use 4.2.7 because that works flawlessly for me. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #27 from Dmitry Kazakov --- Hi, lempikq! Could you recheck if the problem appears with Instant Preview **disabled**? I have tested on my builds on both Linux and Windows and the results are consistent: 1) Krita-master + Instant Preview -> Light hiccups. 2) Krita-4.2 + Instant Preview -> Heavy hiccups. 3) Krita-master + Instant Preview disabled -> works fine 3) Krita-4.2 + Instant Preview disabled -> works fine -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #26 from lemp...@gmail.com --- I've made a mistake in my description about drivers. It seems I messed up when enabling disabling win ink in my tablets drivers (not in krita only in the driver app), I wasn't sure how Krita and the drive app interprets it if I disable win ink in the driver's app (confusion came out because pen still worked). So when I said everything is smooth with ink but pressure doesn't work that was a mistake. At this time win ink was disabled in my driver's app and from what tiar told me Krita registered my pen as a mouse instead. I assume because as stated before zooming with mouse works just fine so when win ink is set in krita but disabled in drivers it results in krita defaulting to mouse events only even for pen (so pen pressure with win ink works). To sum it up, zoom is stuttering with both win tab and win ink, it freezes several seconds if both zoomed out or in a lot (10-20% and about 800% or more) if I release the pen and let Krita do it's processing after several seconds it gets to max zoom out (5%) if I want to zoom back in it freezes again at about 10%, I have to release the pen, wait and then after krita finishes processing I can zoom in more. The difference between Win Tab and Win Ink is that win ink in incredibly stuttering (it looks like it's 10-15 fps at best) and freezes way more. The slower I zoom out/in the less apparent the issues is (as described previously I can zoom out/in completely if I move my pen very slowly and I mean glacial slow it takes minutes to zoom out though so not a useful method ;0). To be clear in the 4.2.7 version both win tab and win ink work smoothly and just fine. I apologize for this one misinformation, after reading tiar's message just a moment ago I went to double check it that the issue is with both drivers options and it is, win ink is just way worse but neither is very usable unfortunately. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #25 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #24) > Hi, lempikq! > > Could you check if the bug is still reproducible in the very latest Krita > builds downloaded from here? > https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ > https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/ > > Or at least tell the exact version of nightly you tested on. Usually the > patch appears in the nightly builds on **the next** day after I push it to > master. And according to your message you tested on the same day. Usually it > means that you tested on a version without the patch applied... Hello, when it comes to my reply above I waited until the patch was included in the build to be sure. I just tested the build from the the link you provided (I also checked today's both Krita next and Krita plus from krita.org - download per -tiar-'s suggestion on reddit). All share the same problem for me. To be precise this issues occurs only when using pen as described in the previous posts, it does not happen if I use mouse or shortcuts (ctrl + '+' and ctrl + '-'). If needed I can make a recording tomorrow to showcase it again if the previous video isn't enough, I'm not sure if there's any logging related to this done but if you guide me I can provide it too. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #24 from Dmitry Kazakov --- Hi, lempikq! Could you check if the bug is still reproducible in the very latest Krita builds downloaded from here? https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/ Or at least tell the exact version of nightly you tested on. Usually the patch appears in the nightly builds on **the next** day after I push it to master. And according to your message you tested on the same day. Usually it means that you tested on a version without the patch applied... -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 lemp...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #23 from lemp...@gmail.com --- (In reply to RamonMiranda from comment #22) > I have been testing this and i have uploaded a video. Maybe helps maybe not. > https://drive.google.com/file/d/1hx8kwHQKX_0qYFXD55Sq-LXt6kB9hvSY/ > view?usp=sharing > > > If you need more testing let me know please So I gave it one more try to check in comparison to your video and I found the difference. It's in tablet drivers inside Krita, if I switch to win ink then everything is smooth and works fine the problem is that pen pressure doesn't work for me like that, if I turn win ink in my pen displays application then the lag is so visible that I can barely zoom at any level, if I turn on win tab (which I usually have, while having win ink off in drivers) then I'm at the situation when it's a little bit choppy and freezes completely for several seconds at about 10-5% zoom (if zoomed out quickly, Krita shows the zoom bar changing like it's processing something for long until it changes zoom levels at these levels of zoom). I checked the same settings in the previous version 4.2.7 and everything is perfectly smooth so I don't think my pen tablet's drivers are the cause here but something has changed in Krita or is it possible for being it my drivers although they are fine in all previous versions in the past 2.5 years (same machine)? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 RamonMiranda changed: What|Removed |Added CC||mirandagrap...@gmail.com --- Comment #22 from RamonMiranda --- I have been testing this and i have uploaded a video. Maybe helps maybe not. https://drive.google.com/file/d/1hx8kwHQKX_0qYFXD55Sq-LXt6kB9hvSY/view?usp=sharing If you need more testing let me know please -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #21 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #20) > Git commit 06cb53798c1c6ac69d28b3d280b86513424c6923 by Dmitry Kazakov. > Committed on 31/01/2020 at 14:14. > Pushed by dkazakov into branch 'krita/4.2'. > > Fix hiccups when doing canvas actions > > Fixed KisSignalCompressor became too precise and tries to keep > the interval too hard. Sometimes the signal handler is too slow, in > such cases we should still give some time for event loop to execute. > > To achieve that, KisSignalCompressor now has an additional operational > mode: "additive interval mode". When this mode is active, then interval > time is counted from the moment, when the execution path is returned from > the signal handler. In "precise interval mode" (default), in reverse, the > interval is counted from the moment, when start() signal arrives. > Related: bug 415773 > CC:kimages...@kde.org > > M +23 -3libs/global/kis_signal_compressor.cpp > M +7-0libs/global/kis_signal_compressor.h > M +36 -4libs/global/tests/KisSignalCompressorTest.cpp > M +2-0libs/global/tests/KisSignalCompressorTest.h > M +3-1libs/ui/input/kis_input_manager_p.cpp > > https://invent.kde.org/kde/krita/commit/ > 06cb53798c1c6ac69d28b3d280b86513424c6923 I tried Krita Plus (31.1.2020) with the fix included. The instant preview mode is more or less on par with 4.2.7.1 (I'd say it's still choppier). When instant preview mode is off the zoom is still not as smooth as it was in 4.2.7.1 and it still freezes for several seconds if I zoom above 25% (usually at about ~12-10%), it's way better then it was but when I compare both versions the 4.2.7.1 is a really smooth ride without any hiccups while the current fix is still a bit choppy and freezes. To be precise the freeze doesn't happen if you zoom out very slowly and I mean glacial slow, my hand barely moves, then it doesn't freeze but it takes me half a minute to zoom out at this speed. I'm sorry, considering this was resolved with the fix, to suggest there might be something more to open it again? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Dmitry Kazakov changed: What|Removed |Added Latest Commit|https://invent.kde.org/kde/ |https://invent.kde.org/kde/ |krita/commit/0ca332c7089c69 |krita/commit/06cb53798c1c6a |0a62c6d7b66515fe9aacdabbdb |c69d28b3d280b86513424c6923 --- Comment #20 from Dmitry Kazakov --- Git commit 06cb53798c1c6ac69d28b3d280b86513424c6923 by Dmitry Kazakov. Committed on 31/01/2020 at 14:14. Pushed by dkazakov into branch 'krita/4.2'. Fix hiccups when doing canvas actions Fixed KisSignalCompressor became too precise and tries to keep the interval too hard. Sometimes the signal handler is too slow, in such cases we should still give some time for event loop to execute. To achieve that, KisSignalCompressor now has an additional operational mode: "additive interval mode". When this mode is active, then interval time is counted from the moment, when the execution path is returned from the signal handler. In "precise interval mode" (default), in reverse, the interval is counted from the moment, when start() signal arrives. Related: bug 415773 CC:kimages...@kde.org M +23 -3libs/global/kis_signal_compressor.cpp M +7-0libs/global/kis_signal_compressor.h M +36 -4libs/global/tests/KisSignalCompressorTest.cpp M +2-0libs/global/tests/KisSignalCompressorTest.h M +3-1libs/ui/input/kis_input_manager_p.cpp https://invent.kde.org/kde/krita/commit/06cb53798c1c6ac69d28b3d280b86513424c6923 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Dmitry Kazakov changed: What|Removed |Added Latest Commit||https://invent.kde.org/kde/ ||krita/commit/0ca332c7089c69 ||0a62c6d7b66515fe9aacdabbdb Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #18 from Dmitry Kazakov --- Git commit 0ca332c7089c690a62c6d7b66515fe9aacdabbdb by Dmitry Kazakov. Committed on 31/01/2020 at 14:06. Pushed by dkazakov into branch 'master'. Fix hiccups when doing canvas actions Fixed KisSignalCompressor became too precise and tries to keep the interval too hard. Sometimes the signal handler is too slow, in such cases we should still give some time for event loop to execute. To achieve that, KisSignalCompressor now has an additional operational mode: "additive interval mode". When this mode is active, then interval time is counted from the moment, when the execution path is returned from the signal handler. In "precise interval mode" (default), in reverse, the interval is counted from the moment, when start() signal arrives. Related: bug 415773 CC:kimages...@kde.org M +23 -3libs/global/kis_signal_compressor.cpp M +7-0libs/global/kis_signal_compressor.h M +36 -4libs/global/tests/KisSignalCompressorTest.cpp M +2-0libs/global/tests/KisSignalCompressorTest.h M +3-1libs/ui/input/kis_input_manager_p.cpp https://invent.kde.org/kde/krita/commit/0ca332c7089c690a62c6d7b66515fe9aacdabbdb --- Comment #19 from Dmitry Kazakov --- Git commit 2fea6a9b28f5e9ec90cd06f5bbc79c7ef8e40ca2 by Dmitry Kazakov. Committed on 31/01/2020 at 14:06. Pushed by dkazakov into branch 'master'. Implement KisRegion with optimized rects compression The patch fixes two bugs: 1) Freezes when zooming with Intant Preview enabled. The freezes happened due to a very long QRegion calculation in KisSyncLodCacheStrokeStrategy::createJobsData(). Now KisRegion does the calculation 50 times fister. 2) Short 200ms delay in the end of every stroke in KisIndirectPaintingSupport::writeMergeData(). What is KisRegion? The main difference between KisRegion and QRegion is that KisRegion, once created, doesn't allow adding/removing rectangles. It lets us use optimized algorithm for merging rectanges, which is 50-100 times faster than iterational algorithm used in QRegion. When to use KisRegion? By default, use KisRegion. If you need any boolean operation not supported by KisRegion, then use QRegion. KisRegion can be converted to/from QRegion via toQRegion() and fromQRegion() calls. NOTE: these conversion were intentionally made explicit, *not* implicit, because accidental use of QRegion may affect performance significantly. M +1-0libs/global/CMakeLists.txt A +204 -0libs/global/KisRegion.cpp [License: GPL (v2+)] A +98 -0libs/global/KisRegion.h [License: GPL (v2+)] M +1-1libs/image/kis_datamanager.h M +0-1libs/image/kis_image.cc M +0-1libs/image/kis_image.h M +1-1libs/image/kis_image_animation_interface.cpp M +2-1libs/image/kis_image_animation_interface.h M +0-1libs/image/kis_layer.h M +2-1libs/image/kis_node.cpp M +2-1libs/image/kis_node.h M +13 -15 libs/image/kis_paint_device.cc M +6-9libs/image/kis_paint_device.h M +3-3libs/image/kis_paint_device_cache.h M +2-2libs/image/kis_paint_device_strategies.h M +1-1libs/image/kis_perspectivetransform_worker.cpp M +3-3libs/image/kis_perspectivetransform_worker.h M +1-1libs/image/kis_processing_applicator.cpp M +4-4libs/image/kis_regenerate_frame_stroke_strategy.cpp M +3-1libs/image/kis_regenerate_frame_stroke_strategy.h M +1-1libs/image/kis_selection_based_layer.h M +3-3libs/image/kis_suspend_projection_updates_stroke_strategy.cpp M +1-1libs/image/kis_sync_lod_cache_stroke_strategy.cpp M +10 -14 libs/image/krita_utils.cpp M +4-2libs/image/krita_utils.h M +1-0libs/image/lazybrush/kis_lazy_fill_capacity_map.h M +3-4libs/image/lazybrush/kis_lazy_fill_graph.h M +2-1libs/image/lazybrush/kis_multiway_cut.cpp M +2-2libs/image/tests/kis_image_animation_interface_test.cpp M +3-8libs/image/tests/kis_lazy_brush_test.cpp M +0-15 libs/image/tests/kis_node_test.cpp M +0-1libs/image/tests/kis_node_test.h M +3-3libs/image/tests/kis_paint_device_test.cpp M +5-4libs/image/tiles3/kis_tiled_data_manager.cc M +2-2libs/image/tiles3/kis_tiled_data_manager.h M +52 -0libs/image/tiles3/tests/kis_tiled_data_manager_test.cpp M +3-0
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Dmitry Kazakov changed: What|Removed |Added Latest Commit||https://invent.kde.org/kde/ ||krita/commit/0ca332c7089c69 ||0a62c6d7b66515fe9aacdabbdb Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #18 from Dmitry Kazakov --- Git commit 0ca332c7089c690a62c6d7b66515fe9aacdabbdb by Dmitry Kazakov. Committed on 31/01/2020 at 14:06. Pushed by dkazakov into branch 'master'. Fix hiccups when doing canvas actions Fixed KisSignalCompressor became too precise and tries to keep the interval too hard. Sometimes the signal handler is too slow, in such cases we should still give some time for event loop to execute. To achieve that, KisSignalCompressor now has an additional operational mode: "additive interval mode". When this mode is active, then interval time is counted from the moment, when the execution path is returned from the signal handler. In "precise interval mode" (default), in reverse, the interval is counted from the moment, when start() signal arrives. Related: bug 415773 CC:kimages...@kde.org M +23 -3libs/global/kis_signal_compressor.cpp M +7-0libs/global/kis_signal_compressor.h M +36 -4libs/global/tests/KisSignalCompressorTest.cpp M +2-0libs/global/tests/KisSignalCompressorTest.h M +3-1libs/ui/input/kis_input_manager_p.cpp https://invent.kde.org/kde/krita/commit/0ca332c7089c690a62c6d7b66515fe9aacdabbdb -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Boudewijn Rempt changed: What|Removed |Added Keywords||release_blocker -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #17 from aferguson1...@gmail.com --- I think that I should make clear that this ONLY happens for me if I'm using the pen to zoom. I have MMB mapped to a pen button and the modifier mapped to a tablet button, that being an Intuos Pro. The same combination with the mouse and keyboard rather than pen and tablet works fine. In the mean time I'm sticking with 4.2.7 until this all gets worked out though I'll reinstall 4.2.8 too test theories posted in this thread. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #16 from Felix --- In my case I have to say, that the problem is not as big as it was at the beginning, but I have checked it, and in fact this is not repeated in Krita 4.2.7. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #15 from Felix --- HI, I don't know if something was changed, but in my case the reason I made the post is almost gone. Now at least the zoom is already usable. But in effect, as Lempikq comments, it still gets stuck when instant preview is used, and only if the canvas is more than 1000 pixels or so. The user interface in my case does not seem to affect me, it works the same in full screen as without it. By the way, I tried it in 3.0, although the 2.8 worked the same for me. Greetings. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #14 from lemp...@gmail.com --- (In reply to Dmitry Kazakov from comment #12) > Hi, Felix! > > Could you please check if you have View->Instant Preview enabled? This > option is the only way how I can reproduce the behavior you describe. Heya, hope it's fine to join the conversation here. For me it's like this: Krita 4.2.7.1 With instant preview mode turned on it gets really "laggy", interesting point it depends on how large the canvas is, for example (a new empty - only a base flat bg color layer) 500x500 [px] canvas is smooth but 5000x5000 [px] is jerking hard. If I turn the instant preview mode off everything is smooth no matter the size. Krita 4.2.8 Here it gets a bit complicated. Influence have: 1. UI visibility 2. Instant preview mode 3. Canvas size 1. Huge impact makes how much of the UI is visible on screen (in full screen mode with zero UI the zooming is the smoothest (still jerky but it's like a video game which usually is smooth at 60fps but now you are at 24fps so it works but definitely not what it should be and you can see that it's jerky) 2. Instant preview mode makes everything worse and significantly. Especially at levels of zoom: 25%, 50%, at these points it always freezes for a few seconds. 3. 500x500 px is smooth (to use the game analogy again: not 60 fps game but we are at about 30fps) while 5000x5000 is definitely not smooth (hard jerk zoom, in game it would be like 3fps). All the 3 points above have the problem with completely freezing Krita from 25% zoom level and above (usually about 10% it freezes for several seconds). I tried making a video but there are some problems with new OBS update and I'm not even sure if it would even help you (?). I can definitely say that for me surprisingly UI makes a huge difference in 4.2.8, even in fullscreen mode if I leave only the top bar on it adds a significant lag to the zoom comparing it to a fullscreen mode without any UI elements. Just to be precise with the game analogy when I say that 4.2.7.1 is smooth I mean it would be a game with 60fps or more while smooth in 4.2.8 never gets to that level as far as I can tell. I hope this will be helpful, I can test anything needed if it helps. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #13 from aferguson1...@gmail.com --- (In reply to Dmitry Kazakov from comment #12) > Hi, Felix! > > Could you please check if you have View->Instant Preview enabled? This > option is the only way how I can reproduce the behavior you describe. I did not have Instant Preview enabled. I tried it both ways and having it enabled or disabled seems to have no effect on the zoom issue. It's still there either way. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #12 from Dmitry Kazakov --- Hi, Felix! Could you please check if you have View->Instant Preview enabled? This option is the only way how I can reproduce the behavior you describe. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Boudewijn Rempt changed: What|Removed |Added CC||b...@valdyas.org Platform|Windows CE |MS Windows OS|Windows CE |MS Windows -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #11 from lemp...@gmail.com --- Sorry, I don't know how to delete comments here. I take my comment above about it being fine back. I misplaced old files in a new folder. I apologize for the comment above. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #10 from lemp...@gmail.com --- I'm not sure what changed but right now the latest 4.2.8 is fine for me. both krita plus as well as a regular download version (I downloaded both today). I had some problems with the previous version so I deleted some krita files in locals and let krita create them anew but then I replaced them with the old ones which I backed so I don't thing that would change anything. Is the new version fixed or did something magically change on my end? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Tymond changed: What|Removed |Added CC||sebastianl...@hotmail.com --- Comment #9 from Tymond --- *** Bug 415479 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #8 from aferguson1...@gmail.com --- (In reply to Ahab Greybeard from comment #7) > I seem to have fixed this for the appimages on my PC. > > In kritadisplayrc, I had the line OpenGLRenderer=none > > [I must have previously been turning Canvas Graphics Acceleration on and off > to test another bug I'd been looking at. I assume I'd forgotten that a > restart is needed to implement this. > Note that the advisory statement "needs restart" looks like it only applies > to the Preferred Renderer but it applies to any change in those settings.] > > Setting the kritadisplayrc line OpenGLRenderer to be 'auto' or 'desktop' > clears the problem for me. > > Can you go to Settings -> Configure Krita -> Display , make sure Canvas > Graphics Acceleration is ticked and then press OK then restart krita? > > This setting does not cause any zoom-lag problems for version 4.2.6 or > 4.2.7.1 appimages. It affects 4.2.8 and the Dec09 4.3.0 prealpha appimages. Reinstalled 4.2.8 to see if this worked. The Checkbox for Canvas Graphics Acceleration was already ticked since it was in the previous version and the new installation didn't overwrite the setting. OpenGLRenderer was set to desktop. With these settings the problem was still there. Changing OpenGLRenderer to auto made a slight improvement but it was still unusable. Instead of taking two seconds to react it only took one. Unfortunately this setting was the best of all available since all the other choices are either as bad or worse. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #7 from Ahab Greybeard --- I seem to have fixed this for the appimages on my PC. In kritadisplayrc, I had the line OpenGLRenderer=none [I must have previously been turning Canvas Graphics Acceleration on and off to test another bug I'd been looking at. I assume I'd forgotten that a restart is needed to implement this. Note that the advisory statement "needs restart" looks like it only applies to the Preferred Renderer but it applies to any change in those settings.] Setting the kritadisplayrc line OpenGLRenderer to be 'auto' or 'desktop' clears the problem for me. Can you go to Settings -> Configure Krita -> Display , make sure Canvas Graphics Acceleration is ticked and then press OK then restart krita? This setting does not cause any zoom-lag problems for version 4.2.6 or 4.2.7.1 appimages. It affects 4.2.8 and the Dec09 4.3.0 prealpha appimages. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Tymond changed: What|Removed |Added CC||aferguson1...@gmail.com --- Comment #6 from Tymond --- *** Bug 415038 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Tymond changed: What|Removed |Added Keywords||regression -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #5 from viktorsla...@viksl.com --- For me the problem is the same be it pre-alpha 4.3.0 or latest 4.2.8.2 (both portable as far as I can tell it doesn't matter if it's portable or not with the current 4.2.8 stable). Just curious but is anyone working on this or is it a niche thing? Just to know if any future Krita versions will be usable for me or not. Thanks ;0. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Ahab Greybeard changed: What|Removed |Added CC||ahab.greybe...@hotmail.co.u ||k --- Comment #4 from Ahab Greybeard --- With 4.2.8 Windows portable .zip on Windows 10, I do get this to some extent when using the stylus but not when using the mouse. With the Dec 05 4.3.0 prealpha Windows portable .zip on Windows 10, I don't see it much and the zoom is quite smooth. With the 4.2.8 appimage on Linux, I see quite bad zoom lag with the mouse and very bad zoom lag with the stylus. It's worse if you move the mouse or stylus quickly. When this happens, one core goes up to 100% load for about 10 seconds. (I can't get the latest 4.3.0 prealpha appimage due to ongoing problems with the kde nightly build download site.) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #3 from viktorsla...@viksl.com --- Created attachment 124220 --> https://bugs.kde.org/attachment.cgi?id=124220=edit Krita log file Here is a video I made showing how it works, my cellphone and computer screen have different frame rates so it looks smoother than it actually is but it is visible that zoom is not a smooth operation in the latest version (in reality it's significantly choppier). Link to video: https://youtu.be/tbN-7ACFNt8 Krita log file is attached, I turned the advanced logging on (all of it) but it did not create any files in log folder so I can't attach these. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 --- Comment #2 from viktorsla...@viksl.com --- Forgot a link to reddit where I started asking around with a short description from my observations (that's it for now until I post the video and bug report file). https://www.reddit.com/r/krita/comments/e3oben/428_problem_with_zoom_being_laggy_and_freezing/ -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 viktorsla...@viksl.com changed: What|Removed |Added CC||viktorsla...@viksl.com --- Comment #1 from viktorsla...@viksl.com --- I can confirm this, happens the same to me. I'm uploading a video so I'll later post a link. For me it's not random it's constantly there, freezes entire krita when zoomed out to about 10% (though in the video you will see it also happens when zoomed out to 30%). I'll post later. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Tymond changed: What|Removed |Added CC||tamtamy.tym...@gmail.com Status|REPORTED|ASSIGNED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 414576] Zoom failure in 4.2.8 but not in 4.2.7.
https://bugs.kde.org/show_bug.cgi?id=414576 Dmitry Kazakov changed: What|Removed |Added CC||dimul...@gmail.com Assignee|krita-bugs-n...@kde.org |dimul...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
