Feature: start RequestManager sooner than onStart(). To reduce latency

[mullender]

The RequestManager is paused until the onStart() lifecycle event is triggered. It might be better to start the RequestManager sooner in the lifecycle (in addition to onStart) for example by creating the request manager in the started state.
I do not know what the reasoning is to postpone the start of the request manager, there is probably a good reason :)

The reason for this request is the following observation.
I have an app that:

1. preloads images from the Application.onStart()
2. loads the images into the ImageView from Fragment.onActivityCreated()

From the logs I can tell that the loading into the ImageView results in a MEMORY_CACHE hit in under 1ms.
However the RequestListener.onResourceReady() is not called until the RequestManager is started.

The result is an additional latency of about 80-100ms (depends on device and layout)

When I force the requestManager to start immediately after I load the url into() the ImageView the latency disappears.

[TWiStErRob]

The following is just a guess, let's hear from @sjudd about the design decision.

The view becomes visible after onStart though I'm not sure when the first layout is. Glide uses a predrawlistener, which is probably only called after onStart. Are you by any chance using .override()? If so you could have an early start as you said. You can manually resume when you like it, but for the most cases the size is not known until later so the load cannot start even if the manager is resumed.

Even cold start time was reduced by using the modules to be able to delay class loading and construction until the first usage so user has something to look at faster. See #299.

[sjudd]

It's quite easy to start the RequestManager earlier if it would help in a specific case: Glide.with(context).resumeRequests(). You can call onStart() as well, though that will call the corresponding method on Target objects, which might be unexpected.

That said, my understanding is that ui isn't visible to the user until onStart() is called. If those images are already cached in memory by the time onStart() is called, there shouldn't be any visible delay? Is 80-100ms the visible delay, or the time between onCreate() being called and onStart() being called?

The documentation claims:

The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop()

[mullender]

Thanks guys for such insightful comments so quickly! (It also made me discover inline code markdown)
@TWiStErRob, I am indeed using .override() so the Target can immediately resolve its dimensions.

@sjudd I believe you are correct and the latency is the time between onCreate() and onStart(). I will run some experiments using adb shell screenrecord to see if the difference is visible or simply because I measure the wrong thing. i.e. measuring onResourceReady() instead of image rendered on screen.

All this to say: Getting onResourceReady to trigger sooner might not mean that the image is rendered on screen sooner. This is something I will need to verify.

[mullender]

@TWiStErRob @sjudd
I had some time to perform the experiment.

• When calling resumeRequests() the text and image display at the same time.
• Without that call the text displays first, and the 2 images display after about 300ms

It is not a big deal as there is a documented api to work around the issue.