Stream decoding images

[CosmicHorrorDev]

Just opening as a draft since I still have to do more cleanup, but this streams the decoding and compression of images. I'll update this message when I've got it cleaned up It's now cleaned up!

main

PR

[trimental]

Had a look over this, looks great so far. Didn't know the image crate had a guess format function. How have you found the changes to async image loading, are the images still loading worse then they did before for you?

[CosmicHorrorDev]

How have you found the changes to async image loading, are the images still loading worse then they did before for you?

It certainly seems better than the original switch to async, but there's still some blocking on the initial rendering compared to the non-async version

Also note that we seem to be using more idle memory now. In the plot on #69 you can see the idle memory usage is ~19 MiB, but the switch to async bumped it up to ~26 MiB. From some quick glances at memory profiles it looks like the extra memory is from font stuff, but that could be wrong

Currently I'm not sure if the switch to async is carrying its weight. The main advantages for switching to async in general would be:

1. Better efficiency/performance when doing a lot of waiting-intensive tasks
2. Better readability/ergonomics when doing a lot of waiting-intensive tasks

Where I think the main issue is that we're not doing a lot of waiting-heavy tasks to begin with. For 1. it's primarily just reading files and performing networks requests which we don't do much of either (Maybe into the 10's of files and network requests). For 2. it seems like we mix CPU-intensive and waiting-intensive tasks enough that it seems to be harder to reason about compared to using threads and threadpools. Currently it's pretty easy for us to accidentally block the executor in a lot of ways that will likely be hard to notice (things like decoding images or calculating layouts)

I'm fine with sticking with the async version and trying to smooth out the bumps that we've hit from just porting, or I would be fine with reverting the async changes and just trying to refactor the existing thread-based code to improve readability and performance (probably using some dedicated threadpools for things and using channels for clearer transfer of data). It's up to you

[trimental]

Hmm yeah to be honest I agree. I was sort of blinding with thinking that async must be better then just blindly spawning threads for each image, but it seems like each image doesn't block long enough for async to really matter.

I'll probably switch it back to a better threaded approach soon. I think queuing up repositions for when images load in, and executing them when main events are cleared is still something to take back when we revert.

[CosmicHorrorDev]

Sounds good to me! I think experimenting with async brought up some new design ideas at the very least :)

I'll try to finish off this PR this weekend. It just needs some refactoring, logging cleanup, and automated testing

[CosmicHorrorDev]

It should now be ready for review!

It's probably easiest to review the new commits while ignoring the refactor: ... commits since it makes diffing a pain

[trimental]

Hey @CosmicHorrorDev. This looks great to me, really clean code as always. I tried for a while to create a simpler read implementation for Rgba8Adapter that performs equally as well but I couldn't. Thanks for all the time you've spent on image efficiency.

Just looks like there's a merge conflict to resolve and then we can merge this 🥳

[CosmicHorrorDev]

Thanks for the review! I'll deal with the merge conflict tomorrow

[CosmicHorrorDev]

Merge should be clean now