Bug 415106 - Popup palette colour history is not updated if paint stroke is started soon after closure
Summary: Popup palette colour history is not updated if paint stroke is started soon ...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Color Selectors (show other bugs)
Version: 4.2.8
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-12 19:19 UTC by Ahab Greybeard
Modified: 2020-06-09 22:06 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Popup Palette colour history failure - example (136.86 KB, image/png)
2019-12-12 19:19 UTC, Ahab Greybeard
Details
Low delay paint stroke gives no history update (136.64 KB, image/png)
2019-12-13 09:07 UTC, Ahab Greybeard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ahab Greybeard 2019-12-12 19:19:11 UTC
Created attachment 124453 [details]
Popup Palette colour history failure - example

SUMMARY
This has been seen on the 4.2.8 and 4.3.0 Dec 09 prealpha appimages and the 4.3.0 Dec 10 prealpha Windows portable zip.

I've tried in on the 4.2.6 and 4.2.7.1 appimages and not seen it happen but it's intermittent.

STEPS TO REPRODUCE
1. Start krita and create a new image.
2. Right click to bring up the popup palette. Note that the colour history ring is empty.
3. Choose a paint colour from the wheel then a shade from the triangle.
4. Paint a stroke with this colour.
5. Open the popup palette and note that the colour has been added to the history ring.
6. Repeat for different colours to populate the history ring.
7. Note that the colour is not always added to the history ring.

OBSERVED RESULT
See screenshot attached.  Six different colours have been selected and used (using the mouse) but only four were added to the history ring.

On one test, colours were often not added for several different sequential colours, then selecting a different brush preset from the palette and using it caused the colour to be added. Further selected colours were not added until I selected another different brush. This scenario only happened once as I was investigating the behaviour. It is intermittent.

EXPECTED RESULT
Each colour should be added to the history ring

SOFTWARE/OS VERSIONS
Krita

 Version: 4.2.8
 Languages: en_GB, en
 Hidpi: true

Qt

  Version (compiled): 5.12.5
  Version (loaded): 5.12.5

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 4.19.0-6-amd64
  Pretty Productname: Debian GNU/Linux 10 (buster)
  Product Type: debian
  Product Version: 10

OpenGL Info
 
  Vendor:  "NVIDIA Corporation" 
  Renderer:  "GeForce GTX 750 Ti/PCIe/SSE2" 
  Version:  "4.6.0 NVIDIA 418.74" 
  Shading language:  "4.60 NVIDIA" 
  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 4.6, 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) 
     Version: 4.6
     Supports deprecated functions true 
     is OpenGL ES: false 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsOpenGLES: true 
  isQtPreferOpenGLES: false 

Hardware Information

  GPU Acceleration: auto
  Memory: 16039 Mb
  Number of Cores: 8
  Swap Location: /tmp

Current Settings

	Current Swap Location: /tmp
	Undo Enabled: 1
	Undo Stack Limit: 18
	Use OpenGL: 1
	Use OpenGL Texture Buffer: 1
	Use AMD Vectorization Workaround: 0
	Canvas State: OPENGL_SUCCESS
	Autosave Interval: 360
	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
Comment 1 Lynx3d 2019-12-13 01:47:19 UTC
I'm not sure if this is really the issue you're seeing, but I found something that can cause colors to not be added to the history.
The popup palette seems to be the home of several ugly hacks, one even relies on patches in ext_qt as I recently found out.

If it only happens when you make a stroke quickly after closing the palette, you're probably seeing the effect of this commit:
https://invent.kde.org/kde/krita/commit/591684144731c0e8516bfd065fa812ff3e5f9c00

I honestly can't follow which issue this is supposed to fix, but basically it blocks the update of recently used colors for 0.75s (plus event loop latency, I assume) after closing the popup palette. Given that it's almost 10 years old, chances are the causes have been refactored at least once and it needs  reevaluation.
Comment 2 Ahab Greybeard 2019-12-13 09:07:02 UTC
Created attachment 124458 [details]
Low delay paint stroke gives no history update

Thank you for finding that. It seems to be the cause.
I've updated the title of this bug report

I repeated the testing and 4.2.6 onwards show this behaviour. The time interval involved seems notably less than 1 second.

I attach a screenshot example. I can do it repeatedly and consistenly over many sessions.
Comment 3 wolthera 2020-04-24 13:06:46 UTC
given that we identified a commit...
Comment 4 Lynx3d 2020-06-09 21:38:40 UTC
Git commit 17e6e2841c245aa16eeb000f62f3e5717db7b657 by Mathias Wein.
Committed on 09/06/2020 at 21:31.
Pushed by mwein into branch 'master'.

Remove old workaround for popup palette hiding

Commit 591684144731c0e8516bfd065fa812ff3e5f9c00 and
Commit ae734675be9f92173a9c44516a205edefb19ee97
added this to prevent picking up the new foreground color as
used by closing the palette with a left-click on the canvas.

The paint tools however have been refactored since then and
the "TODO" is no longer present in kis_tool_freehand.cc,
so remove the remains of this workaround.

M  +1    -7    libs/ui/kis_canvas_resource_provider.cpp
M  +0    -15   libs/ui/kis_canvas_resource_provider.h
M  +0    -7    libs/ui/kis_favorite_resource_manager.h
M  +0    -1    libs/ui/kis_paintop_box.cc
M  +0    -23   libs/ui/kis_popup_palette.cpp
M  +0    -12   libs/ui/kis_popup_palette.h

https://invent.kde.org/graphics/krita/commit/17e6e2841c245aa16eeb000f62f3e5717db7b657
Comment 5 Lynx3d 2020-06-09 22:06:35 UTC
Git commit a43a239a6a342a2d8e179bee1d8c57bdb1afd89a by Mathias Wein.
Committed on 09/06/2020 at 21:42.
Pushed by mwein into branch 'krita/4.3'.

Remove old workaround for popup palette hiding

Commit 591684144731c0e8516bfd065fa812ff3e5f9c00 and
Commit ae734675be9f92173a9c44516a205edefb19ee97
added this to prevent picking up the new foreground color as
used by closing the palette with a left-click on the canvas.

The paint tools however have been refactored since then and
the "TODO" is no longer present in kis_tool_freehand.cc,
so remove the remains of this workaround.
(cherry picked from commit 17e6e2841c245aa16eeb000f62f3e5717db7b657)

M  +1    -7    libs/ui/kis_canvas_resource_provider.cpp
M  +0    -15   libs/ui/kis_canvas_resource_provider.h
M  +0    -7    libs/ui/kis_favorite_resource_manager.h
M  +0    -1    libs/ui/kis_paintop_box.cc
M  +0    -23   libs/ui/kis_popup_palette.cpp
M  +0    -12   libs/ui/kis_popup_palette.h

https://invent.kde.org/graphics/krita/commit/a43a239a6a342a2d8e179bee1d8c57bdb1afd89a