Peter Pokorny Posted August 5, 2019 Share Posted August 5, 2019 The new RC is extremely laggy as soon as you have more than two layers. Dreingabe, enlarging, moving has several Second Delay what Maikes it Alain Almost unuseable. Link to comment Share on other sites More sharing options...
pixelcoder Posted August 6, 2019 Share Posted August 6, 2019 Could you do a screenrecording or provide your file? I really tried to bring it to lag by opening some 36MP Raw files, but its super smooth for me even with 10+ adjustement layers applied. Brushengine also works fine with reasonable large canvases. Using an iPad Pro 2017 and iPadOS13 beta4. (No other Apps running in background while testing) | https://www.instagram.com/lutz.heidbrink | https://500px.com/lutzheidbrink | https://www.eyeem.com/u/pixelcoder | https://society6.com/pixelcoder iPad Pro 10.5 - iOS 11.4.1 - Affinity Photo 1.6.7 - Affinity Designer 1.6.0.35 Link to comment Share on other sites More sharing options...
frankthechicken Posted August 6, 2019 Share Posted August 6, 2019 2 hours ago, pixelcoder said: Could you do a screenrecording or provide your file? I really tried to bring it to lag by opening some 36MP Raw files, but its super smooth for me even with 10+ adjustement layers applied. Brushengine also works fine with reasonable large canvases. Using an iPad Pro 2017 and iPadOS13 beta4. (No other Apps running in background while testing) I have an iPad Pro 1TB edition on iOS 12.4, and I can demonstrate a very simple video to show how the lagging occurs. Whenever it seems my touch is staying in one place, lagging is occurring (I have not simply held the touch there) It seems to be most prevalent when using groups of layers, the lag also builds up over a period of time. Eventually the system becomes inoperable, and one can lose all work or progress. It should also be noted that if one were to try to return to the main menu after the lag has begun, the file sometimes will not save. RPReplay_Final1565081610.mp4 Link to comment Share on other sites More sharing options...
frankthechicken Posted August 6, 2019 Share Posted August 6, 2019 Just as a further example, I've performed the same operations to individual layers (i.e. not in a group) and it is far harder to get the system to slow down. RPReplay_Final1565092284.mp4 Link to comment Share on other sites More sharing options...
Peter Pokorny Posted August 6, 2019 Author Share Posted August 6, 2019 hi frank. I tried to enlarge the entire document with all layers. what happened was every time a crash of AP Link to comment Share on other sites More sharing options...
DM1 Posted August 7, 2019 Share Posted August 7, 2019 23 hours ago, pixelcoder said: Could you do a screenrecording or provide your file? I really tried to bring it to lag by opening some 36MP Raw files, but its super smooth for me even with 10+ adjustement layers applied. I don't have problems with my normal workflow. I use a few pixel layers to inpaint but generally use adjustment/filter layers and perform a merge visible before progressing to next stage of editing. My experience with AP is therefore positive. However, creating a large canvas and adding 10 or more pixel layers, then making random strokes on each layer before selecting all layers, spinning and expanding/contracting the object box for a few minutes will generally result in a major slowdown, to the point that further paint strokes will take 5-6 seconds to appear. Should this happen? Is it pixel layer related? I don’t know. Peter appears to use lots of pixel layers in his workflow so maybe this is why he experiences so many more issues? M1 IPad Air 10.9/256GB lpadOS 17.1.1 Apple Pencil (2nd gen). Affinity Photo 1.10.5 Affinity Design 1.10.5 Affinity Publisher 2, Affinity Designer 2, Affinity Photo 2 and betas. Official Online iPad Help documents (multi-lingual) here: https://affinity.https://affinity.help/ Link to comment Share on other sites More sharing options...
frankthechicken Posted August 7, 2019 Share Posted August 7, 2019 To be honest it doesn't require much to get the app to slow down to a crawl, just manipulate a group of 3 layers or more on a reasonably large canvas for a few operations and you will experience serious slow down. If one works on individual layers then the app seems fine and smooth as it was on 1.6, however working with groups of layers is still very buggy. Link to comment Share on other sites More sharing options...
Staff Andy Somerfield Posted August 7, 2019 Staff Share Posted August 7, 2019 Evening all, Thanks for this thread - it has helped identify a significant problem which I am very pleased we have got fixed before the 1.7.2 release. Turns out that in builds since 1.7.0, we have, under certain circumstances, used only half the memory available to us on iPad. This causes disk thrashing and explains some of the terrible slowdowns you have been experiencing. Worth saying though that there are still limits - your example of a 5000x5000 RGBA 8bit canvas - one layer is 25MP (100MB). You have 5 layers (500MB). You then scale them down by about 50% - Photo is lossless when scaling layers, so they balloon from 25MP per layer to 100MP per layer - 400MB. At this point, your 5 layers cost 2GB - not including the ~1GB undo history created by the initial steps. Repeat this say 20 times quickly (so Photo doesn't have chance to optimise / deduplicate history in idle time) and you are using ~60GB of memory on a device which has (at most) 2GB of usable physical memory - on a 2GB/3GB device, only 1GB is usable.. It's fair to expect Photo on iPad to page to disk at some point in pretty much any large project. We do everything we can to hide that latency - but grouping a number of huge layers, scaling them down, then moving them around is pretty much a perfect storm - so if you are repeatedly doing that, fast, at some point Photo will panic and start paging to disk.. Anyway, thanks again for helping to get this nailed down - we should now be back to 1.6-quality memory management, which hopefully, coupled with the improvements in the new 1.7 compositor, will yield a decent improvement for 1.7.2. I'll push the 151 build with these fixes ASAP. Thanks, A Chris J, frankthechicken, Patrick Connor and 5 others 6 2 Link to comment Share on other sites More sharing options...
MikeW Posted August 7, 2019 Share Posted August 7, 2019 Don't have an iAnything. Heck, and I don't use APhoto. I just wanted to thank you, @Andy Somerfield, for the clarity & honest communication. So, Thanks! Mike Link to comment Share on other sites More sharing options...
frankthechicken Posted August 7, 2019 Share Posted August 7, 2019 1 hour ago, Andy Somerfield said: Evening all, Thanks for this thread - it has helped identify a significant problem which I am very pleased we have got fixed before the 1.7.2 release. Turns out that in builds since 1.7.0, we have, under certain circumstances, used only half the memory available to us on iPad. This causes disk thrashing and explains some of the terrible slowdowns you have been experiencing. Worth saying though that there are still limits - your example of a 5000x5000 RGBA 8bit canvas - one layer is 25MP (100MB). You have 5 layers (500MB). You then scale them down by about 50% - Photo is lossless when scaling layers, so they balloon from 25MP per layer to 100MP per layer - 400MB. At this point, your 5 layers cost 2GB - not including the ~1GB undo history created by the initial steps. Repeat this say 20 times quickly (so Photo doesn't have chance to optimise / deduplicate history in idle time) and you are using ~60GB of memory on a device which has (at most) 2GB of usable physical memory - on a 2GB/3GB device, only 1GB is usable.. It's fair to expect Photo on iPad to page to disk at some point in pretty much any large project. We do everything we can to hide that latency - but grouping a number of huge layers, scaling them down, then moving them around is pretty much a perfect storm - so if you are repeatedly doing that, fast, at some point Photo will panic and start paging to disk.. Anyway, thanks again for helping to get this nailed down - we should now be back to 1.6-quality memory management, which hopefully, coupled with the improvements in the new 1.7 compositor, will yield a decent improvement for 1.7.2. I'll push the 151 build with these fixes ASAP. Thanks, A Thank you so much for the detailed reply. I'm glad that something has been sorted out, I'm looking forward to loving this amazing program once more. I'm not quite sure I understand the reasoning that given as I would have expected similar problems when dealing with single layers. Unless one is dealing with the group as a whole (rather than individually) and then referencing memory that has not been allocated I guess. Link to comment Share on other sites More sharing options...
frankthechicken Posted August 8, 2019 Share Posted August 8, 2019 I have just been testing the latest version 1.7.2.151, and unfortunately the same problems occur. Any kind of manipulation of groups of layers is resulting in complete slowdown, and degradation of work. Leading to files being unable to be saved. I realise that I am probably coming off as a pain, but I just want Photo to be back to the glory of 1.6. When I try to manipulate groups of layers (in this case, just two), even with kid gloves, I experience horrendous slow down. Note that when the blue touch circle is on screen (and paused) the app has hung. When there is no blue circle I am giving the app every chance to recover. RPReplay_Final1565253975.mp4 Link to comment Share on other sites More sharing options...
frankthechicken Posted August 8, 2019 Share Posted August 8, 2019 However, I can manipulate single layers with wild abandon, with no slowdown whatsoever. Note these videos are done at 5000 x 5000 pixels RPReplay_Final1565254091.mp4 Link to comment Share on other sites More sharing options...
Peter Pokorny Posted August 8, 2019 Author Share Posted August 8, 2019 I hope too that the app will soon be working more fluently because it would be the best app at the moment for this on iPad. Link to comment Share on other sites More sharing options...
frankthechicken Posted August 8, 2019 Share Posted August 8, 2019 As a further example, I've made a video of a document which is 10000 x 10000 pixels (equivalent to about four layers of 5000 x 5000 I guess) and performed the same scaling and translating with no lag. Surely this should be further evidence that there is something wrong with the group implementation? RPReplay_Final1565273562.mp4 Link to comment Share on other sites More sharing options...
Peter Pokorny Posted August 8, 2019 Author Share Posted August 8, 2019 Kam totally on your side frank. The more lasers I am edging into the group the slower is AP reacting. So it might be a problem with the groups. Will try next time how it will be without groups. I’m usually working with pictures in the size of 4000x6000 pixel. Link to comment Share on other sites More sharing options...
Peter Pokorny Posted August 8, 2019 Author Share Posted August 8, 2019 When you want to save an unsaved document with large size an many layers AP freezes while needing endless during saving and if you restart it you can’t load the picture and tryinto restart saving Leads to an crash of AP. It makes no sense if you can’t save your work. So please please correct this before releasing it Link to comment Share on other sites More sharing options...
frankthechicken Posted August 22, 2019 Share Posted August 22, 2019 Photo still cannot cope with transformations of groups, though I'm wondering whether its just shrinking the groups which causes issues (particularly shrinking smaller than their original size?) In these videos one shows that no issues occur when simply enlarging the groups, however there is significant lag when one attempts to shrink the groups (these are unadjusted sample pictures pixel dimensions 2560x1440):- This is with the latest Photo release 1.7.2.153 on a 1TB iPad RPReplay_Final1566425259.mp4 RPReplay_Final1566425594.mp4 Link to comment Share on other sites More sharing options...
Recommended Posts