CM0

When painting, the blend mode does not work with the layer beneath, it works with the brush and the current layer. Yes, you can change the blend mode of the current layer, but then you can't mix multiple blend modes without adding more layers which can get messy. I suppose that is a work around in some cases, but not all. Thanks.

Many tools have the option to use layers beneath. However, I don't see any way to do that with the basic paint brush. I want to paint on a new pixel layer, but have the blend mode work with the layer beneath so that I can paint non destructively using different blend modes. Is this possible?

Thank You! Fixing this will help me tremendously!

Yes, it is completely broken. If Affinity wants to take the position the apps aren't designed to work together, then I'm out. That was the most compelling feature that Affinity has. Seems this should be a priority to fix. Note, they are also technically broken in Photo as well. If you attach the filters to objects and move them within the canvas you will still run into problems, just don't hit that use case as often. This also shouldn't be a very difficult problem to fix. It is likely just a matter deciding on a different point of reference for anchoring the filter. I would have rather had these problems fixed than any new feature added V2. It would have been more useful to my workflow.

Yes, I agree on the user input, user input is an essential part of Agile development which ensures the customers have high bandwidth communication to the dev team as all features are developed alongside user feedback. Iterative development, where the users get to experience a feature during the development cycle and influence the end result. However, disagree on the forum. It is simply not a good tool to be able to understand beyond the very problem you stated. The most vocal will be that which rises to the top of awareness. This is because the forum can't be organized, ranked or prioritized in any meaningful manner. Things get lost in the forum as evidenced by mods who sometimes respond, "let me ping a dev again on that topic". There is no systematic way to understand exactly how many customers are impacted by an issue or want a particular feature.

Could Affinity please look into fixing this. I normally use 40-50 art boards per project. Essentially, I have to operate as if the many of the live filters do not exist.

It has been one of the things I've brought up many times. I've been on the other side, as I'm a developer myself. What I know is that my company would never be able to figure out the right priorities from a forum. A forum just doesn't have the tracking capabilities to know how many people are interested in a particular feature/bug and rank them properly. We also did iterative development year round. So users could always checkout progress of a feature and give feedback before it was completed. This often saved months of rework that might need to be done. We had opportunity to change the implementation before we had already put in too much work. We also would have team calls with heavily invested users/partners to discuss potential upcoming features before work started so we could get a lot of good feedback before starting. And nothing discussed on the call was ever guaranteed. That was made clear, but the calls were useful at giving more feedback on user interest as well to help rank priority. I would really love to see Affinity at least engage with some of the major content creators for Affinity. Have a public recorded round table discussion. I think that would be a lot of free marketing for Affinity as well. I could see a lot of excitement around a company willing to do such type of engagements.

Affinity essentially traded complaining about roadmaps etc to complaining about no roadmaps and no communication. I don't think this tradeoff was a win by any means. Other companies successfully engage with their users. There is no magical reason that Affinity should be different. Complaining about lack of knowledge is literally useless to the company as it can't be used in any meaningful purpose. Complaining about roadmaps etc is actually useful as it is a feedback loop if used properly. BTW, roadmap doesn't have to be the mechanism for engagement, but some means of higher bandwidth communication is really what is needed. It seems Affinity is too afraid of negative feedback to engage. That really can't be avoided and really shouldn't even be looked on as a negative. People who passionately love your product will be vocal about it. The company I worked for had in depth engagement with users. Often difficult, but it was always seen as necessary to truly understand needs of users. Not engaging with users will never make negative complaints go away.

Since that is not a critique of any of your original value statements, I assume you have then accepted this counterpoint. FWIW, it is also available on all platforms. If you want an example of something more commonly used everyday, then the look to Servo and Stylo. Servo was developed following game rendering engine architecture for the Mozilla browser used to render HTML and Stylo handles the CSS. https://www.tomshardware.com/news/firefox-57-beta-project-quantum,35541.html

Precisely the opposite. All these things have improved by orders of magnitude over C. Even performance. Take RipGrep as an example - https://blog.burntsushi.net/ripgrep/

There really is no workaround that isn't such a PITA that it essentially nullifies the whole advantage of doing it live. Especially for any work that is rather complex. Imagine having multiple objects within the same artboard that have different displacement layers. Then they all break when you duplicate the art board. Seems like just allowing the user to somehow set an anchor point could be an easy fix for a bunch of the live filters.

Doing most projects in C would be the most costly implementation compared to far better options available today.

Yes, being able to point and click to set an anchor point anywhere relative to the parent would be most flexible with some reasonable default, maybe center. Having them all work like Ripple probably makes sense, in that it would be consistent behavior.

Most do not. Even for the exceptions, it never justifies the cost of development of the entire platform in a low level language when only less than 1% will benefit.

Everything you mention is moving to newer tech. Yes, much is still written in older tech, but that is not where the momentum is for good reason.