Ben

I've also spotted something else about this document which will hammer snapping performance.  A lot of the layers are made up of other nested "Layers" or "Groups".  There is nothing wrong with this in itself, but this pattern is unfortunately bad for snapping in this scenario.
 
If you have a top level Vector object, such as a rectangle, with child objects inside of that, the snapper can work out the bounding box of that layer by just calculating it for the rectangle (since its children will be clipped to it).  For "Layers" or "Groups" the snapper has to work out the bounding box by summing up the boxes for all the child objects.  This works recursively until it reaches a vector or pixel object for which it can calculate the real bounds.  Snapping in your document would be loads faster (with the options I mentioned before) if your top level layers were Vector objects (even if they are just used for clipping, with no fill or line colour).
 
This also applies if you have a surrounding rectangle with lots of objects as sibling objects in your document tree (such as your control panel images).  This would snap better if the details layers were children of the surrounding rectangle object.
 
For people making reusable symbols, this will be a good approach to follow.  We may release some "good practice tips" for forming Symbols and Assets when we have a few more snapping features in 1.6.
 
I also have some ideas for caching bounding boxes which will help performance, but a combination of this with well structured documents will give the best performance.

Save As is used to save the file as a new document in Affinity's native format.
Export is used to save in non-native formats.

True.  We set the size way back, just before Retina really took off.  Arguably, it becomes less of an issue as everything gets faster and bigger.  So, we can look at this again when someone has time.
 
An option would be a good way forward as we don't want to hobble slower/older machines.

True.  We set the size way back, just before Retina really took off.  Arguably, it becomes less of an issue as everything gets faster and bigger.  So, we can look at this again when someone has time.
 
An option would be a good way forward as we don't want to hobble slower/older machines.

That's exactly what I was wondering....
 
We don't store a flattened version of the document in Affinity files, for a couple of reasons (unlike what other wasteful file formats might do).  We have a max sized raster preview that we use for the quick look previews.  This is rendered at a maximum resolution (currently a max edge of 512 pixels) to limit time taken during saving to generate the preview images and he file size overhead of the additional data.
 
For vector files particularly, it would be a very bad idea to try to store a full resolution raster image as the size and DPI could lead to massive raster images.  So, we'd have to put some cap on it regardless.

How so? A preview is exactly that, a preview.

Wow - I think this is one that slipped under the radar.  I'll have a look into it once we're past 1.5 MAS release...
 
So many snapping changes in 1.5, it's easy to forget a couple.

Wow - I think this is one that slipped under the radar.  I'll have a look into it once we're past 1.5 MAS release...
 
So many snapping changes in 1.5, it's easy to forget a couple.

Another tip - it's better to use "Groups" than "Layers" when creating symbols or assets as it enables you to select the entire symbol when clicking on spread. "Layers" click through, and so you will select one of the child layers, and not the whole layer.
 
In a UI prototyping situation, you'd want to be able to easily select the whole object and move/snap it.
 
"Layers" currently do not pass through for snapping bounding box calculations.  Anything in a "Layer" will currently not get added to snapping when using the "Immediate layers" option.  I'm in two minds as how this should work.  It's not really a bug, more a question of expectations.  I'm thinking that I might change it so they behave as "Groups" for the purpose of snapping.  Guess we'll have to see how this pans out when people use it.

This is because you have Candidates set to "All layers".  You really DO NOT want to use this option for big complicated documents.  It'll try perform snapping with every layer in the document.  When you've got all the options turned on (like you have) that's a lot of calculations.
 
I only added "All layers" for people who insisted they needed to snap to everything and want to shoot themselves in the performance foot want full snapping for simple documents.
 
Simple resolution - don't turn everything on.  And use either the "Candidate list" or "Immediate layers" modes only.  The array of options is there so that people can perform just the type of snapping they need without both a performance and usability hit.  We have provided some Presets to also help with this.
 
After the MAS release of 1.5 I plan to add time-outs to snapping to help alleviate this kind of issue, but ultimately the choice of what snapping to enable is down to the user. With great power comes great responsibility.
 
I am also adding the option to mark layers as excluded from snapping to help exclude the child nodes of top level layers/objects.

I've also spotted something else about this document which will hammer snapping performance.  A lot of the layers are made up of other nested "Layers" or "Groups".  There is nothing wrong with this in itself, but this pattern is unfortunately bad for snapping in this scenario.
 
If you have a top level Vector object, such as a rectangle, with child objects inside of that, the snapper can work out the bounding box of that layer by just calculating it for the rectangle (since its children will be clipped to it).  For "Layers" or "Groups" the snapper has to work out the bounding box by summing up the boxes for all the child objects.  This works recursively until it reaches a vector or pixel object for which it can calculate the real bounds.  Snapping in your document would be loads faster (with the options I mentioned before) if your top level layers were Vector objects (even if they are just used for clipping, with no fill or line colour).
 
This also applies if you have a surrounding rectangle with lots of objects as sibling objects in your document tree (such as your control panel images).  This would snap better if the details layers were children of the surrounding rectangle object.
 
For people making reusable symbols, this will be a good approach to follow.  We may release some "good practice tips" for forming Symbols and Assets when we have a few more snapping features in 1.6.
 
I also have some ideas for caching bounding boxes which will help performance, but a combination of this with well structured documents will give the best performance.

This is because you have Candidates set to "All layers".  You really DO NOT want to use this option for big complicated documents.  It'll try perform snapping with every layer in the document.  When you've got all the options turned on (like you have) that's a lot of calculations.
 
I only added "All layers" for people who insisted they needed to snap to everything and want to shoot themselves in the performance foot want full snapping for simple documents.
 
Simple resolution - don't turn everything on.  And use either the "Candidate list" or "Immediate layers" modes only.  The array of options is there so that people can perform just the type of snapping they need without both a performance and usability hit.  We have provided some Presets to also help with this.
 
After the MAS release of 1.5 I plan to add time-outs to snapping to help alleviate this kind of issue, but ultimately the choice of what snapping to enable is down to the user. With great power comes great responsibility.
 
I am also adding the option to mark layers as excluded from snapping to help exclude the child nodes of top level layers/objects.

There are a number of reasons.  Often games use known or fixed pipelines, and heavily preprocessed data. The editing phase and optimisation of input data was done way in advance of it being used in the render pipeline, sometimes at considerable cost that couldn't work in realtime (or 30fps).  Render pipelines are also often ordered and restricted for performance reasons, and certain tricks used to limit wasted calculations.
Games also only require the data to go in one direction - to the graphics card (and display).  They can be loaded with managed inputs, but the results and intermediate stages can be kept on the graphics card, without the need to pass it back to main memory for other processing. Transferring pixel data back and forth between memory on the card and main memory has historically been slow.
 
So, it's not a good comparison between games and creative software.

Regarding the comment about Affinity/Serif not caring about Macs anymore, they just released updates to the retail versions of Designer & Photo (to version 1.4.3) to iron out a few problems with the just released macOS Sierra. They are available via the Mac App Store > Updates category. The 15th (!!) update to the Designer for Mac beta was just made available yesterday. There has yet to be a retail version of either product released for Windows. They have said several times that the Mac & Windows products are being developed by two separate teams, & that development for Macs has not been slowed by development for Windows (or visa versa).
 
You may also have noticed if you browse through the Questions forum, the staff spends a great deal of time answering questions about the Mac products, & that for generic questions that would apply to both operating systems there still is a preference for using OS X symbols like ⌘ & ⌥ for keyboard shortcuts & such.

1) Performance while working should not be affected.  When a save happens, there will be some work being done to save any new pixel data.  Because of how we structure our documents, only portions that have been added or altered are saved.
 
The auto-backup feature will cause a save at intervals, but this can be halted if you are in the middle of drawing, so again should not affect using tools.  If you perform a full save there will be time taken to save any new pixel data, and you will have to wait until the save has completed (with a progress bar).  The more drawing you have done, the more pixel data will need to be saved.
 
With a full save, we also do periodic clean-up of your file (to remove wasted space).  This may take additional time at the end of your save, which will be longer if your document history is longer and contains lots of pixel drawing changes.
 
2) The file size will obviously be much larger - you are going to be saving the incremental changes to the state of the document on top of the data required for the document itself.  Again, we only save the small changes at each increment, so it will be as efficient as possible, but saving history does mean that there is a considerable overhead in file size.  To test this you can always save a copy of your file without history and compare the two file sizes.
 
The increase in size will depend largely on how you work.  If you over-draw pixel data a lot, the history will have to save more pixel data in addition to the pixel data required for the document.  If you just add more new pixel data (new layers), then the history will just reference the pixel data used in the document, so the overhead will be less.

It's like we thought of everything...   ;)
 
Shift doesn't do anything when combined with Ctrl, as I always create the shapes with equal aspect ratio anyway (since only one axis of the shape can be defined by the distance between the two points).

Just to be clear - you are trying to snap when creating the circle?  Or creating the rectangle to fit into an existing circle??
 
Phase 3 is already possible in this diagram.  When creating a circle, use Ctrl+Cmd to drag out a circle from it's centre, and define it by radius.  Start on the bottom right corner of the rectangle, and finish at the top left.
You'll want snap to bounds on (or snap to key points will also work for a non-aligned rectangle shape).
 
Ctrl enables you to define a shape (circle in this case) to fit between two points.
Cmd creates a shape from it's midpoint.

The snapping candidate system has been in there right from the start, and there have been numerous threads and tutorials about it.  It provides exactly the "select what you want to snap to" functionality you want, but probably not in the way you imagine.  See the tutorials.
 
"Exclude from snapping" was already done but will be in the 1.6 Beta (after we release 1.5 MAS and go into the next Beta cycle).  It won't make 1.5 as we have a freeze on UI changes now.
 
The "snap to everything" modes are already in 1.5.  In the snapping options, chose "Immediate layers" or "All layers" form the Candidates dropdown.  Immediate layers will only snap to a layers siblings or parent, so it excludes children of siblings and anything above the parent.  For most layout tasks this should be preferable if you organise your document sensibly - of course, if your document is flat, you are going to end up snapping against everything.
 
As for the last paragraph - I think you are going to have to draw a diagram to explain what you mean.

The first reason snapping doesn't work after opening a file is if your are in "Snapping Candidates" mode.  The candidate list is not saved, so you have to re-add you candidates when reopening.  To improve on this, we now add candidates when objects are manually selected/deselected.  Alternatively, we now have other modes for the choice of snapping inputs that snap to objects in their sibling list in the document.
 
There was a bug I just fixed where guides didn't snap when being created.  There should be no reason why you can't snap objects to guides though - as long as you have the option turned on.  If you identify a problem, could you capture a video of it, or send us a test file if it is recreateable.
 
Thanks.

I'm not sure I understand what you are saying...?
 
'Snap to cente' is an extension of snapping to bounding box - i.e., snapping to the centre of the bounding box.  You will have to demonstrate the problem where snapping to edge of the bounding box is causing you a problem when trying to snap to the centre. I have not seen another app that only snaps to centre, but I have seen a few that only snap to the outer bounds of an object.  So, we have that option.
 
What do you mean by "threshold"?  Are you referring to the snapping tolerance?  That just defines the distance in screen pixels at which you want things to snap when editing.  It is really a metric for defining how 'responsive' or 'active' snapping behaves.  Lower values for tolerance will require you to move objects more closely or precisely before they snap, higher values will make it snap more readily.  It is also not a value in terms of document units - it is always in screen space and is entirely independent of zoom levels or document units.
 
And, trust me, the snapping tool is getting a lot of attention.

I'm not sure I understand what you are saying...?
 
'Snap to cente' is an extension of snapping to bounding box - i.e., snapping to the centre of the bounding box.  You will have to demonstrate the problem where snapping to edge of the bounding box is causing you a problem when trying to snap to the centre. I have not seen another app that only snaps to centre, but I have seen a few that only snap to the outer bounds of an object.  So, we have that option.
 
What do you mean by "threshold"?  Are you referring to the snapping tolerance?  That just defines the distance in screen pixels at which you want things to snap when editing.  It is really a metric for defining how 'responsive' or 'active' snapping behaves.  Lower values for tolerance will require you to move objects more closely or precisely before they snap, higher values will make it snap more readily.  It is also not a value in terms of document units - it is always in screen space and is entirely independent of zoom levels or document units.
 
And, trust me, the snapping tool is getting a lot of attention.

Well, that is a false overgeneralisation, R C-R. You will always have to take the red control points into account. It is not just about creating shapes, but also about controlling them in a specific way …  ;)

We like to hide the useful stuff in menus...  ;)

All my kids started computer drawing on my old Amiga, using a program call Deluxe Paint. All four became proficient, w. 2 getting degrees in fine arts. My younger daughter did not, but is now doing freelance design. She did her first computer drawing at age 3 1/2. We still have the glorious 90 dpi print out, called "Teddy bear falling off a mountain.".
 
Yesterday she stopped by, and so I showed her AD, and some clumsy work w. my new tablet.
 
Most of her work is in paint programs, not sure which, and I thought it might interest her to show how AD used both vector and bitmaps, particularly the vector brushes.
 
She was intrigued, and was also delighted with the performance. At one point, as I messed around varying the cog shape, she went "Whoa!" She said several times that some of what I showed her would have been very helpful in several recent jobs. She noted there were more blend modes than in Photoshop, which she has.
 
You folks at Serif have impressed someone who is quite proficient and practiced. Congrats.

KUDOS to Affinity for such a fine program - and to ALL THE MASTERS with all the great solutions - MUCH appreciated!