https://bugs.kde.org/show_bug.cgi?id=441956
--- Comment #4 from keyth_qcfx2 <keyth2363...@gmail.com> --- I was asked a minimal working example not efficiency... in Krita 4.4.5 and below does not go slow and in Krita 5 goes slow, what can I imagine it too be? Because if I did not put it on a QThread it would act slow just like it is in Krita5 but on every version regardless. If QThread does not work it is just like any other class but on the same thread no? That is why I think it is something related to QThread. Thing is my code for how inefficient it might be it WORKS in QThread normal(no freeze frames) and then is best example to detect problems because it is not efficient. Your arguing the survivors bias. Because I have been searching other ways to render this since my lack of QThread or whatever it is and I have found a new way and is almost in real time now. Not to mention despite my example updating with mouseEvent it only uses the image from one second ago, run sends images on it's own it is not triggered to read by mouseMove. but that is beside the point. If I am 100% sure it is QThread. no I am not, but my testings pointed me in that direction because that QThread class only does one thing. if it is not the QThread it is something inside of it, but everything inside seem to be working normal on their own. I don't think it is fractional UI scaling because my other plugins are working correctly with scaling in this Krita 5 environment and they were severely affected by it in Krita4.4.7. And I scale QImage with them too and did not happen to notice issues with them yet. The things that differs for me here is it being inside the QThread and requesting a Thumbnail that I never used before, but I don't making thumbnails changed. -- You are receiving this mail because: You are watching all bug changes.
