Jump to content
Sign in to follow this  
Peter Pokorny

RC2 lagging like hell

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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:

Share this post


Link to post
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.

 

 

Share this post


Link to post
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?


IPad Pro 10.5/512GB lpadOS 13.1.1  Affinity Photo 1.7.3.155 Affinity Design 1.7.3.1 Publisher for iPad ?

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
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.

 

Share this post


Link to post
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. 

 

Share this post


Link to post
Share on other sites

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?

 

 

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | 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.