IPv6

Neither would I, until this:
At least, @MattP was totally swift in fixing it.

@loukash...you are a star. Thanks for you efforts... I can use the app again now.
Hopefully they can fix it now that you have found the problem

Ha!
Hold on, here's the clue:
It's ye olde DEFAULT ENGLISH (UK) LANGUAGE BUG!
The (temporary) fix:
Change the app language from English (or Default) to English US (or any other language you can read).
English US is what I'm using anyway – and thus suffering from all those related bugs elsewhere – hence I've never encountered this issue until now.
P.S. Although seeing that others are using e.g. German and having this bug anyway, it's likely not the only "source". Worth to try though.

Procedural texture 
When can we expect this for those of us where this function is not working with extra controls
I am using Photo MAC version 1.9.4.242 on OS 10.12.6 and still no fix for Procedural Texture extra controls (sliders) which disappeared with 1.9.0 upgrade. I have never seen a company take so long to fix a regression of a valuable tools such as this.
 
I would pay more for the application if it meant you could hire more developers and fix bugs faster, so I could ultimately completely switch from LR and PS completely.

Status: Beta
Purpose: Features, improvements and fixes.
Requirements: Purchased Affinity Photo
Mac App Store: Not submitted
Download ZIP: Download
Auto-update: Available
 
Hello,
We are pleased to announce the immediate availability of the third build of Affinity Photo 1.9.4 for macOS.
If this is your first time using a customer beta of an Affinity app, it’s worth noting that the beta will install as a separate app - alongside your store version. They will not interfere with each other at all and you can continue to use the store version for critical work without worry.
This beta is an incremental update to the 1.9.3 version recently released to all customers (although it still installs parallel to the released version, as described above). We recommend that you use this beta in preference to the store version if you are affected by any of the issues listed below.
The 1.9.4 beta will have a performance focus as we circle back to clean up some inefficiencies which have crept in over time. If you notice performance improvements (or regressions!) over 1.9.3, or if you notice rendering bugs which appear to have been introduced in 1.9.4, please let us know.
Affinity Photo Team  
 
Changes Since Previous Beta
 
- Added the ability to open FITS files directly, with control over demosaicing.
- Performance and memory usage improvements when using placed images.
- Performance and memory usage improvements when using embedded documents.
- PDF import and export improvements.
- Significant performance improvements in low memory situations.
- Fixed small visual issues when switching back to templates from presets in the new document panel.
- Fixed gradient map adjustment rendering issues.
- Fixed expression input issues with decimal separators other than ".".
- Fixed issue whereby ISO speed was incorrectly reported for some images.
- Assorted other small fixes.
- Localisation improvements.
- Help improvements.
 
Changes Since 1.9.3
 
- Added support for Xtrans sensor images in astro stacking.
- Added GPU acceleration for blending ranges (in Advanced Blending).
- Further, significant, performance improvements for documents with many layers.
- Significant performance improvements when converting documents between ICC profiles / pixel formats.
- Fixed performance issues with previous build with certain GPUs.
- Fixed spare channel / mask editing.
- Assorted metadata panel tweaks.
- Further panorama stitching performance tweaks.
- Added a new "median" mode to the frequency separation filter.
- The gradient map adjustment now has a GPU implementation.
- Restored the GPU rendering improvements which were dropped towards the end of the 1.9.2 beta. The benchmark version is once again set to 1920.
- Improve performance when manipulating the selected layer immediately after loading a document.
- Significant performance improvements in low-memory situations, reducing use of the swap file.
- Panorama stitching performance improvements.
- Significant performance improvements for documents which contain flattened, opaque layers (usually the result of merge visible).
- Render EXIF exposure time as decimal if above 1.
- Fixed F-number always showing as "f/0" for Leica M-series cameras (and others).
- Fixed issue whereby LUTs would incorrectly report "Identity" as the description.
- Fixed potential crash when quitting with layers still on the clipboard.
- Fixed performance issues with CMYK documents when GPU acceleration is enabled.
- Assorted small fixes.
- Localisation improvements.

The projection, regardless of the shape (proportions), is distorted to match the original proportion of the image. The video is more clear. Even if you create a 1:16 dinomical projection plane on an image with an aspect ratio of 1: 1, it will stretch and shrink it to a 1: 1 square.

la.mov

Please, add "Affine filter" as live filter

Thats why I said that dedicated filter would be great .
Yeah its not as accurate or as convenient. But I think very few people knows about this imperfect solution - searching for "Zdepth pass in Affinity Photo" results in zero solutions just "use this or that plugin", no tricks for vanilla Affinity Photo. So I think this is as good as it gets for now.

Hi,
on Windows, with OpenCL active.
the gradient map ignores alpha.
Until 1.9.2.1035, a gradient map only affected pixels with alpha >0. On a transparent background, nothing changed.
Starting with Beta 1.9.4.1048, the gradient map changes all pixels, even where alpha is zero.
This is either a bug, or a change of functionality which totally brakes backward compatibility.
If you suspect the OpenCL driver: On the same PC, 1.9.2. does not shows this issue, with OpenCL active.
462.31 (as of 2021-04-12) latest available "studio" driver
Regards,
Timo

1.9.4.1048 beta gradient map.afphoto

Thank you and just sadly confirming that on macOS Big Sur 11.2.3 the Procedural Texture dialog in this beta still does not display the Custom Input value fields or sliders.

Status: Beta
Purpose: Features, improvements and fixes.
Requirements: Purchased Affinity Photo
Mac App Store: Not submitted
Download ZIP: Download
Auto-update: Available
 
Hello,
We are pleased to announce the immediate availability of the second build of Affinity Photo 1.9.4 for macOS.
If this is your first time using a customer beta of an Affinity app, it’s worth noting that the beta will install as a separate app - alongside your store version. They will not interfere with each other at all and you can continue to use the store version for critical work without worry.
This beta is an incremental update to the 1.9.3 version recently released to all customers (although it still installs parallel to the released version, as described above). We recommend that you use this beta in preference to the store version if you are affected by any of the issues listed below.
The 1.9.4 beta will have a performance focus as we circle back to clean up some inefficiencies which have crept in over time. If you notice performance improvements (or regressions!) over 1.9.3, or if you notice rendering bugs which appear to have been introduced in 1.9.4, please let us know.
Affinity Photo Team  
 
Changes Since Previous Beta
 
- Added support for Xtrans sensor images in astro stacking.
- Added GPU acceleration for blending ranges (in Advanced Blending).
- Further, significant, performance improvements for documents with many layers.
- Significant performance improvements when converting documents between ICC profiles / pixel formats.
- Fixed performance issues with previous build with certain GPUs.
- Fixed spare channel / mask editing.
- Assorted metadata panel tweaks.
- Further panorama stitching performance tweaks.
- Assorted bug fixes.
 
Changes Since 1.9.3
 
- Added a new "median" mode to the frequency separation filter.
- The gradient map adjustment now has a GPU implementation.
- Restored the GPU rendering improvements which were dropped towards the end of the 1.9.2 beta. The benchmark version is once again set to 1920.
- Improve performance when manipulating the selected layer immediately after loading a document.
- Significant performance improvements in low-memory situations, reducing use of the swap file.
- Panorama stitching performance improvements.
- Significant performance improvements for documents which contain flattened, opaque layers (usually the result of merge visible).
- Render EXIF exposure time as decimal if above 1.
- Fixed F-number always showing as "f/0" for Leica M-series cameras (and others).
- Fixed issue whereby LUTs would incorrectly report "Identity" as the description.
- Fixed potential crash when quitting with layers still on the clipboard.
- Fixed performance issues with CMYK documents when GPU acceleration is enabled.
- Assorted small fixes.
- Localisation improvements.

@GabeI realize the team is small and Affinity is racing with a half dozen other competitors, but that seems like an even greater reason to employ automated nightly regression testing to at least test the fundamentals are working. Imagine automatically doing hundreds of hours of testing every night. It would also allow you to focus on the more interesting/complex issues. It was a huge improvement in my life and sw when we employed it. Hope this helps.

Midpoints on Gradients not working on Pixel Layers [1.9.4.239]
Changing the location of the midpoints on any gradient on any Pixel Layer has no effect on the actual gradient. The gradient well on the Context Tool bar will update and if click on it will show the proper gradient. 
The gradient tool works quite well on objects and fill layers.
Not sure if this is related to the FX bug reported
 

Hi IPv6.
We are still looking into/fixing bugs found in v1.9x. Thanks for keeping at it.

Status: Beta
Purpose: Features, improvements and fixes.
Requirements: Purchased Affinity Photo
Mac App Store: Not submitted
Download ZIP: Download
Auto-update: Available
 
Hello,
We are pleased to announce the immediate availability of the first build of Affinity Photo 1.9.4 for macOS.
If this is your first time using a customer beta of an Affinity app, it’s worth noting that the beta will install as a separate app - alongside your store version. They will not interfere with each other at all and you can continue to use the store version for critical work without worry.
This beta is an incremental update to the 1.9.3 version recently released to all customers (although it still installs parallel to the released version, as described above). We recommend that you use this beta in preference to the store version if you are affected by any of the issues listed below.
The 1.9.4 beta will have a performance focus as we circle back to clean up some inefficiencies which have crept in over time. If you notice performance improvements (or regressions!) over 1.9.3, or if you notice rendering bugs which appear to have been introduced in 1.9.4, please let us know.
Affinity Photo Team  
 
Changes Since 1.9.3
 
- Added a new "median" mode to the frequency separation filter.
- The gradient map adjustment now has a GPU implementation.
- Restored the GPU rendering improvements which were dropped towards the end of the 1.9.2 beta. The benchmark version is once again set to 1920.
- Improve performance when manipulating the selected layer immediately after loading a document.
- Significant performance improvements in low-memory situations, reducing use of the swap file.
- Panorama stitching performance improvements.
- Significant performance improvements for documents which contain flattened, opaque layers (usually the result of merge visible).
- Render EXIF exposure time as decimal if above 1.
- Fixed F-number always showing as "f/0" for Leica M-series cameras (and others).
- Fixed issue whereby LUTs would incorrectly report "Identity" as the description.
- Fixed potential crash when quitting with layers still on the clipboard.
- Fixed performance issues with CMYK documents when GPU acceleration is enabled.
- Assorted small fixes.
- Localisation improvements.
 

This could also possibly explain a bit why there is such a huge delay when doing fast brush strokes with Hardware Acceleration on Windows. The amount of dots created at the beginning and end of each stroke is likely making the computing skyrocket. Of some reason this slowdown doesn't happen to the same extent with regular CPU computing, but the inconsistent brush stroke spacing likely doesn't help.
Good detective work, by the way!

I've had a hard time adjusting the brush to act in a natural way for drawing. I've compared with mainly photoshop and sketchbook pro and posted numerous reports about this. There are a few issues like jagged lines on low zoom levels and general inconsistent behaviour of hardness and size. Things you only notice when drawing or writing by hand on a tablet or Cintiq.
Now I think I found what causes the latter! I was able to isolate what is going on by setting the shape to a narrow ellipse and the stroke to large spacing. Look what the preview shows. There are 2 things going on here:
1 Inconsistent size toward the beginning/ending of the stroke, causing a sort of 'arrow head' effect
2 The increase of the amount of dots towards the ending is too steep. Meaning the spacing between the dots in the end is near zero and in the middle pretty large. Some decay in spacing is useful since the relative spacing between dots should stay the same. But it seems that AP does not take the dot size into account and at certain settings the decay is much to steep, causing too many dots to overlap. I noticed that in photoshop and sketchbook pro this decay is far less and generally in better balance with the shape size. This presumably results in their smoother line behaviour. One result of this steep decay in AP is that soft lines are much harder in the endings than in the middle and pressure sensitivity feels a bit 'off'.
All in all this explains the strange behaviour I was experiencing. This arrowhead effect is nearly invisible in the preview when the shapes are rounder, but in practice I always notice the inconsistent line behaviour because of this. 
Affinity photo:

A drawn line to show it's not just the preview:

 
photoshop:

sketchbook

 
lastly look at this soft line and how hard it gets near the endings. The steep decrease of dot spacing is what causes this. 

 
In all examples these are the dynamics settings:

In my opinion two things need to change:
1 The arrow head behaviour is just off and needs to be fixed.
2 The spacing between the dots needs to be rebalanced in order to have a consistent line behaviour throughout different settings of spacing, dynamics, hardness etc. Generally speaking the dot SPACING needs to be in balance with the dot SIZE and SHAPE. E.g. the thinner part of a pressure sensitive line should be equally soft as the broader part of the line. Also when pressure sensitivity is set to linear, the line thickness change should also be linear. This is currently not the case and my guess is the inconsistent dot spacing causes this. 
I hope this helps refine the brush behaviour for AP!
 

currently no... I tryed, but straightforward approaches does not produce such crashy file.
I`m getting files from freelancers sometimes - so can`t really tell how those mask were created //

It's your personal opinion, and that is okay. But my personal opinion is totally different. Not everything is perfect in Affinity Photo, but even in Photoshop not everything is solved in the best way. Every software has its own solutions. So use the software you are most comfortable with. It's your choice.

Hello.
FYI: Just downloaded and tested Affinity Photo 1.9.2 
This gradient tool bug is still there... 

You'll have to expand the strokes in order to get the 'level' cut-off that you want. In other words turn them into shapes and then you can have a horizontal line at the bottom. Rightmost is expanded and has the nodes moved, middle isn't.

Or... you could clip the bottoms.

Hi IPv6,
Thanks for the additional info/steps. It can indeed cause trouble along the way. I'm logging this/raising the issue with the dev team. Thank you for your support/feedback. Much appreciated.

In this particular case yes, this is the option... But still, this looks like shady way to accidentaly ruin something without noticing (changes may be subtle and zoom in and inspect every pixel to check every operation is not feasible). For example with the case above layer mask preview stays perfectly valid (so it is not properly depicting content in this case)

I found the case when masks starting to act weird. This is about document rotation, seems there is a bug with mask rotation. Steps:
1) rotate document 90 degrees
2) create mask
3) rotate document -90 degrees.
4) Link pixels to mask pixel data, created at step 2.
Linked data will be rotated and shifted, while it definitely should not. Look at video for reproduction

Looks like there is a problem somewhere. Visually everything will be the same, document is rotated back EXCEPT the mask. Because mask should be unrotated with the document as well, to the state similar to all other layers before step (1). But in fact it is still rotated and additionally shifted

Screen_Recording_2021-03-25_at_15_43_45.mov

Ah, I see. You also want to paste into mask layers, nested layers etc. Sorry, I didn't get this. "Merge down" with Cmd+E has indeed the side effects you mention.

Well today I'm getting it on your test file from the initial post.
I believe there have been some Metal changes so I'll investigate further and pass this to the developers - thanks IPv6