https://bugs.kde.org/show_bug.cgi?id=441956
--- Comment #2 from keyth_qcfx2 <keyth2363...@gmail.com> --- I made the minimal working example. download at: https://github.com/EyeOdin/bug_report_example to use this: 1. install "bug_report_example" as any other plugin docker. 2. open any image bigger than 1000x1000 or so with krita. This will update the display of that image every second without any limitations for this example. 3. press Left Mouse Button on the docker and move the white square with the mouse. 4. using this in 4.4.5 will move the square with no lag and on krita 5 will move the square with rubber banding Notes: 0. This contains the essencial loop of QThread present on Tela. I tryed to make a scripter version but considering I had to create a window to exist, it was not affected by the UI lag nor it had canvas directly available and Krita somehow as it seemed independant I might be wrong though. But because of that I made it into a mini docker as I think this is a composited problem and not a isolate case that happens on every situation with QThread. 1. I know self.update() sucks to cause lag but I made it to write it faster, my original script does not have it but has tons of more stuff that justifies not using it. 2. The original script stops itself from doing a full loop but still has to check what is the image because I cant detect if there was an interaction of the user with Krita to guess "considering the user clicked Krita did he edit the image?" I made that into another proposal to bypass this QThread handycap situation at: https://krita-artists.org/t/python-user-activity-versus-inactivity-timer/28504 However doing this proposal with the current system is so glitchy and prone to crash that is not worth exploring more as it is not a viable solution as I state on the thread. Either way, the usage of QThread bypassed all these crossroads by simply powering through it by managing the workload correctly. -- You are receiving this mail because: You are watching all bug changes.
