Hello,
I’m experiencing major lagging issues working in Draft-Mode. I’ve noticed this issue over the last updates, currently working with version 2023.7.17.212. The patterns I’m working on have been created in older versions but have been converted to the higher versions. Is there a known reason and maybe solution to that ?
Best, Philip
Hello, @philip
Which operating system are you working on - because I’m using Windows 10 and haven’t noticed anything - so I’m guessing that @Douglas will need to know so that he can check it out.
Yes you’re right, I’m using macOS.
@philip - Can you share a pattern with it’s measurement file so we can compare results, making sure we see what you see?
@csett86 - Can you confirm this behavior on MacOS?
I have not seen it myself, but if you @philip could share an example with some instructions when you hit the issue, then I sure will try to figure it out and fix it.
I know there has been a reported issue with high cpu usage on macOS. It appears to be related to curves, specifically with the control points. For some reason when the curve(s) are in view the cpu usage goes up. I guessing it’s a constant (re)paint() issue. Not an issue on Windows though. Not sure if it’s the case here, but something that woukdnt hurt for me to take a look at.
I can confirm that it often and mostly appears trying to change curves, but also sometimes while scrolling through the workpieces in Draft Mode, while zooming in and out for example.
Hi, @philip. I don’t know anything about Mac OS, but something is niggling in my mind. Do you have any pattern pieces made in Piece Mode? If you do, perhaps you can double check the order that the curves and nodes are listed in the pattern piece Properties. We had a case a while ago that the curves were selected in the wrong order with a node inbetween and once this was reordered, all the lagging problems went away.
I can’t find that topic right now, but I’ll keep looking. In the meantime, perhaps you can just double check that it isn’t the same problem 
Hi @Grace,
unfortunately I don’t exactly get how I should try you succession 
.
I can only say that the lagging appears on different files that I’m working on.
I’m planing on starting a new one from scratch using the newer version of seamly2d and see if it’s still an issue.
@philip, perhaps if you send me your files, I can check it on Windows 10. I can also check for anything that’s out of order. If you prefer, you can DM me with your files.
I searched for that other topic last night but really couldn’t find it. 
Can you try loading a problem pattern and toggle the curve control points off, and see what the response is.
I think it’s only a macOS issue, but it can’t hurt to see if it’s a pattern issue. I have a hunch what the problem is.
@Grace I’ve sent you the pattern in private.
@Douglas I’ve opened one problem pattern, already after opening it’s lagging trying to zoom into the pattern to be able to select a curve, so its not only while interacting with curves.
Did you try toggling the control points off? I’ve pretty much confirmed that even on the windows version when control points are visible within the scroll area, the cpu usage goes up… even just sitting there doing nothing. I’ve never really noticed before, because I usually have the points hidden. In my case it hovers around 21%, and spikes around 30%. If I turn the control points off or scroll / zoom any visble control points off the view area, the cpu usage drops to 0%. I even tested it with an old Seamly2D pre fork ver, and it does the same thing. So it’s been a long existing issue. I’m sure it’s probably proportianal as to how many curves are in a pattern as to how much the cpu usage jumps.
Now that I know where the issue is, I can fix the issue. It’s probably the control point widgets are stuck in a recursive paint loop. Constantly repainting when they should only repaint when something changes… like when you move them or the curve, zoom or scroll, edit a formula, etc.
@Douglas, I’ve just checked @philip’s pattern and it doesn’t lag at all on mine. Also checked a few of his pattern pieces for the order of the nodes, but didn’t see anything out of line. The control handles were already hidden when I opened the file and the CPU usage ranges between 0 & about 5% while zooming in & out or moving around. As soon as I make the control handles visible, it goes up to as much as 77.7% while doing nothing !?! If I zoom in & out, it varies between about 35% and 58%.
I hope this helps.
Yes it helps… one more confirmation of where the issue lies. I’m assuming the variation in usage is machine dependent. I’ve got a laptop with a pretty fast cpu & graphics, with a lot of ram, so that’s why I"m maxing out at 30%. Although that could change if I loaded a pattern with even more curves. It’s instant though… as soon as I click the control points off the cpu drops to zero.
I’ve checked the CPU and it does go up to a >99% when a curve is selected. I’m working on MacOS using an M1 MacBook Air. I hope that this isn’t a big thing to fix ?
It shouldn’t be. Just need pinpoint which graphic part of the control point triggering the repaints. I ran the app in debug mode last night, and confirmed that when the control points (and line) are visible they’re all stuck in an endless loop repainting.
Since a control point (square) is tied to the line, and subsequently the spline, when one changes (and paints) it causes others to paint… it’s like the point is telling the line to paint, which then tells the point to paint, which tells the line to paint again… and so on.
Plus, another side effect of this when the spline repaints, it in turns triggers the groups to update for no reason… another apparent legacy inefficiency.
Thank you for the workaround on MacOS! Turning the points off is working well 