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.

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/

Created attachment 124220 [details]
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.

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.)

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.

*** Bug 415038 has been marked as a duplicate of this bug. ***

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.

(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.

*** Bug 415479 has been marked as a duplicate of this bug. ***

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?

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.

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.

(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.

(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.

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.

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.

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.

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:kimageshop@kde.org

M  +23   -3    libs/global/kis_signal_compressor.cpp
M  +7    -0    libs/global/kis_signal_compressor.h
M  +36   -4    libs/global/tests/KisSignalCompressorTest.cpp
M  +2    -0    libs/global/tests/KisSignalCompressorTest.h
M  +3    -1    libs/ui/input/kis_input_manager_p.cpp

https://invent.kde.org/kde/krita/commit/0ca332c7089c690a62c6d7b66515fe9aacdabbdb

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    -0    libs/global/CMakeLists.txt
A  +204  -0    libs/global/KisRegion.cpp     [License: GPL (v2+)]
A  +98   -0    libs/global/KisRegion.h     [License: GPL (v2+)]
M  +1    -1    libs/image/kis_datamanager.h
M  +0    -1    libs/image/kis_image.cc
M  +0    -1    libs/image/kis_image.h
M  +1    -1    libs/image/kis_image_animation_interface.cpp
M  +2    -1    libs/image/kis_image_animation_interface.h
M  +0    -1    libs/image/kis_layer.h
M  +2    -1    libs/image/kis_node.cpp
M  +2    -1    libs/image/kis_node.h
M  +13   -15   libs/image/kis_paint_device.cc
M  +6    -9    libs/image/kis_paint_device.h
M  +3    -3    libs/image/kis_paint_device_cache.h
M  +2    -2    libs/image/kis_paint_device_strategies.h
M  +1    -1    libs/image/kis_perspectivetransform_worker.cpp
M  +3    -3    libs/image/kis_perspectivetransform_worker.h
M  +1    -1    libs/image/kis_processing_applicator.cpp
M  +4    -4    libs/image/kis_regenerate_frame_stroke_strategy.cpp
M  +3    -1    libs/image/kis_regenerate_frame_stroke_strategy.h
M  +1    -1    libs/image/kis_selection_based_layer.h
M  +3    -3    libs/image/kis_suspend_projection_updates_stroke_strategy.cpp
M  +1    -1    libs/image/kis_sync_lod_cache_stroke_strategy.cpp
M  +10   -14   libs/image/krita_utils.cpp
M  +4    -2    libs/image/krita_utils.h
M  +1    -0    libs/image/lazybrush/kis_lazy_fill_capacity_map.h
M  +3    -4    libs/image/lazybrush/kis_lazy_fill_graph.h
M  +2    -1    libs/image/lazybrush/kis_multiway_cut.cpp
M  +2    -2    libs/image/tests/kis_image_animation_interface_test.cpp
M  +3    -8    libs/image/tests/kis_lazy_brush_test.cpp
M  +0    -15   libs/image/tests/kis_node_test.cpp
M  +0    -1    libs/image/tests/kis_node_test.h
M  +3    -3    libs/image/tests/kis_paint_device_test.cpp
M  +5    -4    libs/image/tiles3/kis_tiled_data_manager.cc
M  +2    -2    libs/image/tiles3/kis_tiled_data_manager.h
M  +52   -0    libs/image/tiles3/tests/kis_tiled_data_manager_test.cpp
M  +3    -0    libs/image/tiles3/tests/kis_tiled_data_manager_test.h
M  +1    -1    libs/ui/KisAsyncAnimationCacheRenderer.cpp
M  +1    -1    libs/ui/KisAsyncAnimationCacheRenderer.h
M  +1    -1    libs/ui/KisAsyncAnimationFramesSavingRenderer.cpp
M  +1    -1    libs/ui/KisAsyncAnimationFramesSavingRenderer.h
M  +4    -4    libs/ui/KisAsyncAnimationRendererBase.cpp
M  +4    -2    libs/ui/KisAsyncAnimationRendererBase.h
M  +3    -3    libs/ui/dialogs/KisAsyncAnimationRenderDialogBase.cpp
M  +3    -2    libs/ui/dialogs/KisAsyncAnimationRenderDialogBase.h
M  +1    -1    libs/ui/kis_animation_frame_cache.cpp
M  +2    -1    libs/ui/kis_animation_frame_cache.h
M  +1    -1    libs/ui/tests/KisFrameCacheStoreTest.cpp
M  +1    -1    libs/ui/tool/strokes/kis_painter_based_stroke_strategy.cpp
M  +3    -3    plugins/paintops/experiment/kis_experiment_paintop.cpp
M  +2    -1    plugins/paintops/experiment/kis_experiment_paintop.h
M  +3    -3    plugins/tools/basictools/strokes/move_selection_stroke_strategy.cpp

https://invent.kde.org/kde/krita/commit/2fea6a9b28f5e9ec90cd06f5bbc79c7ef8e40ca2

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:kimageshop@kde.org

M  +23   -3    libs/global/kis_signal_compressor.cpp
M  +7    -0    libs/global/kis_signal_compressor.h
M  +36   -4    libs/global/tests/KisSignalCompressorTest.cpp
M  +2    -0    libs/global/tests/KisSignalCompressorTest.h
M  +3    -1    libs/ui/input/kis_input_manager_p.cpp

https://invent.kde.org/kde/krita/commit/06cb53798c1c6ac69d28b3d280b86513424c6923

(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:kimageshop@kde.org
> 
> M  +23   -3    libs/global/kis_signal_compressor.cpp
> M  +7    -0    libs/global/kis_signal_compressor.h
> M  +36   -4    libs/global/tests/KisSignalCompressorTest.cpp
> M  +2    -0    libs/global/tests/KisSignalCompressorTest.h
> M  +3    -1    libs/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?

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

(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)?

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...

(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.

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.

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

(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.

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)?

Created attachment 126578 [details]
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.

Created attachment 126579 [details]
Krita 430 prealpha sys info log

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.

(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.

Created attachment 126581 [details]
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.

Created attachment 126582 [details]
Sys info from 3.3.2020

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.

(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?

Well, there was a change in timing of the compressed tablet events. But I don't know why I cannot reproduce it here.

(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.

(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. :-?

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.

(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)

  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<QSurfaceFormat::FormatOption>(), 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<QSurfaceFormat::FormatOption>(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

(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<QSurfaceFormat::FormatOption>(), 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<QSurfaceFormat::FormatOption>(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!

(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<QSurfaceFormat::FormatOption>(), 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<QSurfaceFormat::FormatOption>(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..

(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.

(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.

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<QSurfaceFormat::FormatOption>(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<QSurfaceFormat::FormatOption>(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

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.

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

(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!

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.

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    -2    libs/ui/KisView.cpp
M  +1    -1    libs/ui/KisViewManager.cpp
M  +28   -19   libs/ui/kis_zoom_manager.cc
M  +6    -1    libs/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

I think I can finally close this bug :)

(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

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    -2    libs/ui/KisView.cpp
M  +1    -1    libs/ui/KisViewManager.cpp
M  +28   -19   libs/ui/kis_zoom_manager.cc
M  +6    -1    libs/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

(In reply to Dmitry Kazakov from comment #54)
> I think I can finally close this bug :)

Omg,the zoom is 100000% 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?

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/

(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

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.

(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?

No, it's safe.

@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

Aright,thanks!Sorry for bothering:D

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    -2    libs/ui/KisView.cpp
M  +1    -1    libs/ui/KisViewManager.cpp
M  +28   -19   libs/ui/kis_zoom_manager.cc
M  +6    -1    libs/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

*** Bug 416893 has been marked as a duplicate of this bug. ***