What a purpose of rotation of the color wheel’s triangle? I saw it in couple other software also but can’t find any explanation through web why it is. I feel really uncomfortable using it. There would be good option to make it static.
Any ideas?
1 Like
As you’ve seen, it’s a common presentation style for a colour selector and the Advanced Colour Selector has a stationary triangle.
I don’t think there’s any kind of ‘mode’ control for it. Someone else may know differently though.
All you can do is make a formal bug report of the ‘Wishlist’ classification and it will be added to the long list of existing fault-bugs and wishlist-bugs in the system.
2 Likes
I do not like it spinning very much either, so I tend to use the normal docker. I don’t think there is a way to stop it from spinning in the Pop-up Palette though.
But you can choose a shortcut to show the colour wheel without the rotation near your pen!
You can get the Colour Wheel by using Shift+I. The action is called “Show Color Selector”. You can change the shortcut to something easier to press! There it won’t rotate! 
1 Like
Didn’t know about shortcut to the color wheel, thanks, Rakkurri. Btw, I prefer Artistic Color Selector, and pop-up color wheel use on sketch stage in fullscreen mode.
But I just wonder : “What is the benefit from triangle rotation? What is an advantage compare to standard triangle?”
1 Like
ps. really don’t know why my text in previous post is HUGE? I didn’t see any size format tool.
I edited it for you, It had two underline beneath that sentence making it a header or title
1 Like
You can try to set the following option in kritarc:
popuppalette/usevisualcolorselector=true
The “internal” visual color selector does not feature the rotating triangle either (and on top of that supports different selector styles too, aswell as wider gamut than sRGB).
Though it still has a few small glitches and does not use the available space that perfectly either.
-edit-
oh and I don’t know what purpose the rotation would serve either, guess it “looks cool” but doesn’t help usability, or actually lowers it.
3 Likes
Thank you. This bypass is working. And as you say has glitches. There are jags while dragging pen in color wheel, including small size of triangle and my 13" display it becomes very critical. So, I think using shortcut to awake standard color selector is the optimal option for now.
Hm what exactly do you mean?
Is there some UI scaling (Hi-DPI) in effect?
Maybe I can fix it…
While dragging in triangle the point selector moves after second or more straight to pen position, it doesn’t react in the same time with stylus.
You mean UI scaling in Windows of Krita? HIDPI support in Krita is on, but I also tried it off - results are same.
P.S. sorry for the late respond, notification for this answer didn’t come to my email.
Hm sounds like a different issue than I expected.
Do you see a difference between stylus and mouse when dragging the handles?
And with UI scaling, yes I meant if you have Hi-DPI enabled in krita and use a display scaling >100% in Windows, i.e. the interface gets upscaled.
For compatibility reasons, applications see virtualized coordinates that correspond to an unscaled UI, and need to transform it to real display coordinates (which currently only a few places in krita do, like the canvas itself)
I’m currently working on some improvements, but it seems Qt still has rough edges when it comes to scaling…
With mouse no lag, only stylus. For testing I switched from WindowInk to Wintab and it seems OK. But in WinTab I have other more serious issue I already posted (No pressure at first stamp in floating dock mode)
UI scaling in Windows is 100%, in Krita HiDPI off/on doesn’t influence to the issue.
Btw, two fullhd monitors connects at shorter edge (display + cintiq) are counts as one HiDPI display?
I record the screen with the lag. Unfortunately, my record software doesn’t show the real position of cursor in the “pause” moments when I drag pen away and then selector jumps.
https://youtu.be/aAX5M0rUJOo
Hmm, it seems the same issue are with default docker palette “Advanced Color Selector”. I didn’t notice it because I always use “Artistic Color Selector” panel. Since selecting process in ArtisticColorSelector slightly different I didn’t pay attention, BUT it also has the same lag, though it didn’t strong like in “Advanced Color Selector”. Strange that pop-up rotating triangle doesn’t has the issue.
Hahh, it seems I’am forced to use WinTab+docked “Dockers”
I did ask Dmitry why the default color selector of the popup palette has extra code to generate mouse events from tablet events, and IIRC he told me that with WindowsInk no mouse events get synthesized when some (parent) widget accepts the tablet events, which is the case for the canvas (and hence the popup palette).
I’m not sure why it would happen with the advanced color selector docker though, but maybe having it float causes this.
Will see if I can fix that, though I can’t test it myself I’m afraid. And how soon (if accepted) this would go upstream is yet another question…
Thanks for troubleshooting, Lynx3d.
I checked advanced color selector in float and docked mode and there is no differences.
Also I tested WindowsInk in other software. Similar issue with color picker also have ClipStudioPaint and Rebelle. Photoshop 2019 is OK, but I remember visually similar glitches in previous versions since they switched plugins from flash to html engine. Paint Tool SAI is OK too. In PaintstormStudio I didn’t find switcher windowsink/wintab but tested with option in wacom driver settings and it is OK.
And, just in case, I checked it with Intuos5 (main tablet is Cintiq13hd) and as suspected there is no differences.
I have now taken care of all the technical issues I’ve found so far when using the visual color selector for the popup palette:
- close palette with right-click when the cursor is on the selector
- better fit of the triangle
- more precise visual positioning of the handle on the hue ring
- render at native screen resolution when using global UI scaling
- listen to tablet events to avoid issues with emulated mouse events (hopefully)
The code branch:
https://invent.kde.org/mwein/krita/tree/color-selector-enhancements
Unfortunately I don’t have a windows machine here, so I can’t test it there, nor create a build for others to test 
2 Likes
Thanks for the work! Is it will be included into next update of Krita? or it have to be tested by someone before?
1 Like
Yes some feedback would be great, but I haven’t even made a merge request yet.
So probably not for 4.2.9, the devs were a bit disappointed by the amount and severity of the regressions lately and the next release is a bit overdue too, so I guess we should play it safe for this round, I’ve only committed small fixes to that.
4.3 will still take a bit, so no hurry in that regard.
My ultimate goal is to have the color selector support HDR displays too (even though I don’t have the hardware) so this color selector can finally be a more widespread alternative to the multitude of sRGB-only color selectors scattered over krita’s source tree…
1 Like
So, I have read the “build” manual and it seems sort of higher mathematics for me. It is get a quite a time to figure out this kitchen before I will got the successful result.
Just to give an update, the color selector changes are now in master and should be in the nightly builds now.
Though there is a catch, while the resource rewrite is now merged, it still has some rough edges, one of them is noticeable lag on color selection (spits a bunch of console messages too), and other not yet working things.
Not sure if another stable release (4.2.10) will happen before 4.3.0 (if that’ll be the version number) gets released, so I’ll not speculate about possible backporting.