CM0

Thank you. Let me just clarify what I would hope could happen in this case. This issue, as seen by Affinity, is not a bug; however, it is also not a "nice to have" as seen by users as it is an issue that is breaking the user experience. Behavior that is misleading in a way that some could say is displaying wrong or incorrect information. Any user who experiences this will immediately think "bug" or something is broken. To simply categorize or place it alongside all the other new feature requests seems out of place. So yes, if features aren't tracked, then developers simply browse features as they have time, which I'm certain is extremely limited. This request was likely long forgotten with its importance to users. I am fine with letting the developers come up with a solution. Overhaul, new view mode or something else etc. Suggestion: I suppose a suggestion for Affinity to please consider would be a new tag for some features that are in the classification of "breaking user experiences" or "unexpected behaviors". I think this might be the optimal middle ground as it allows developers to find and consider such issues and prioritize them separately from the "nice to have" new features. This way, as a user, I would at least feel that the information I have delivered has been correctly understood as to its implications whether it is ever implemented or not :-)

Also as previously explained this is not a work around. There is no reality in which the UI lies to the user that is desirable or would not be seen as a bug to users. I understand this is by design, but it is severely impactful in a negative way to our work and dismissing its importance that it is by design is extraordinary frustrating to users. Previously you had expressed interest in solving this issue and I appreciated that interest. Exactly how does a request ever get picked up by developers? That request has indicated it is impactful to many users. Has this been logged for development into their tracking system? Often we are told development will take a look at certain issues, is development even aware of this discussion?

@Chris B Could we please get a proper issue logged with development? It seems as @NotMyFault has pointed out, this has been an issue reported by many people, but likely confusingly miscategorised. Please take note of this comment on a previous post - This thread in the above issue indicates that it is impactful to many people and likely contributes to lots of miscategorised issues/bugs. The previous issue has been tagged feedback for v1 so probably is not getting the focus and priority that it needs. If we could get focus on this better described problem, then we can close or consolidate proper notes into one issue to log with developers.

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?

Thank you for the reference. I suggested exactly what you stated earlier in this thread. We need at least a preview mode for accurate rendering. Unfortunately, there a lot of such issues that don't get the priority they deserve as they are so poorly understood. Many likely have encountered such problems, don't know how to describe it and goes without being reported or it is diluted by being reported under what would seem unrelated topics such as how this thread started.

Here is another file that I'm attaching from Affinity that demonstrates to a much greater degree the problem of the rendering accuracy. As you zoom out, the image changes significantly, more than just color distortion. rendering view accuracy test.afphoto

In my continuing efforts to break down and document the sometimes odd Affinity behavior, I'm now focusing on the peculiar blending behavior of passthrough mode. Previous explanations have been something like "it is due to blending order" However, if this is the case, we should be able to manually replicate the exact same behavior. I have been completely unable to do so. I can not replicate, nor explain it. Furthermore, the behavior would not seem to be expected or desirable. This is a sample using passthrough And this is the same using normal There are specifically 2 problems (bugs) with the previous image: Colors are deformed. There seems to be desaturation or some additional oddities. Pure red blends normally. However, anything with mixed colors or partial grays results in undesirable color transformation. There is banding in the image. It seems the underlying smooth gradient is somehow clipped and is no longer a smooth ramp. This is most evident in the middle gray layer. If you sample the colors, you will see the values of gray do not change at all until you cross the midpoint of the image. These conditions only occur when we have a mask or erase mode layer like the following: The mask also must have partial transparency. It is the area of partial transparency that produces the unexpected results. But this must be done with a mask, as if we place an image with partial transparency it will blend fine. I had assumed this is likely due to the mask being applied to the underlying layer ( in the above would be fill layer ) as part of blending/rendering and then blending a second time as part of the group with the fill again. However, you can't reproduce this effect by manually doing these steps. No such combination of doing that with any blend mode available in affinity will result in what we observe with passthrough. No matter how you blend with either the black fill or an empty layer or multiple merges results in what we observe. Additionally, if you add the mask as a child layer of a child, the problem still occurs and in that configuration the mask should not be affecting the group's underlying layer. So then what is happening? I've attached the sample document for anyone that would like to attempt to further explain. What to look for and when to use work arounds: Anytime you are using passthrough combined with some type of applied transparency (mask, erase mode) you likely will not get the expected result. Consider ... Don't use passthrough. Break up your composition in some other way. This might be difficult depending on your composition. Create copies of your mask and apply to every layer individually that is a child of the group layer. The mask must be attached to the masking position. If added as a child layer of a child layer the problem will resurface. This is another odd behavior. passthrough mode blending.afpub

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

No, that is not a way. It is not a work around. It doesn't do the same thing. There is a reason I created the feature request.

Being able to see in realtime the effect of all the selection modification tools in quick mask mode. They are all currently disabled or either they don't update while viewing in quick mask. Take 'select sampled color' as the best example because it is the hardest to use. You can toggle quick mask while the tolerance slider is visible, but it will not update until you click 'apply'. If it is not the result you want, you have to start over.

Sorry, that doesn't solve any use case I posted.

In the spirit of Affinity doing everything live, it would be awesome if we could use the selection modification tools while viewing in quick mask mode so we can see exactly the effect live. As it is now, I have to try something, view it in quick mask, then undo retry again, view in quick mask, undo retry etc. It would be very helpful for viewing feathering effect as well as using along with 'Select Sampled Color'

VSCode was scriptable from the initial release. Affinity has already demonstrated this is work-in-progress. Some of us are excited about this news. Everyone is well aware of how long features have been desired. It really isn't productive input to this particular thread.

Has anyone had an opportunity to review or consider? Can we at least start discussion with the Gaussian blur issues?