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.
1 Like
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.
2 Likes
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.
1 Like
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 
2 Likes
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.
1 Like
@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.
1 Like
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.
1 Like
@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.
1 Like
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.
3 Likes
@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.
1 Like
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.
3 Likes
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 ?
1 Like
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.
3 Likes
Thank you for the workaround on MacOS! Turning the points off is working well 
2 Likes
Ok folks… I have fixed the elusive high cpu usage bug when the control points are turned on. Now I just have to fix the similar issue when zooming in more than 100%. I’m assuming it’s going to be a similar issue causing the scene or graphic items to continually redraw unnecessarily.
3 Likes
I’ve narrowed down the zoom issue between the Jan 11 2023 and Apr 14 2023 builds. Could be related to the zoom to point feature that was added in that time frame. The control point issue was a legacy issue that existed since Val.
Curiosly the cpu use only goes up when zoomed more than 100.00%
1 Like
Are you saying that zooming out is not a problem, but zooming in causes the CPU to run high? hmmm.
1 Like
It’s more complicated than that… the cpu usage goes up when tools are within the view and you zoom greater than 100%. Zoom out below 100% and the cpu usage goes back down. Which is unlike the issue with the Control points that I fixed, where if the control points were turned on the cpu usage went up. Which had nothing to do with zooming, but rather a feedback loop between the control points and their curve causing endless repainting.
I’m stumped at the moment on the zooming cpu issue… especially since it seems the only tool that doesn’t cause the issue is the basepoint. I suspect it may a similar paint issue between the tool (point) and leader line / name where over 100% it’s causing a paint recursion. I’ll keep at it and figure it out.
1 Like