Users should have access to the information required to show image load progress

[ohif-bot]

Created By: #620

Context:

Some studies/images are very large, and loading them in their entirety can take a fair amount of time (especially over slower connections or on congested networks). Having some mechanism to show load progress may improve the end user experience.

That being said, this is a tricky problem as there are many ways we can show progress. It gets a bit messier when you consider that loaded images may have exited the cache if we've exceeded our cache's size. This is more true now than ever with our beefier segmentation labelmap and volume rendering.

To accommodate as many cases as possible, we should create a service that tracks loading/cache stats, and can be consumed/used (like by an overlay text layer) to report that information in the way the implementer prefers.

Acceptance Criteria:

This information exists, to some extent, in Cornerstone's cache and via loadHandlerManagers. We need something a bit more generic.

A new service in platform/core that tracks and can be queried for the following:

• State of study (given studyInstanceUid)
  • Total, in-flight (pending XHR), completed, isCached
• State of series (given seriesInstanceUid)
  • Total, in-flight (pending XHR), completed, isCached
• State of image (given imageInstanceUid)
  • in-flight, completed, isCached

This may not be as flexible as we'd like, given that a "stack" is not always a single series, but it's a good/simple first stab.

• A simple progress bar on each thumbnail that shows load percentage
  • Where load percentage is determined by "cached" or completed "xhr"

[dannyrb]

Related: The react-cornerstone-viewport now provides image loading progress to a component prop.

[whage]

I would also like this feature in the new v3 version of the viewer. We are currently transitioning from v2 (v4.12.51.21579) to v3 (3.6.0).
I found a couple other issues about the same topic ("show progress to the user so he doesn't rage quit") the others seem to be closed and are pointing to this one.
I guess this was reported in OHIF v2 times, do the above notes by @dannyrb still apply for the current (v3) version?
Is there a more recent or up to date issue about the some topic?
Is this maybe something configurable in OHIF v3?

[sedghi]

@whage please file in all the issues you found, it helps us maintain the project

[sedghi]

We will track it here #3363