Minor improvements

[Khang-NT]

1. Decoding & transforming image tasks consume heavy CPU resources, it's CPU bound task so should use Dispatchers.Default as default. Proof: in the example app, go to the "MP4" screen and the app will be freezzing.
2. ViewTargetRequestDelegate: unregister lifecycle observer as soon as the request is complete, so itself will be eligible for GC.

[colinrtwhite]

Appreciate the work, though I'm not sure that we can merge all the changes. I added a few comments.

[colinrtwhite]

Why is it better to use context.resources in this case?

[Khang-NT]

In general, it's because the Configuration is different between:

applicationContext.getResources().getConfiguration()
AND
activityContext.getResources().getConfiguration()

The Application context is first constructed with a default Configuration of the system, then Activity inherits and extends that configuration with its state, for example, Application context may have Configuration#orientation = PORTRAIT, but Activity context has Configuration#orientation = LANDSCAPE therefore the resource retrieved will be different if it's varied by orientation.

PackageManager#getResourcesForApplication will returns a Resource object with default system Configuration, same as applicationContext.resources.
So we better use the context from ImageRequest object.

[colinrtwhite]

Ah great point! So we're actually using the application resource object here? Sounds like this could potentially fix: #954

[Khang-NT]

Yeah, it fixes both #752 and #954

[colinrtwhite]

I think we actually want to keep this as Dispatchers.IO as it's unlikely, but possible some IO will be done while decoding. Also changing this to Dispatchers.Default doesn't fix the issue with the video frames in the sample app - that's due to MediaMetadataRetriever being slow and not supporting cancellation. Unfortunately, there's not much we can do to optimize that.

[Khang-NT]

Yeah, you're right. I observed lagging in demo when switch from MP4 screen to JPG, I thought 100% CPU is stolen, but I ran CPU profiler and saw the CPU isn't stolen that much, it just because Dispatchers.IO is out of room (MediaMetadataRetriever hanging), and the ImageListAdapter's differ is also scheduled in Dispatchers.IO.

coil/coil-sample/src/main/java/coil/sample/Utils.kt

Lines 53 to 57 in 986e91d

	fun <T> DiffUtil.ItemCallback<T>.asConfig(): AsyncDifferConfig<T> {
	return AsyncDifferConfig.Builder(this)
	.setBackgroundThreadExecutor(Dispatchers.IO.asExecutor())
	.build()
	}

[Khang-NT]

MediaMetadataRetriever being slow and not supporting cancellation

Did you try runInterruptible or just call MediaMetadataRetriever#realease() early to support cancellation?

[colinrtwhite]

@Khang-NT Sorry forgot to respond to this. I tried out runInterruptible and calling release if the coroutine is cancelled and unfortunately neither free up the thread that's decoding. In fact, I was able to get MediaMetadataRetriever to completely lock up and never return by using release while the decode was in progress.

[colinrtwhite]

Thanks!