performance: inexplicably long pauses when using `takeScreenshot`
matthiasn opened this issue · comments
I have a somewhat larger Fluttium flow with around 250 steps, taking a total of 23 screenshots. When I watch the flow complete on macOS, all the described steps complete very quickly, in under 2:30. However, it then takes another almost 9 minutes to complete the flow, see video.
Steps To Reproduce
- Check out https://github.com/matthiasn/lotti
- Run
$ fluttium test test_flows/habit_flow.yaml -d macOS
Expected Behavior
My expectation would be for the whole flow to complete in under 3 minutes. Another 30 seconds or so after the finishing the interaction with the app would seem plenty.
Screen recording
fluttium_long_pauses.mp4
This is happening because the screenshots take a long time to be consumed, blocking the steps output for the reporter.
May I ask what your use-case is for taking so many screenshots in your user flow? My idea for the screenshot action was more to store the final result of the flow than intermediate results.
@wolfenrain thats for keeping the manual up-to-date. I want screenshots in documentation that always reflect the current state of the UI, rather than manually going through a script, especially since I'm really bad at doing that manually and having to start from scratch again and again (so I end up not doing it and this have outdated docs).
Seems like that's a really long time, considering that all screenshots I'm taking combined are only 1.8MB in total.
Where do the screenshots get consumed? Can I help and take a look?
Seems like that's a really long time, considering that all screenshots I'm taking combined are only 1.8MB in total.
Where do the screenshots get consumed? Can I help and take a look?
The binary data is send over the stdout of the device to the host side in parts as we can only send so much per line, so it has to wait until all of it is consumed to be able to go to the next step but there is no way to halt execution of actions when that happen.
@wolfenrain thats for keeping the manual up-to-date. I want screenshots in documentation that always reflect the current state of the UI, rather than manually going through a script, especially since I'm really bad at doing that manually and having to start from scratch again and again (so I end up not doing it and this have outdated docs).
I see, I wonder if a custom action that stores screenshots directly might be better than using the screenshot action then. This would be possible if you are generating the screenshot on a desktop platform, as you have access to the file system.
Ah I see, makes sense. Yeah I'm taking the screenshots on macOS, that would work, I'll look into the custom action route, thanks 🙏
May I ask what your use-case is for taking so many screenshots in your user flow? My idea for the screenshot action was more to store the final result of the flow than intermediate results.
I have the same issue with multiple screenshots which slow down the flow. But I think my use of Fluttium is wrong, because I'm using it for user flow testing, and to take series of screenshots of the App for the Stores (as an alternative of Fastlane screenshots).
I misunderstand that the takeScreenshot action was mainly for debugging (I never ask myself why this is in the "debugging" session of the docs 😅)
I found a way to optimize the screenshot action drastically so I'll be working on a PR to allow that soon.
Can you give some hints to optimize the screenshots action? It would be a pleasure to help you with this one. I know you need to rest.
Can you give some hints to optimize the screenshots action? It would be a pleasure to help you with this one. I know you need to rest.
It requires a full refactor of the internal driver and using flutter_daemon, which I already have done. Just need to finish up writing the tests
Oh ok, I think I can not help with this feature so, maybe the review of the PR 😅
Oh ok, I think I can not help with this feature so, maybe the review of the PR 😅
I pushed everything into #293, I wont merge that PR but it serves as the proof of concept and I'll be pulling code out into it's own PRs to get it to the next stage.