paschulke2

Content of this post deleted by myself.

In another thread about this problem I wrote this: This thread was closed by Affinity staff. Currently Apple is very active with updating XProtect (once or twice per week). Whenever anything around Xprotect is updated (you receive these updates as "security updates") apps will be checked at the next start up. Three possible solutions: 1) make the apps smaller - e.g. less than 3GB(!) for Affinity Photo 2.3.1 (Affinity) 2) make security check faster (Apple) 3) disable the automatic download and installation of security updates (not recommended). This would make the slow start ups occur less frequent.

This behaviour also drives me crazy (45s to 1min start-up time ...) It's clear that this is caused by security checks and that these checks take very long because of the size of the (universal) Affinity apps. One thing may not be clear to everyone: Why does this problem come and go without any obvious reason? (Quite often users report that they did "X" and now the problem is solved. A week later they report that the problem has returned ...) You can use a tool called SilentKnight to check the status of all security updates on your system. See image attached, where in the red box the latest updates are highlighted. The latest update was on January 31st and of course that evening Affinity apps started very slowly on my iMac. Now start-up time is back to normal - until the next MRT/XPR/XProtect/MacOS update. In a typical configuration all the security updates are installed automatically in the background so that the user knows nothing about the update. That's when the slow start-up problem returns "out of the blue". To me the riddle why this problem comes and goes is solved. The long start-up time when a new security check is made is of course not acceptable, whether it is related to the size of the app or not. But I am not expecting this problem to be solved by either Apple or Affinity anymore.

Done. Thanks! Just tried it again: If I export the whole document, the resulting png file will be smaller than the png file I will get when selecting everything that is visible and performing a "export selection only" (I hope that's the correct english version of "nur Auswahl exportieren"). "Export whole document" produces the result I expect – "export selection only" does not.

You're right, thanks. There are three curves which extend the rectangle and are cut off by it. See image attached. But: I only selected what is visible on the left of my first screenshot and these three curves are in the png but don't show up in the selection. For the second screenshot I explicitly selected these three curves to see their full extent. Weird, but maybe not a real bug ...

The screenshot shows it all: The exported png is much bigger than the selection with lots of empty space – not only in the preview but also in the actual png file. This problem did not exist in 2.1.0

Can't you see how incredibly bad this is for your customers? Their credit cards get charged, they don't get a license and all you have to say is that everything is "fully functional"? I was about to buy a universal V2 license using my credit card today. Of course, having read this, I won't.

I did not and do not think that they are working on it. Let's rephrase my question: Affinity: When will you start to work on this very annoying problem? Is this bug a way of "convincing" the Apple Store users to buy another version through the Affinity Store?

It works. But only for a while (maybe a week or two). Affinity: when will this be fixed? It's very annoying!

This is of course not "outside of the app". The feature to show a good preview of a file in the finder is called "Quick Look": https://developer.apple.com/documentation/quicklook Unfortunately, Affinity Photo or Affinity Designer do not provide this extension and all you get to see is a small png of your photo or designer file in the finder. It's not a bug, but the unwillingness to properly implement a very useful standard feature of Mac OS.

Hi Chris, the CPU is an i5, 3.4GHz, quad core. GPU is 4GB Radeon Pro 570. Kind regards, Thomas

… or a mix of German and English ("Greys, Colours and Gradients"):

Hi, I can't post this image here but you could post a dropbox link for me. Kind regards, Thomas

Hi Chris, you already have the 500MB 16bit panorama file with the zoom problem, don't you? I don't have any other file with this problem, but I can still easily reproduce the problem with this file. With this huge file zoom in will always "hang" when zooming for the first time and with metal compute enabled—sometimes a second, sometimes even longer. Otherwise I see a performance increase with Metal compute enabled (but a decrease in quality, see new thread). Kind regards, Thomas

Hi, Enabling "Metal compute acceleration" reduces the quality of image rendering when using live filters, e.g. the clarity live filter. Here are four screen shots to show the effect. The windows on the left side are without "Metal compute acceleration", the windows one right side have "Metal compute acceleration" enabled. The top screen shots are taken the clarity filter off, the bottom ones with the clarity filter on. The clarity filter was set to 0% (no effect). As you can see the rendering of the image on screen gets blurred with metal compute and the clarity live filter. If you export the image or merge the pixel layer with the liver filter, the result will be ok (no blurr). Please look at the image attached in 100% zoom in order to see the effect. Edit: The image file is RGBA/16. iMac Retina 5k, Mojave 10.14.5, Radeon Pro 570 (4GB), 48GB RAM This bug makes it impossible to judge image quality with live filters. Kind regards, Thomas