Jump to content
You must now use your email address to sign in [click for more info] ×

RC2 lagging like hell


Recommended Posts

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 :11_blush:

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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

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

  • Staff

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

 

Link to comment
Share on other sites

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

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. 

 

Link to comment
Share on other sites

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

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

  • 2 weeks later...

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

 

 

 

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.