Compressing "Youtube video + controls" screenshot takes forever; prevents home tiles from appearing

[mcomella]

STR:

1. Go to a youtube video
2. Show the controls while the video is playing
3. Quickly open overlay and pin (to trigger screenshot)
4. Click home

Expected: Tile appears with screenshot of youtube
Actual: All custom tiles hang for several seconds (twenty?)

Compressing the screenshot to disk is the operation taking a while, which locks the screenshots file system. Since we block titles showing on screenshots, no tiles are shown. Thoughts:

• This compression blocks a thread and pegs the CPU to 100% on that thread
• We compress with WebP, which seems to take longer than JPEG

Realistic solutions:

• Switch to JPEG compression. It'll be larger on disk and have more artifacts, but we downscale heavily atm so it's probably fine
• Figure out why these screenshots hang and fix them (is it because there's transparency? we can just fill those pixels with a solid color)
• (not recommended) Whitelist pages that cause this problem
• Time-out screenshot loading on the home screen - this would mean no one gets screenshots, but it's better than the title not appearing
• (adds a lot of complexity, probably not worth it) Lock individual screenshot files so the other screenshots can still access the file system
• Cache screenshots in memory

I think we should probably just switch to JPEG or try removing transparency from screenshots, assuming that fixes the problem.

[mcomella]

Another problem with the existing code: the common thread pool has a limited size so when we block it on IO, we're unable to run other coroutines until these methods return – ouch! Concurrency is hard!

[mcomella]

In #627, I mitigated this with fine-grain locking. For this bug, we may want to consider:

• timing-out reads
• if we don't mind increased file sizes with more artifacts, switching to jpeg
• Trying to detect images that take a long time to save (transparency?) and fixing them (or dumping them)

[mcomella]

[triage] This is much less urgent to fix with the mitigation ^.

[IgorGanapolsky]

when we block it on IO, we're unable to run other coroutines

I was under the impression that coroutines are unlimited. You can have tens of thousands of them spawned at once...

[mcomella]

@IgorGanapolsky The number of coroutines you can create is nearly limitless but the number of coroutines actually executing simultaneously is limited.

If a coroutine runs a blocking method, like file or network IO, it blocks the thread it's running on. The default dispatcher, CommonPool, runs on a thread pool with a limited number of threads so if all the threads are blocked, your suspended coroutines need to wait for your threads to be unblocked before they can run.

As a one way around this, there are some coroutine wrappers (which I assume suspend instead of block) around around Java 7's non-blocking io packages: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-nio/