I see. that is good to hear none the less. I did thought both issues were connected so it is like 2 issues then.
When I started tweaking I thought solving this could be impossible, so I am happy to hear that there is a way.
I still need a couple of days to implement both solutions. Not to mention run tests on performance as I build up.
Updated: Lite is Lite?
https://github.com/EyeOdin/Pigment.O-Lite
Preview:
It has all the core features for color conversion.
Lacks TIP, TTS, MIX and Panel but it should be almost Copy Paste and tweaking variables and stuff.
Also Added a percentage indicator while your editing values for the percentual ruler.
Also Cleaned the Agnostic Color Scale of Pigmento.
If this version is not problematic it should be the last Lite version.
I donât know why but after I installed it, Krita doesnât open anymore. Nothing loads up after the loading screen. After deleting the plugin, Krita opens up normally again.
Hereâs what shows up when I ran it using console, https://pastebin.com/Xq7CTkLv
Does not even boot? =0
oh my but it is working so much better now on my end. that is so strange~~
let me try and read that to see if I can understand something.
P.S. - This is impossible I think something went wrong on the upload. I updated it try downloading again.
Alright, it is working now but weirdly it has more lag than the original.
Lite
Original
⌠it is like Linux works backwards for some reason. 
it should be going much faster. I need to think.
The only thing I can think of now is to just make a different UI for Linux.
No colors, no point and click and default widgets.
Update: New lite version
This to me is performing so well, even with frame dropping on the recording you can see it:
I havenât looked at the source code, but you should be able to inline them so your source code doesnât become redundancy itself. Iâd bet a lot of money that if-statements by themselves are not a bottleneck.
Just from the gifs you posted, Iâd say the bottleneck is going to be in the view or viewmodel logic: either how the widget is bound to data or how the widget draws itself. Otherwise, maybe the threading logic if you have poor thread locking structure. I donât yet work with Qt though.
It just occurred to me your source is in python, so I donât know about inlining, then. And that means the layer between Krita and your plugin could even play a part.
yeah I can only go so far considering I am in python.
but I was trying to give it my honest old try to make it work for Linux without making 2 versions of the same 
I think it is not the draw method at all. it is when I made the custom widget and when you click on it and how it converts color after that to the other channels, I think. because with the same code but a standard slider it moves pretty good but it is a bit super ugly and harder to use.
as for threading I just made a normal thread I think as they only touch each other only on the conversion point and never again. The tricky part is that the information goes back and forth because of the user input. But I might be totally wrong on how to use it for sure.
But before I did this the lag of it was totally ignorable on my end and now it has no delay at all. I think to improve performance for Linux just deleting features might be the only option.
Threads are expensive to allocate. How often do you create a thread instead of reusing it, and do you process a ton of data or just a little (in which case, a whole thread might not be worth it?) It would make sense, if you create and destroy threads every frame, that this could be a source of the different speed between Windows and Linux, depending on how the OSes handle threads.
As for converting colors to each channel, you can probably memoize that to some degree if youâre worried about it. Even without looking at the code, Iâm not; it shouldnât affect performance much at all.
The âand when you click on itâ and âthe information goes back and forthâ parts are the viewmodel I was mentioning as a source of slowness. So given you believe drawing is not the problem, it could be: the viewmodel, thread creation, or the Krita-python plugin bridge causing your pain.
Iâm sorry if Iâm interrupting without the knowledge of the specific problem and the fixes you already applied, but from the first glimpse it looks like a standard Kritaâs âno signal compressionâ problem⌠Basically in a lot of places in Krita there are sliders etc. which when moved, every little change is sent to Krita and creates avalanche-like changes everywhere. It comes from the signal connection between the slider - or any other UI widget - and the value it represents (often also calculated or having some consequences deep in Krita etc.). Because of that, in Kritaâs code there are often added little objects that are called âsignal compressorsâ, which, colloquially saying, eat all the huge amount of signals in some time period and instead send just one, so the calculation needs to be done just once. If the time period is small enough, the user doesnât see it anyway, but the slider suddenly moves much quicker because there is much less to do.
I donât think signal compressors are available in Python now, so I guess @EyeOdin havenât used them, have you? If so, instead of trying to make it work like that, maybe it would be easier to work on making a Python API for the signal compressor, Iâm sure it would be useful in other places, too. (Itâs very easy to use, so adjusting the plugin to use it wonât take much time).
@tapatilorenzo
I will read a bit more about thread creation and deletion then.
@tiar
I think I dont even know what âsignal compressionâ is yet. I did not use it that I know.
Where is the latest link to be downloaded and test a bit?. When I tested, it worked fine. With a bit of lag but fine and with interesting options. What happen right now? Is not working?
Hmm, does not seem to have noticeable improvement on the lag on mine. The original version still updates the slider faster.
I donât know if a misuse of threads would make such a visible difference⌠I know that I fixed a few bugs regarding slowness of sliders (ex. the Size of the brush) because of lack of signal compressors though, so let me write here about that.
@EyeOdin since you seem happy to experiment here, Iâd check if it works better if you ignore 9/10 signals like
self.aaa_1_slider.SIGNAL_VALUE.connect(self.Pigment_AAA_1_Slider_Modify)
Like, make a counter somewhere, and return immediately (without any changes etc., except for increment of counter) if the counter%10 != 0, or something like that. (Do it on just one slider to see if it helps). If my suspicion is correct, the slider should be much more instant. Since itâs not a correct signal compressor, you can see some incorrect values at the end (for example the slider not exactly reaching the point you were sliding to), but a proper one would have it fixed, so whatâs matters now if it helps for the speed or not.
The code is rather hard to read, one long spaghetti, and the strange way to update the repo by deleting and re-adding files doesnât help to follow the development eitherâŚ
So you create a ton of threads, but they all just seem to call some function once and then theyâre done. But manipulating the GUI outside of the GUI thread is a really bad idea anyway. Iâm actually surprised nothing bad happens, but it seems trying to do anything PyQt from a non-QThread is just ignoredâŚ
I donât get it. ignoring a fraction of a signal? what does that mean?
I really donât understand what you ask me to try out with the counter thingâŚ
when it is not connected to anything the sliders work fast but as soon as it makes calculations for more than 1 color space it suffers, the threads helped so in Linux the interface would not become stoped until the slider finished its calculations.
the sad thing is that it is âinstantâ for me even more so now.
I donât have need for github I have my own cloud and since I am working alone, github is just a relay. my versions are on my cloud properly archived. it did not even occur to me someone would even want to see the progress just download it. Besides what is there is what I have currently.
it only works with QThread?!.. ~_~
another +1 PyQt Hate.
Update: Lite update and bugfix
https://github.com/EyeOdin/Pigment.O-Lite
Lite now has all the features of the ânormalâ version, It has TIP, TTS, Mixer and Panels.
However still slow on Linux as on the previous post no upgrades there yet.
On Windows however the panel is much faster than before as a consequence of the work done on the previous Lite versions. Using the tablet on the normal had a small delay until it came up to speed and now it is not noticeable moving around.
Also changed the Double click behavior to use just âModifier Keyâ + âSingle Clickâ.
Reserving Double Clicks to APPLY settings only regardless of Modifier Keys pressed.
I am gonna play around with QThread now and see what happens, but if I recall i opted for Pythons Threading because it was easier to implement with modules, but since I killed all modules and have only one now it should be easier.
Considering Signal Compression I still have not found anything talking about that to read on the subject but I will keep looking around to see if I find something.
My current stance:
Now it is a Bigga Spaghetti