On demand processing in background isolate #21
Conversation
| } | ||
| List<RawFrame> bytes = []; | ||
| for (final frame in _frames) { | ||
| final i = await frame.image.toByteData(format: ui.ImageByteFormat.png); |
There was a problem hiding this comment.
This part still will freeze the screen on Web if you have many frames @ueman
There was a problem hiding this comment.
Yeah I know. For now it's just an improvement for io platforms. For web it's just the old implementation. (This PR is a few commits behind)
There was a problem hiding this comment.
The problem is that this operation(toByteData) we dont have any way to include it on a Web Worker, thats why my other proposal of processing the frames on the way. I dont like much my approach but honestly i dont find any other workaround :S
There was a problem hiding this comment.
So then, for me to get context about the PR, where is the improvement exactly? Capturing or just exporting?
There was a problem hiding this comment.
This significantly improves the gif exporting on io platforms. Each frame is directly processed for a gif in a background isolate which means when the user actually requests the gif export, it's almost completely converted to a gif. So for a user this seems like a significant performance improvement.
But as said, it just works on IO platforms and only for gifs as dart:ui APIs can't be used in a background isolate.
But I'm guessing you're more interested in individual frames than a gif 😅
There was a problem hiding this comment.
Ok see what you mean now.
But yeah, this will still be a pain in my side haha Wondering what middle point we can have. For any reason i dont understand why the operation toByteData is freezing just on Web not in iPhone.
This processes each frame as it comes in in a background isolate. As a result, exporting the final gif takes way less time.
This a first draft and probably doesn't work in all scenarios. Re-using an exporter is probably one of those use cases.