Ben

Standard rotation convention is that a positive rotation rotates away from the primary axis towards the secondary axis (conventionally X towards Y) - so a 90 degree rotation will take you from the X axis to the Y axis. This understanding becomes more relevant as you add more axes. Clockwise/anticlockwise are all dependant on the handedness (is that a real word?) of the coordinate system and the method of projection to the visualisation plane. It is true that we are not representing the rotation correctly in Affinity. Our logical axis (as the user perceives) points right (X) and down (Y), yet our positive rotation behaves as though our Y is up. This is something that may well get addressed in the not too distant future (no promises on time). It crept in due to the different behaviours expected from different people when dealing exclusively with either vector or raster content.

The short answer is - to improve performance overall, you'll first want more memory and good size (and faster) primary storage. A faster CPU is also beneficial, but sometimes the higher spec ones won't offer the equivalent performance benefit relative to the price difference. Generally, you'd want to balance the spec of all three anyway - it'd be pointless having the fastest CPU with the minimum memory. Annoyingly, the option of upgrading memory later is being hampered in some machines (and often 3rd party memory is a lot cheaper). We make use of primary storage quite a bit to store bitmap data, and document data, and scratch files for document saving - so a fast hard drive is a must. Then there's GPU performance...

A sample file, perhaps...?

How about also providing the examples of what freezes the app so that we can improve the performance? Snapping is now threaded, and also should time out - but there will be certain permutations that still require the time out test.

You have to understand that cloud storage (whichever brand) is NOT a backup. It is not a safe version of a file stored at some specified point in time. If your local copy of a file becomes broken, for whatever reason, cloud storage will propagate that to all other instances you have, including the server side copy. For this reason you should not view cloud storage as a mechanism to protect historic versions of your files. A backup has to be an intentionally created duplicate copy of a file at a given moment in time. You do not work from a backup - you hold it only for the purpose of archiving know versions. It needs to remain safely separated from your working copy. Cloud storage fundamentally does not achieve this. Some cloud storage system suggest they offer some form of versioning. I'm not sure about the quality of that over a system tailored for the job.

We just need to have a look at the command and see if it can't be applied to multiple layers in one go.

No - it will flatten to one rasterise layer.

Because you were never snapping to these things. The thing you were actually snapping to was/is obstructed by the selection box handles. If you had two circles on screen - one selected and one not - you would be able to snap a guide to either of them. So seeing the selection box on top of the one circle gives you nothing (other than the visual cue that I mentioned). This is what is meant by visual clutter - UI devices that serve no purpose while an action is taking place. All the handles are there until you drag one to start an action - they then become redundant. For this reason we also offer the option to hide the selection box while transforming objects - because people want to see the document contents while performing actions, not the UI overlay. Yes - in 1.6 we didn't hide the selection box when moving guides, and in 1.7 we now do. That has changed - along with a raft of other major changes in 1.7 to how most of the tools work. All very carefully thought out, and intended to improve usability. I also don't understand what you are saying about having to zoom in to snap things more accurately...????? The whole point of snapping is that it will give you the exact same position regardless of zoom level - if the snapping result shows the snap, the position will be accurate. If you are zooming in to position things, you are not snapping at all. It appears to me that you are fundamentally misunderstanding a lot of how things are working in reality, and have come up with a set of technical superstitions that you are now struggling to shake off. You need to re-read my explanations above - they are correct.

Seriously - I wrote the snapping system, so I can say with 100% confidence that we NEVER snapped to the control handles on the selection box. You were either snapping to the key points on the ellipse circumference, or the mid line of the bounding box of the shape. You can still accurately snap to these positions. That is no different - so I am not sure what it is you cannot do exactly. If I drag out a new ellipse - I can still snap to those key points, and the bounding box and midline. Just as accurate, and still works perfectly fine as far as I can see. When you talk about drawing accurately - the snapping system is still as accurate as it ever was - in some places 1.7 is more accurate than 1.6. Provide a video or something - I think your problem is your understanding of how snapping is working or how you are trying to use the tools. Who else has "confirmed" this bug...? Your explanation so far just indicates that you were using the selection box handles as a visual cue - whether you understood that was what was happening or not.

It's probably always been done like that because defining the rules for how this behaviour would work in terms of the UI and the back-end logic are both very involved.

Unfortunately, the functionality you'd need for achieving this is not as straight forward as you'd think. The knockout effect actually works in the opposite order of the layer drawing. We generally apply effects downwards through the draw stack (layer order) - where as in my example, the red line would need to knock out the black stroke on the yellow line which would need to appear higher in the draw stack.

Yes - the selection box and it's blobs disappear. It doesn't affect your ability to snap to the object bounds (including its mid points), or any key points. Snapping to this stuff is not dependant on the object being selected - that depends on your snapping candidate settings. So - the only thing you've really lost, which you seem to find important, is the visual cue of where the middle of the object is from the selection box points, since what you thought you were snapping to is not actually the thing you are really snapping to - you've been snapping to something that happened to be in the same position as the selection box handles. Is that right?

I formed this example with two lines, then cloned them, set the stroke colour to black and increased the stroke size to give the illusion of a common stroke.

You know - you could just clone all your objects, move the clones to the back, apply a black fill and stroke, and it will appear like in your first example. You will have two set of objects though - but it is not possible to apply a single stroke to a collection of objects in the way you are describing.

Snapping to what handles?? Guides have never snapped to the control handles on the selection box - they are not part of the document, they are just blobs on the screen that you can grab to move and resize a layer. Guides have only ever snapped to layer bounding boxes. And the layer bounding box will be tight to the outline of the selected layers, which is still visible while dragging a guide. You may be thinking of the key points. An ellipse will have four on its quadrant points - when dragging out a new ellipse these will be at the top, bottom, left and right of the ellipse - coincidental to where the mid edge control handles will appear on the selection box. Try turning "Snap to shape key points" on....