My freezing/beachball problem always happens in the same method

[Florida]

I seem to be the only one with constant freezing/beachball issues with the betas (and even in recent prod release). Every time it does this macOS saves a diagnostic report, and the location of the freeze is always in the exact same place in the report. This would seem easy for one of your programmers to identify.

...

10  void Raster::ProcessBase<Raster::Copy>::Execute<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5, Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5, Raster::X1, Raster::X2, Raster::X3, Raster::X4, Raster::X5, Raster::PNG<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5>, Raster::Buffer<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5>, Raster::Copy, Raster::IdentityMask, Raster::IdentitySampler, Raster::IdentityTransform, Raster::Safe, Raster::NormalBlend>(Raster::PNG<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5>*, Raster::Buffer<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5> const*, Raster::Copy::Params*, Raster::IdentityMask::Params const*, Raster::IdentityTransform::Params const*, Raster::IdentitySampler::Params const*, Raster::Safe::Params const*, Raster::NormalBlend::Params const*) + 485 (libcocoaui + 17748725) [0x13b7622f5]
  10  void Raster::PixelProcessor<Raster::Horizontal>::Process<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5, Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5, Raster::X1, Raster::X2, Raster::X3, Raster::X4, Raster::X5, Raster::Buffer<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5>, Raster::PNG<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5>, Raster::Copy, Raster::IdentityMask, Raster::IdentitySampler, Raster::IdentityTransform, Raster::Safe, Raster::NormalBlend>(Raster::Buffer<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5> const*, Raster::PNG<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5>*, Raster::Copy&, Kernel::RectT<int>, bool, Raster::IdentityMask::Params const*, Raster::IdentityTransform::Params const*, Raster::IdentitySampler::Params const*, Raster::NormalBlend::Params const*) + 290 (libcocoaui + 17749026) [0x13b762422]
  10  png_write_row + 345 (liblibpng.dylib + 150713) [0x13e689cb9]
  9   png_write_find_filter + 8897 (liblibpng.dylib + 191457) [0x13e693be1]
  9   png_compress_IDAT + 304 (liblibpng.dylib + 167232) [0x13e68dd40]
  9   deflate + 2435 (liblibzlib.dylib + 17363) [0x13e9253d3]
  7   deflate_slow + 278 (liblibzlib.dylib + 22310) [0x13e926726]
  2   longest_match + 487 (liblibzlib.dylib + 25751) [0x13e927497]
 

As a programmer myself it appears to involve copying pixels in some way that involves swapping or something that causes both the process itself and the Windowserver to freeze for a time. Maybe its my video card or something else in the system. My device is pretty standard and the latest Big Sur version. I have a set of files that reproduces the issue on my iMac all the time, but not two other  user's (different) iMacs. Currently I am unable to effectively use AP. I'd be happy to provide any useful info you might need.

[Florida]

I now see the issue. I only have 16GB of ram on this iMac, and trying to work with too many large layers, with many other applications open, the memory demands is causing a ton of swapping virtual memory pages. With an SSD you can't hear anything like you could with hard drives. Running the beta on a freshly restarted iMac with no other apps open, no slowdowns are seen. Clearly having only 16GB of ram is insufficient to do anything large (in my case I often do 9000x9000px images).

Ordered 16GB more ram should help!

[Chris B]

Hey Florida,

16GB should be enough for a 9,000 px x 9,000 px document - I mean, the average WIndows PC's have that (or less). 

I have a 2017 iMac with 24GB RAM so I'd be happy to try a file for you or something. We might be able to properly diagnose what's going off. I suppose it depends on what else might be using that 16GB RAM.

[James Ritson]

Hello @Florida, a couple of things to mention that may help identify what's happening:

• Are you opening up PNG files, then working directly on them without saving to the .afphoto document format first? If so, could you try immediately saving into the native document format, then carrying on with your usual workflow? We identified an issue with TIFFs and autosaving of the compressed raster data, it may apply to PNG as well.
• Do you have Metal Compute enabled under Preferences>Performance? If so, you are also at the mercy of available VRAM on your GPU (8GB in your case) since it is being used for compositing. Bear in mind that there will be OS overheads, other applications may require GPU memory, and Photo of course will have a certain overhead for mipmaps and other tasks. That said, it is very unlikely you would be filling the VRAM with just a single 9000x9000px layer. Are you working with multiple layers of the same resolution? If you exceeded the available VRAM, it would start using swap memory which would incur a performance penalty—it shouldn't crash, however, just cause an inconvenience whilst you wait for data to be transferred in and out. It may be worth temporarily disabling Metal Compute, thereby making compositing entirely reliant on your 16GB RAM, to see if that helps the issue.

Hope the above helps!

[Andy Somerfield]

Florida,

Is the image you are trying to export to PNG very large? You mention 9000x9000.. I wonder if there is some integer overflow issue here.

Exporting is not done on the main thread, so beach balling implies either a.) It's not export related, which is unlikely as your stack is plainly exporting, or b.) We are somehow exporting on the main thread! Could you provide the full stack dump?

Cheers,

A

[Florida]

I tracked it down to thrashing virtual memory, AP was using more VM than was available and it made both it and WindowServer thrash trying to page in/out memory.

I included a .diag that macOS generated during the beachallery. By ensuring not too many apps were running and restarting AP frequently I can avoid all the issues with my 16GB of ram. I am just now upgrading to 32GB.

Yes I often have 5-7 png documents open all 9000x9000, and the one I am pasting into often has multiple layers as well since I pasting the other in. So the total with undo stack could be very large.

Affinity Photo Beta_2021-07-11-105602_Andrews-iMac.wakeups_resource.diag