CM0

Yes, this will be great. Ultimately what will make Affinity a top tier platform will be having a marketplace for plugins/scripts. So that you can just click a button and add a feature/script to your application. Just like in the VSCode editor. As a developer myself, this would be very exciting to be able to start providing enhancements for Affinity.
I know we can't everything at once, but yes this would allow for a much better and integrated experience for script and plugins. Having that professional level of integration where we can add capabilities that just naturally fit into the workflow and new buttons, menus, context selections etc are available where they should be.

It would seem this is in reality the most critical issue above all others. :-(
Sometimes I don't even know why I'm here. I think exactly zero bugs have been fixed of all those I've submitted over the years. I really wish we could have a release that is just catchup on all the issues.

This wasn't about you. Do you have something you would like to add here that is relevant?

It would seem this is in reality the most critical issue above all others. :-(
Sometimes I don't even know why I'm here. I think exactly zero bugs have been fixed of all those I've submitted over the years. I really wish we could have a release that is just catchup on all the issues.

Welcome to the club of users who deeply share this pain- a great product with some innovative aspects, but far too many bugs and quirks ignored for too long.
My theory is that the company decisions are driven by some owners / developers/ product experts who have totally different priorities about what matters vs. what some (existing) users like you think.
Bug fixing pleases existing users. New features attract new paying customers.
If you were developing software for customers whose live literally depends on fixing bugs (aerospace, medical devices, …) the priorities could differ.
 

Currently, Affinity Photo does not provide a absolute trustworthy preview of the current document.
For any zoom levels not equal to 100%, you get misleading rendering of noise and unsharp mask filters With View Mode "Bilinear", you will always get false rendering on pixel level at hard edges Even with zoom level 100%, you could get get false rendering when dealing with pixel art For zoom level below 100%, you could get completely wrong colors caused by resampling (same bug report above) Many live filters can introduce rendering artifacts at any zoom level, including 100%, leading to severe deviations from final result, especially when combined with blend mode "difference" The false color by resample issue could bite you at almost any zoom level except 400% and integer multiples of 400%  
The only way to get a reliable preview of your document is to either
Export - leaving the application The Export Preview is cumbersome to use (modal windows, not able to use navigator panel) Merge visible - introducing superfluous temporary layers, must be created on top of layer stack and deleted after use. To overcome all these issues, it would be helpful if Photo would offer an "absolute trustworthy preview" move, similar to Designers View Modes.
Requirements:
No color artifacts (false colors) by resample in case of zoom <100% (use color-correct average, not false sub-sample) utilize full display color depth (10-bit, 12-bit, …) to avoid banding in case of 16-bit documents 100% accurate rendition of result ability to zoom to any level (at least -8x to + 8x) Ultimate priority on accuracy, no priority on performance. Options to deal with non-opaque pixels (color of matting background), switching options while in preview Regular keyboard shortcuts and mouse actions to zoom / pan

I'm happy to report that SDK development is progressing well. We are steadily working towards exposing enough app functionality to make useful plugins, but there's still quite a lot to do before we can consider even a "technology preview" release. 

Yes, this was the very reason for the enhancement request as it would be a significant productivity enhancement to be able to preview live.

It's now been about 6 months since Tim France teased with some scripting news.
Given Adobe have just announced price increases for Creative Cloud, it would be nice if we could have any sort of update on any progress being made. Even the smallest glimmer of hope of when it might find its way into a beta.
It's hard to believe I started this thread over 5 years ago.

Thank you for the information and I have passed the information along to the relevant team

@CM0 thanks for sharing this, as I'm often left wondering how and why layer FX render as they do. While this doesn't solve the problems, it does help develop an understanding of what works, what doesn't and how to approach using layer FX.

Using Affinity for several years and spending hours in it per day, I have been constantly troubled by inexplainable behaviors that when reported never seem to have adequate explanation. Is it a bug or working as intended but in some bizarre way?
Well, I just spent many hours over the weekend finally attempting to map out in detail how everything is rendered in hopes to bringing some sanity to my understanding. The exercise has been beneficial in that I can now finally explain many of the oddities; however, I can't confirm whether they are intended, but can point to why they occur.
I hope that Affinity could confirm/document the true rending order. This is very important as it helps us to understand how to properly create compositions as well as sort out bugs from simply lack of understanding. The exercise of documenting would also likely bring to light some of the non-intuitive behaviors such that hopefully they could be addressed.
It would be great if the rendering were simple, something such as child layers > current layer, FX, blend ranges etc. However, what I discovered is that it is anything but simple.
This is my best attempt so far, it may not be perfectly accurate, but has been good enough to explain all of the odd behavior I have seen.
Rendering pipeline order and rules
Child layers of group
(if passthrough) bottom of stack is rendered on top of layer below group layer
rasterizing this layer may result in a different blend.
use merge down or merge visible to retain original on screen view.
(else all other color blend modes) The bottom stack starts as if on top of transparent.
this is why for the bottom layer of the group, its blend mode will usually have no effect and blend ranges for underlying will have no effect as there is nothing to blend with.
Transparency tool effect and Masks
Adjustment layers | Live Effect layers
Layer FX ( rendered to temporary FX layer )
Exception - Gaussian blur will result in immediate merge down as well as blend range underlying being applied to source instead.
Exception - when combined with of the following then will be applied later after underlying blend ranges
Other layer FX
Preserve Alpha
Current layer is any blend mode other than ‘normal’
Exception - Child layers
Effects are applied to the child layers after child step 4. Or in other words, applied after layer FX merge down. So blend ranges underlying blend is not utilized from children when layer FX are rendered. The fully rendered result of children is not used!
Blend Ranges ( source blend )
Exception - Gaussian blur disables source blend unless combined with another FX or preserve alpha.
Exception - ignored if Live layer is applied to current layer and current layer is an image layer.
Layer FX previous rendering from step 2 merged down
Blend Ranges ( underlying blend )
Exception - This operation skipped when Gaussian blur enabled unless combined with another FX, preserve alpha or blend mode other than ‘normal’
Exception - ignored if Live layer is applied to current layer and current layer is an image layer.
Layer FX ( Gaussian blur exception )
Gaussian blur applied at this step when combined with other FX, preserve alpha or blend mode other than ‘normal’
Merge using blend mode (Multiply, Screen etc)
I have found additional oddities, but still can't sort out the rules yet. For example Bevel, outline, outer glow and outer shadow all render in a different way than the other FX in certain conditions, but can't yet articulate the reason.
These are some major notable observations from the above:
Gaussian blur seems to be the greatest offender of unexpected behavior. So much so it actually changes the rendering order and will completely flip the blend ranges depending on certain conditions. Rendering does not seem to be serial. It is interwoven or forked. See step 4 layer FX. This adds substantial confusion when trying to figure out what is the right order for an effect you imagine. It also makes some combinations impossible. Live FX completely breaks blend ranges applied on a pixel layer. I have refrained from specifically listing anything as a bug although I doubt anyone finds the above as desirable. What I hope is that we could finally officially document what is supposed to happen and from there figure out how to improve this to something that works as desired and is intuitive whether we call it bugs or enhancements we just need solutions.
I make a lot of complex compositions and the above always costs me hours of work attempting work arounds for unexpected behaviors.
Attached is a test file I used to evaluate much of the above. The key parts is that it has blend ranges for both source and underlying applied in a way that is easily recognizable. There is a character '1' on a blue gradient background and it is blended such that the top of the one is transparent for the source blend ranges and the bottom is transparent due to the bottom blend ranges. Experiment with applying FX directly to the image or parent group in different combinations.
 
Render order testing.afpub

It's probably easier to do that after exporting sliced images from the artboards then, so to fill areas on a bulk of images. - One free tool predestinated for such tasks is ImageMagick, which nearly offers everything one can imagine in this regard.
With just using Affinity tools here instead things will get difficult and laborious. As first ADe doesn't offer any automation, or bulk processings except the Export Persona, and using the ADe files in APh then for applying some matte macros and bulk exporting can be adventurous.
There were some older threads where people needed some custom image size specific padding solution via APh, which might give you an overall idea here for using the Affinity apps or some third-party script solutions ...
 
... but all that can be done more easily via a tool like ImageMagick then.

Thanks All - we've got a fix for that bug @Frozen Death Knight described, will get it in before another RC later this week.

It is never expected behavior to have the display to differ from what you export or rasterize.
It is impossible to create an output to the desired specifications under these conditions.
So what is the solution to having a perfect representation of the current view? Also, where is the documentation that defines in detail the rendering pipeline sequence for layers, groups, effects etc?
Note:
I took the same image and applied the same effect in Krita. It does not have this problem. Each method of rasterization results in an image that matches the view precisely. It works exactly as a user would expect. An export or rasterization that doesn't match what you see can only be a bug.
 

@Chris B FYI, you are probably already aware, but an easy test to perceive the rendering accuracy is to merge visible, then set that layer's blend mode to difference.
In Affinity, you will see as you zoom out, it is less accurate as the image begins to appear once you zoom out from 100%
FYI, In Krita, the difference mode is nested under 'Negative' group of blend modes. 
Doing the same in Krita, you can see the display is pure black no matter the zoom level.

This is because we use mipmaps for speed and efficiency reasons. I do not know if that is exactly why we do see those slight changes.
I'll pull the file down and have a look - thank you  

I added the file to the dropbox. Named "krita rasterize test".
It is the same image as used for the Affinity example.
What you should notice, is that when you zoom in and out, there are no artifacts to the image that you can perceive. I've always noticed Affinity sometimes subtly changes the image when zooming in and out. Just small artifacts. But you do not notice that when doing the same in this Krita example.
You can rasterize this example in Krita by right clicking on the group and selecting either "flatten image" or "merge group". When you do so, the tone of the red seems to be preserved perfectly, unlike in Affinity where it seems a bit faded after the rasterize.
If you want to make changes to the live adjustment, right click on the filter layer and select "properties"
FYI, I did this using Krita 5.1.5 on Windows 10.
Hopefully this will be helpful. Thanks.

I could give you my Krita file if you are interested. Although, not sure this is the right place to share such :-)
But in the interest of making Affinity better, just let me know.

I could give you my Krita file if you are interested. Although, not sure this is the right place to share such :-)
But in the interest of making Affinity better, just let me know.

Krita has live layers as well, called filter layers, and that is what I used. It is open source, maybe you can take some inspiration for how they have achieved this.

You've posted in the Bugs forum. Serif will handle this topic when it reaches the front of the queue.

Your frustration with that is completely understandable.
Consider two categories of objects/layers:
A - Live Filters and Adjustments B - all other objects/layers except Masks (a Group can contain stand-alone Masks in Affinity, but I want to leave that out of this message since that is an unusual, although useful at times, feature.) When a Passthrough Group contains only A, it's the same as Pass Through in Photoshop and other apps - the content can "interact" with the scene below the Group.
When a Passthrough Group contains only B, it's the same as Pass Through in Photoshop and other apps - the content can "interact" with the scene below the Group.
Now here's the problem you came across. When a Passthrough Group contains both A and B, it's inconsistently unlike Pass Through in Photoshop and other apps. In Photoshop and other apps, all content of a Pass Through Group can "interact" with the scene below the Group. However, in Affinity, the B content can "interact" with the scene below the Group, but the A content cannot. Affinity considers the Group to have Normal blend mode for the A content while having Passthrough mode for the B content.
I realised and posted a workaround for the problem scenario a few years ago, but it isn't often repeated. Because the B content can "interact" with the scene below the Passthrough Group, put a white object/layer with Multiply blend mode and covering the entire canvas/page as the bottom member inside the Group. That provides a representation of the background scene with which all other content of the Group can "interact". The white object/layer can be a vector Rectangle or Fill Layer or Pixel object, whichever you prefer, but I generally use a vector Rectangle because there can be problems with the display of a Fill Layer in apps other than Photo.
Serif representatives have repeatedly insisted the dual personality of Affinity's Pass Through blend mode is "by design" and not a bug.
Still leaving aside stand-alone Masks contained in a Group, you'll be familiar with masked Groups. Well, you will soon come across indisputable, and never denied, many years old bugs in the rendering of masked Groups, but that's a story for another day.
 

I agree with much of what you say.
Was just providing some info and explanation.
Maybe you'll get a response from an involved developer of the software.

This thread will be notified when there is anything to look at, but that will not be 2.3 beta. There is a lot still to do