Ben

It is.

Is there an error code?

We don't snap between geometry, only bounds of an object. The exception is for points when using the Node tool, or positioning the corner of an object bounding box. You can use the Node tool, and snap a guide to the nodes and handles of the currently selected curve objects. I think you only need to select the object, not the individual handles for that to work. (off the top of my head I can't recall if I added this for 1.8 or if it's already in 1.7). I could add snapping of guides (conceptually any infinite line) to curves in an object, BUT that snap could potentially have many potential targets. To now, people have been happy with snapping to bounds.

It's being looked at...

To remove a handle, just Alt+Click it. That will deal with request #1.

I have a whole load of ideas for making the procedural functions better. The full vision is going to take a lot of work though, so it might not happen for a while yet. I had thought about samplers, gradients, etc, as well as a visual way of building the functions.

Thanks for your help with this bug. We have now resolved the problem and will make the fix available in the next release of Affinity Photo on your platform.

ok. There is a bug - it'll get fixed soon. It's got nothing to do with integers - it's to do with optimisation of the "(R*R)-T" pattern in the equation.

Sorry - another thing to note. The Fit To Plane method works best when you adopt a Cube based grid. That allows us to calculate the correct scaling we need to apply. That is because the axis lengths are determined from a single scaling factor applied to the cube. If your grid is made using the Advanced Grid option (with Two Axis Custom), then it will generate an incorrect scale in one axis - leading to a shear effect like you are seeing.

That's because we do not currently use true ellipse representations. That will come at some point. What you have is your original circle shape with an applied SSR transform. The SSR effect does just that - it takes your 2D geometry and applies the Shear, Scale and Rotation to put the object into to projected system. The ellipse method you are describing attempts to put a non-sheared ellipse in 2D space directly into position to appear as a axonometric projected circle, by applying a rule that produces a good enough projection of a circle (incidentally that approach is also not very accurate, but that's another discussion). It's not the same approach. Our approach attempts to maintain the original objects editablilty in terms of the original object. If you take a shape and project it, you'll still be able to adjust the shear and rotation as a continuation of the initial SSR transformation. Our approach also applies to any axonometric axis set. The isometric approach you are describing only really works well for isometric. You'd need to get into a lot more maths to apply it to arbitrary axes.

Thanks for your help with this bug. We have now resolved the problem and will make the fix available in the next release of Affinity Photo on your platform.

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.