CM0

Unfortunately, none of the live filters are fixed for any of my use cases. All of my projects are still broken 😞 Note, once you have a filter that is attached to an item within another object, it will always be broken. So even if you later move it out to be a top level item, you can no longer duplicate it as you did before. The perspective live filter performs differently based on whether the live filter mask is attached as a clipping or masking layer. Looks like I did those as clipping child layers. However, the problem manifests irregardless of either method.

I looked at your files. So I was wrong about the group. It must be a child of some object. So instead of the group, place them inside a rectangle or something. I do all of my work on Artboards. In that case, they are always broken. You could also go to the issue I linked above. I have an example file there you can open and duplicate the items.

It only works as long as the object you are applying the perspective is not a child layer of any other object. If you do the same thing on an artboard, it will not work. Or if placed in a group.

It is not fixed, I just reported this with the current release.

It should have been fixed in the current beta. I originally reported it August of last year. FYI, this bug affects all live filters. I don't know how anybody uses this.

PiXimperfect (very popular photoshop channel) posted a video covering features that are missing from Photoshop. The video hits points that would make strong promotional points for Affinity. Some interesting feedback in the comments as well.

Thank you. FYI, out of all the issues I've opened, this is the highest priority for me. I have found no work around and the impact to the type of work I'm producing is the greatest. Just some feedback I hope you could pass along for prioritization. Thanks!

The rectangles containing the filters were duplicated. I have reported this previously for the perspective filter. It has already been acknowledged as a bug. However, I discovered it seems to be all the filters. I have spent hours/days trying to find workarounds.

All live filters that use any positional references break when duplicated. This effectively makes most live filters useless for many use cases. There is no way to make variants of your work or replicate multiples of items within a piece of work. Attached is a sample of filters. First row is duplicated twice. You will see the second duplicate looks incorrect for all filters. live-filters-broken-duplicate.afpub

If you have all 3 products installed, it should simply work as a suite. It should allow you to combine any views from any product. The products already support the same capabilities, you just don't have access to the views or tools. This would make the suite so much more powerful.

In software development, there is a concept called "technical debt" that usually leads to slower development over time. Almost all projects build up technical debt over time. No project ever has all the foresight of what will be needed in the future and original designs can fall short of what is needed. At some point, if technical debt is not addressed, development continues to be slower and slower. It is painful to address, as it usually means you have to put new development on hold to go back and do refactoring and redesign. The benefit is that development velocity can increase afterward. The somewhat hopeful point of view is that it sounds like Affinity did address some technical debt last year with changes they were making to improve performance.

This forum will not be sufficient for a proper in depth discussion. I would recommend you start reading some material on TDD. https://testdriven.io/test-driven-development/ For everyone else, what you are witnessing is exactly what happens internally within development teams when a new process is proposed. There is resistance to change and acceptance that the new process will be beneficial. It is more than just the technical element when improving processes. There is the human element that is a fundamental step in convincing the organization that the process changes will be beneficial. It is why you need an experienced advocate to lead the change. An organization is unlikely to be able to navigate the process on their own without a lot of mistakes along the way.

Just to level set expectations. For anyone thinking that Affinity should just switch to Agile and all will be good. It is not that simple. There is no way to know how long it would take without direct consultation, but it wouldn't be unreasonable for such a transition to take a year or more for any decent sized development when that transition is being led by someone with experience in helping development process transformation. Also, we only have an outside view and it is just speculation as to what are their greatest challenges internally.

It would be normal in proper development to be a test for every API function. When you do this at the unit test level, it is really not necessarily that much more work. You should have 100% test coverage. It is irrelevant whether you are a single person or a huge corporation. Eventually, you can't manually test anymore. Development cycles get longer and longer because of the testing burden until it takes you forever to get out the single new feature. Overtime, the application becomes more complex, new changes may introduce regressions. When you add a new change, you should test all other features that have ever been developed since the beginning. You can't scale this manually. So if you are doing manual testing, you will only test a small portion. What you think might be affected. Often you will be wrong. You don't decide what to test with automated tests. At least at the unit level. You test everything. You should 100% test coverage. That might not be possible at the integration test level. The problem with OS's, is it is essentially just an integration platform because you allow software to be installed that is not part of your testing and that software can be written at low level which is a different problem at a different scale.

I've worked on the largest applications in the industry for 3 decades. Enterprise solutions that have 7 figure licenses. Many multi million lines of code across different languages, systems and platforms that are tightly integrated. I've worked as solution architect for fortune 100 companies to improve their development processes. This is how we did it. At this scale of size and complexity, you don't have enough resources, man hours, to even conceivably make manual testing feasible. Testing is part of a proper architectural design from the beginning. Yes, the problems you describe are common because it is common that proper testing methodologies are not used in most organizations. I've spent much of my life helping teams improve these issues. It is not easy, and frankly, in a large application that never did the design properly from the beginning will not be fully fixable.