https://bugs.kde.org/show_bug.cgi?id=361448
Boudewijn Rempt <b...@valdyas.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Latest Commit|https://commits.kde.org/kri |https://commits.kde.org/kri
|ta/8739c93870f0ce63633402ce |ta/61bc0420ae078a0a7896722f
|b175cad9362fd4cf |25f6b643f3762b6e
--- Comment #21 from Boudewijn Rempt <b...@valdyas.org> ---
Git commit 61bc0420ae078a0a7896722f25f6b643f3762b6e by Boudewijn Rempt, on
behalf of Dmitry Kazakov.
Committed on 24/09/2018 at 07:05.
Pushed by rempt into branch 'krita/4.1'.
Fix delays in the end of Instant Preview rendering stroke
Needs your testing!
Test Plan:
1) Paint with complex brushes on Float32 images
2) Try painting many repetitive strokes, there should be no
flockering and no delays.
3) Try cancel your srokes before they are finished with Esc key.
Please note that the most dangerous moment is when Krita writes
"Updating..." right before background stroke calculation is
finished. Try pressing exactly at this moment! :)
Technical Details:
There was a short delay in the end of every Instant Preview
regeneration stroke. It was mostly seen on bigger canvases and
Float32-bitdepth mode.
The cause of this delay was the "update resume" stroke that
tried to upload the 100%-zoom image data to the canvas. Sometimes
such uploading could take up to 1.5 seconds, which could interfere
into the painter's workflow.
This patch does multiple things to mitigate this problem:
1) KisSuspendProjectionUpdatesStrokeStrategy is now suspendable
(again). It means that Krita will suspend the uploading process
if the user desides to paint further instead of waiting for the
background rendering to complete. This is the main part of this
patch.
2) On resuming Krita will not upload the entire image to the canvas,
but only a changed part. This is achieved by collecting dirty
requests in KisImage::enableUIUpdates(). This method itself doesn't
solve the initial problem, but it makes uploading a bit more efficient.
3) While the resume stroke is suspended, KisOpenGLCanvas2 blocks all the
synchronizations of tiles' mipmaps. It means that normal lodN strokes
will run with the mipmaps blocked. It is a bit dangerous approach, but
it works until KisSuspendProjectionUpdatesStrokeStrategy is the only
user of sigRequestLodPlanesSyncBlocked() signal.
CC:kimages...@kde.org
Fixes T2145
M +3 -3 libs/global/kis_pointer_utils.h
M +1 -0 libs/image/CMakeLists.txt
M +2 -2 libs/image/KisFakeRunnableStrokeJobsExecutor.cpp
M +1 -1 libs/image/KisFakeRunnableStrokeJobsExecutor.h
M +3 -3 libs/image/KisRunnableBasedStrokeStrategy.cpp
M +1 -1 libs/image/KisRunnableBasedStrokeStrategy.h
M +2 -2 libs/image/KisRunnableStrokeJobData.cpp
M +3 -3 libs/image/KisRunnableStrokeJobData.h
C +4 -11 libs/image/KisRunnableStrokeJobDataBase.cpp [from:
libs/image/KisRunnableStrokeJobsInterface.cpp - 070% similarity]
C +10 -13 libs/image/KisRunnableStrokeJobDataBase.h [from:
libs/image/KisRunnableStrokeJobsInterface.h - 058% similarity]
M +8 -8 libs/image/KisRunnableStrokeJobUtils.h
M +1 -1 libs/image/KisRunnableStrokeJobsInterface.cpp
M +9 -3 libs/image/KisRunnableStrokeJobsInterface.h
M +15 -1 libs/image/kis_image.cc
M +4 -21 libs/image/kis_image.h
M +1 -1 libs/image/kis_image_interfaces.h
M +8 -10 libs/image/kis_image_signal_router.cpp
M +34 -2 libs/image/kis_image_signal_router.h
M +0 -20 libs/image/kis_strokes_queue.cpp
M +292 -86 libs/image/kis_suspend_projection_updates_stroke_strategy.cpp
M +7 -2 libs/image/kis_suspend_projection_updates_stroke_strategy.h
M +37 -17 libs/ui/canvas/kis_canvas2.cpp
M +3 -2 libs/ui/canvas/kis_canvas2.h
M +5 -5 libs/ui/canvas/kis_update_info.cpp
M +6 -4 libs/ui/canvas/kis_update_info.h
M +1 -1 libs/ui/kis_animation_frame_cache.cpp
M +1 -1 libs/ui/opengl/kis_opengl_canvas2.cpp
M +3 -3 libs/ui/opengl/kis_opengl_image_textures.cpp
M +1 -1 libs/ui/opengl/kis_opengl_image_textures.h
M +3 -2 libs/ui/opengl/kis_texture_tile.cpp
M +1 -1 libs/ui/opengl/kis_texture_tile.h
https://commits.kde.org/krita/61bc0420ae078a0a7896722f25f6b643f3762b6e
--
You are receiving this mail because:
You are watching all bug changes.
