lb Cake

Safe to say this is still a problem in 2023?

Since my purchase on December 18, 2022 I have been forced to migrate back and forth between v1 and v2 due to the lag, hangs and crashes in v2. On 10/6/2023 I updated to 2.2.0 after not working in v2 since July 2023 due to performance and stability issues described in this forum and was immediately forced to return to v1 due to unworkable lag in the pixel persona. Task Manager showed a power usage spike during the lag but nothing else. My v1 and v2 performance metrics are identically dialed down from the default and hardware acceleration is disengaged, and while that worked wonders for Designer v1 it has had no appreciable effect on v2.
Here's hoping this problem can be fixed before this thread reaches double digit pages.

Are there any plans to allow for the opacity of Guides to be changed? I don't know what the backend process would be, however considering that we can choose between fill and outline I wouldn't think it a major overhaul. 

In the interest of visibility I'm going to throw in my 2 cents. I mentioned this in relation to another thread regarding the scope of the Select All/Same functionality. Wouldn't it be a simple fix to just expand the scope of the lock function to exclude locked objects from all manipulations, including selecting same attributes?
I am a game developer and primarily use Select Same on duplicated items that I wish to recolor quickly. In it's current iteration Select Same is only marginally better than just selecting objects individually. Since locked items are not immune to the Select Same parameters I typically have to cut or copy the objects onto a separate document in order to prevent altering my locked originals, this is a workable solution but hardly ideal for efficiency especially given my scope. 

Are there any plans to allow for the opacity of Guides to be changed? I don't know what the backend process would be, however considering that we can choose between fill and outline I wouldn't think it a major overhaul. 

If the development team refuses to develop this feature, please send a clear notice. Because the request keeps coming up. In order to avoid wasting forum resources and users' expectations, please give a clear answer.

Indeed, just yesterday I reverted to a Adobe state of mind and forgot that locked items are omitted from the Select Same parameters and changed the colors of a couple hundred objects. An hour later I'd moved on to other tasks only to notice my (forced) blunder. All I can say is thank God for incremental saves.
I really hope this gets addressed soon.

I appreciate the reply fde101. I am aware that the lock function only prevents selection and transformation. My apologies if I was unclear on my point.
The point I was attempting to make is that I am surprised that the lock function allows anything at all to happen to the locked objects/layers. It could just be my memory playing trick on me, but I am accustomed to the lock function in other programs (Illustrator, CorelDraw, Inkscape, etc.) excluding locked items from any action whatsoever. I'm hopeful that Affinity Draw will incorporate something like this in the future so that the newly implement (and much appreciated) Select All function can be used a little more conveniently and efficiently.

I appreciate the reply fde101. I am aware that the lock function only prevents selection and transformation. My apologies if I was unclear on my point.
The point I was attempting to make is that I am surprised that the lock function allows anything at all to happen to the locked objects/layers. It could just be my memory playing trick on me, but I am accustomed to the lock function in other programs (Illustrator, CorelDraw, Inkscape, etc.) excluding locked items from any action whatsoever. I'm hopeful that Affinity Draw will incorporate something like this in the future so that the newly implement (and much appreciated) Select All function can be used a little more conveniently and efficiently.

I agree I was really surprised to find that locking a given object didn't prevent it from being accessed by the Select Same function. It would seem a really simple fix to exclude locked items from the selection.

I agree I was really surprised to find that locking a given object didn't prevent it from being accessed by the Select Same function. It would seem a really simple fix to exclude locked items from the selection.

I apologize for reply so belatedly, my alerts are a mess. All the same thanks for taking the time @walt.farrell and @Umiama. I can't really explain it either, it was one of a many issues I was having after the 1.9 update. For now at least it seems Designer and I have settle on a truce and everything is working efficiently and (mostly) correctly now.

Thanks @Gear maker I appreciate all the effort you've put into this. By all appearances it looks like I've reached some sort of solution.
As I mentioned before the issue seemed to lie with a series of rounded rectangles (I had roughly 10,000) that were making use of the contour tool, once these objects were deleted the file size and memory usage fell substantially, although it was still quite high. I also dropped the RAM limit to its lowest position and saw an immediate boost to responsiveness, including redraw speeds, and a stabilization of memory usage. 
I imagine the higher memory usage is a Windows/AMD thing, alternatively its a good excuse to upgrade my desktop memory 😁. Thanks again @Gear maker I think we can call this one solved.

@Gear maker yes I am. I think the major problem may be a series of shapes using the Contour Tool. I'm going to continue transferring items while omitting those shapes to see what that does to my load times. I'll update the post with my findings.

Thanks Richard, I should have done that before reverting to 1.8. I stared long and hard at the OpenGL option but ultimately decided not to bother with it. Turning it off seems to have resolved all the issues I was having after upgrading to 1.9.0.

Thank you folks for the prompt replies. I'll have to read up on the subject once I have a free moment.