frankthechicken
-
Posts
47 -
Joined
-
Last visited
Posts posted by frankthechicken
-
-
I still get a line and a dot unfortunately. I would rather only allow the context menu to be dismissed by pressing OK, rather than having to go back in history/erase whenever I forget. But there are bigger things to worry about!!
-
I know this is low priority, but it would be nice to have fixed.
* 1.8.3.178 - RC
-
This has regressed to prior .168 Beta with the last two versions (1.8.2.172 and previous)
In other words the line is being drawn again after tapping off the context menu.
-
Thanks for letting us know.
I think I would have preferred forcing the user to tap OK on the popup as it is easy to forget and having to correct the error blob much later is a pain.
-
-
This bug was, I think, first introduced in 1.7.
After my limited testing 1.8 seems like a huge improvement on 1.7, so huge congratulations to the team. It seems to be back to the wonderful standards of 1.6, which is great.
My main annoyance of 1.7 was the slowdown when resizing layers, this seems to be vastly improved in the new version. There are a few occasions when resizing/moving layers long slow downs occur but it's nowhere near the levels of 1.7.
-
After changing the size of the pencil width or colour, tapping off the menu to close it with the pencil causes a straight line to be drawn. The only effective way is to tap with your finger.
Clearly one should be able to tap off the menu with the pencil.
*Edit*
I should have stated this is 1.8.0.165 on a 1TB iPad Pro 2018
-
I have a lot of trouble with issue 1 as shown in this screen recording (hard to reproduce on purpose) As you can see by the number of layers I used before finally capturing it!
-
I'm just thankful the issues are slowly being recognised, I felt like I was being flat out ignored previously. The 1.7 iteration of the app was very obviously next to worthless compared to 1.6, and no matter the examples I issued, there was no recognition, no admission, nothing. Then. finally when the issue was recognised, Andy Somerfield, apparently the photo lead stated these issues are only to be expected!
I mean what?
These issues were not present in previous builds, and yet now they are to be expected? Simple manipulation of images should be the apps staple diet.
Everything seems to be about hiding away from the issues, head in sand, pretending they don't exist. I too am about given up on the app. It feels like I am an unpaid, unappreciated, unrecognised, and unwanted beta tester. When issues are raised, it has felt like the customer is the problem, not the product.
-
24 minutes ago, Chris B said:
Hi Inocentpredator,
Yes I had a go with the same file that frankthechicken was using in the above recording and I too ran into the same pauses/delays as seen in the said recording. I cannot test this in 1.6 as we cannot open 1.7 files in 1.6 versions of the app so I found some other complex files that I could open in 1.6 but I didn't really notice any real performance issues. Opening the same file in 1.7 that was working well in 1.6 seemed to work well too.
I really think we need some 1.6 files that perform poorly in 1.7 but we need to make sure those files are not saved in 1.7 so we can use a copy to always refer back to in 1.6.
It doesn't need to be a complex image, though it may need a few more operations.
The following video is a new document at the default size. I will draw on one layer, and perform a few operations on and the app will grind to a halt.
The more complex the document the less operations needed to break the app, however it is still very demonstrable on simple doc.
-
I've said this in the Beta forum but no responses there, so I'll try my luck here as it still applies:-
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) Please note when it appears I am touching the screen for an extended period of time, I am not, the app is just having a think:-
This is with the latest Photo release 1.7.2.153 on a 1TB iPad
-
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
-
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?
-
However, I can manipulate single layers with wild abandon, with no slowdown whatsoever.
Note these videos are done at 5000 x 5000 pixels
-
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.
-
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.
-
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.
-
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.
-
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.
-
To be honest I was not running into any of the halting problems on the previous 1.6 build, I think there is a flaw in the coding somewhere. It feels like a memory leak. The iPad is a very capable device nowadays.
- DM1 and nakamateux
-
2
-
My personal issue with Photo has not been corrected with 1.7.2.149
-
The latest beta (1.7.2.149 RC1) stills shows the problem.
What I haven't demonstrated is that once this slowdown has started, the app can stay very unresponsive, even if one waits long enough for the app to have finished calculating what it needs to.
As soon as the slowdown occurs, it becomes necessary to quit the app, and hope it is able to save your document, else one faces lost work.
Also worth noting that it is not just resizing/moving/rotating the groups of layers, this is just the most easily demonstrable. I find it occurs with almost any task when dealing with groups of layers. It is such a problem that I have to either dramatically reduce the amount of layers of work with, or (and this only occasionally works) hide the layers I am not working on.
I can also demonstrate this happens with smaller documents (in this case 5000 x 5000 pixels).
At the end of this video I was trying to choose a colour but the app was unresponsive.
Please note, I am manipulating a group of layers
-
I can also demonstrate it using a smaller document say a 4000 x 4000 pixel document. Although it requires a few more operations in a row (though still around 7/8 layers in 1 group). All it requires is a few rotations/resizing as demonstrated in the video I made and the app begins to considerably slow down. Eventually the app will cease responding.
No, this is not a genuine use case, but it demonstrates that there is a flaw in the app.
This flaw rears its ugly head again and again in my general work (i.e. slow down with eventual app crashing), so much so that I have to keep returning to the main menu in an attempt to ensure the document is saved before it freezes completely.
-
p_mac, I can't see where you tried rotating, or resizing any of the groups of layers?
If you notice, the slow down occurs when I try resizing or rotating groups of layers on a large document.
I only demonstrated this as it represents what happens during my workflow when I am using a number of layers and groups and trying to perform operations on them.
I suggest you try making a large document (say 16000x8000 pixels), scribble a few layers, say seven, combine them into a group and then try to resize/rotate them.
Rectangle option initially does not allow changing of corner type
in [ARCHIVE] Photo beta on iPad threads
Posted
Not a huge issue, but slightly annoying
iPad Pro 2018 1TB
EDIT **Not sure why I've got 2 videos here**