This behavior is been present for some time now, I am not sure if there is some awareness already of it, I haven't seen other bug (recent) with this problem. Also I am not sure if this is related to 372053 (since I can also reproduce it). Although is not a major problem, it makes the use of the pop-up palette not practical, there are two symptoms to the issue: -The cursor lags while trying to select a color, if I try to go to the advanced color selector docker while the pop-up is on, the same lag occurs, closing the pop-up palette brings back the selecting of colors on the docker to normal. -The cursor lands on inaccurate positions within the selector, while the advance selector on the docker shows the real position, thus a expected black could be a dark-color/gray instead. This happens with the stylus/tablet and mouse alike. Build from master on a archlinux/plasma/nvidia machine. video showing the cursor position problem https://drive.google.com/file/d/0B-cDWUXy4ZMmQjdHRkxqVjZ5aTQ/view?usp=sharing video showing the lag https://drive.google.com/file/d/0B-cDWUXy4ZMmNmJSNFd0aXNfTzg/view?usp=sharing
Video links are the opposite, lag first, cursor position ^ Sorry for that.
Git commit 02c303b337cba86ec1a0147eb8c8092b6e9290ae by Boudewijn Rempt. Committed on 16/11/2016 at 18:32. Pushed by rempt into branch 'rempt/impex-refactoring'. Improve rendering speed of the Visual Color Selector * Convert all colors for the colorselector to a QImage in one go M +1 -1 libs/ui/widgets/KisVisualColorSelector.cpp M +51 -43 libs/ui/widgets/KisVisualColorSelectorShape.cpp M +4 -4 libs/ui/widgets/KisVisualColorSelectorShape.h http://commits.kde.org/krita/02c303b337cba86ec1a0147eb8c8092b6e9290ae
Git commit 6471fa758d0c41f2d7ad162f5eecc6aed5de96c2 by Boudewijn Rempt. Committed on 16/11/2016 at 18:45. Pushed by rempt into branch 'krita/3.1'. Improve rendering speed of the Visual Color Selector * Convert all colors for the colorselector to a QImage in one go M +1 -1 libs/ui/widgets/KisVisualColorSelector.cpp M +51 -43 libs/ui/widgets/KisVisualColorSelectorShape.cpp M +4 -4 libs/ui/widgets/KisVisualColorSelectorShape.h http://commits.kde.org/krita/6471fa758d0c41f2d7ad162f5eecc6aed5de96c2
I also find it strange that the appearance of the hue selector ring is now affected by changes to saturation and value. Is that intentional, and could it be adding to the slowdown?
Yes, it's both intentional, and one of the reasons that the color selector is somewhat slower. Here's the original project description: https://phabricator.kde.org/T2337
Git commit 16c1586c6708cfec62e57a371d7b07f787800390 by Scott Petrovic, on behalf of Boudewijn Rempt. Committed on 19/11/2016 at 15:23. Pushed by scottpetrovic into branch 'petrovic/impex-brush-editor-ui'. Improve rendering speed of the Visual Color Selector * Convert all colors for the colorselector to a QImage in one go M +1 -1 libs/ui/widgets/KisVisualColorSelector.cpp M +51 -43 libs/ui/widgets/KisVisualColorSelectorShape.cpp M +4 -4 libs/ui/widgets/KisVisualColorSelectorShape.h http://commits.kde.org/krita/16c1586c6708cfec62e57a371d7b07f787800390
Thanks for working on it but the current implementation of the color selector unfortunately also doesn't work too well for me: When I choose a black color the whole outer circle turns black and I first have to select a different saturation to see colour on the outer circle again. (Acoordingly when I choose a white color the whole circle turns white.) As I use black or grey most of the times I don't see any colors in the wheel most of the time which is quite irritating. Is there a toggle anywhere to switch back to the previous behaviour (i.e. always showing a colored outer circle)?
On the newer builds in either Rempt/impex.. or petrovic/impex.. there is a improvement on the speed. but the lag still too slow to be usable, most important the point in the pop-up still inaccurate at times. Let me know if I should try a different branch or if some other information is needed. @Chris and @Jelena: I do too share the same opinion, I know there is lots of work done by the devs on the color spaces and selectors, I wouldn't like to simply say "doesn't work for me" when it kind of does. Yet I would like to weight my point of view towards the same situation, to me personally is very awkward to use the ring when not in full color regardless of the saturation, don't know if this new system mimics other software and thus was implemented to easy other's people workflow when they are used to, or may be we are a minority among the users who prefer the "old" way :) Either case if Boudewijn and the rest devs think this can be worked then we should open a different bug for it since it would be a wishlist item, but if the case is that the work done around the color selectors simply doesn't allows this to change, then we can focus (as users) on working-around, e.g. lately I'm simply using the docker more than the pop-up palette to select colors, once I have a few I like then I use the pop-up history color ring to re-select them.
Just to add some info and suggestions : This happens regardless of the video driver (nvidia or nouveau) and to me it's actually a big issue as it's the only color selector we can use when creating a fill layer (and I use fill layers all the time). At least an option to bring back the selector from 3.0 in the settings would help a lot.
I decided to add a feature request : https://bugs.kde.org/show_bug.cgi?id=379595
Git commit 0328e20bc072c11ed5a6c12bb226ceca23d46711 by Wolthera van Hövell tot Westerflier. Committed on 25/08/2017 at 15:39. Pushed by woltherav into branch 'master'. Fix the offset in the triangle color selector. This, combined with the recent speed up should fix two of the big issues with the internal selector. The other issues are a desyncing between the two selector widgets due to stupid rounding errors, and whether or not it should be possible to have the hue ring stuck to one color. These will both take a lot of rewiring. Anyway, test plz when you have the chance. M +16 -11 libs/ui/widgets/KisVisualTriangleSelectorShape.cpp https://commits.kde.org/krita/0328e20bc072c11ed5a6c12bb226ceca23d46711
*** Bug 383780 has been marked as a duplicate of this bug. ***
*** Bug 384233 has been marked as a duplicate of this bug. ***
(In reply to wolthera from comment #11) > Git commit 0328e20bc072c11ed5a6c12bb226ceca23d46711 by Wolthera van Hövell > tot Westerflier. > Committed on 25/08/2017 at 15:39. > Pushed by woltherav into branch 'master'. > > Fix the offset in the triangle color selector. > > This, combined with the recent speed up should fix two of the big issues with > the internal selector. The other issues are a desyncing between the two > selector widgets > due to stupid rounding errors, and whether or not it should be possible to > have the hue ring > stuck to one color. These will both take a lot of rewiring. > > Anyway, test plz when you have the chance. > > M +16 -11 libs/ui/widgets/KisVisualTriangleSelectorShape.cpp > > https://commits.kde.org/krita/0328e20bc072c11ed5a6c12bb226ceca23d46711 Reporting back my tests (this on the master branch build), there is definitely a big improvement: -Speed has increase significantly, although still a tiny bit glitchy, this is not too noticeable, -The color selector prompt seems much more accurate while using the popup palette except: -the corners of the selector (pure black/white/color) are very difficult to select from the popup palette (or other widgets that use this), dragging would not reach the corner, clicking on the corners give sporadic results. -This behavior obviously is experienced in other widgets that uses the new color selector like selecting color for fill layer or the color to alpha widget. note: I use my build on a six core (half decent) pc with 16ram, I think the speed as mention is been helped by the better use of multicores, not sure how the selector is going to behave on a lesser performance wise pc though.
*** Bug 374069 has been marked as a duplicate of this bug. ***
("krita-4.0.0-beta1-b322ae6-x86_64.appimage" on Ubuntu 14.04) Just to confirm the erratic movements of the cursor and the triangle shape of the Popup palette when the "Advanced Color Selector" is set to use the CMYK color space (menu > "Settings" > "Configure Krita" > "Color Selector Settings" > "Advanced Color Selector" > "Color Selector" > "Color Selector Uses Different Color Space than Image")
*** Bug 392958 has been marked as a duplicate of this bug. ***
Just wanted to add that while pop-up palette and advanced color selector currently feel pretty responsive, the color selector within the "Select a Color" pop-up window (that appears when you click on your current foreground/background colors) still feels significantly worse. The other selectors try to smoothly follow your cursor even when it leaves the widget area. On the other hand, the "Select a Color" window doesn't do this, and the selection stops following the instant your cursor leaves the hue ring or the saturation/value triangle. This ends up feeling very buggy and unforgiving as your selection 'sticks' to the edges of the triangle/ring, which is especially annoying with a pen/tablet or as you approach the corners of the triangle.
Yes, we know. The selector you get with the fg/bg color selector can actually do more than the "normal" color selector, like selecting HDR colors, and that is one reason it's slower. The other reason is that we haven't figured out how to cache the color wheel, which means it gets recalculated on every more.
This ticket changed focus to looking at the slowness in the foreground/background color selector in the toolbar. Changing the title Talking with Wolthera it is probably using the internal color selector, which can select colors above 8-bit. We will have to figure out a way to speed this up one way or another.
This should be resolved in Krita 4.2.7 beta thanks to Lynx3d's hard work. If it is still slow, please reopen.