Comment 3 for bug 139053

The underlying cause of this bug is that each repository file can refer to one or more other files that also have to be read. So we don't know, ahead of time, the total number of files that will need to be read (much less the size of each). An analogous problem occurs in displaying page load progress for Web browsers, where an HTML resource may refer to other resources such as images, frames, scripts, and style sheets, and many of those may in turn refer to still other resources that need to be loaded.

A simple solution, where
    p = the value of the progress meter (between 0 and 1)
    t = now
    t' = the previous time the progress meter was rendered
    F = the total number of files needing to be read that are known so far
    f = the proportion of those files that have been read so far (including the fraction(s) of the current file(s))
would be to render the progress meter as
    p(t) = p(t') + (f(t)-f(t'))/F.

This would at least ensure that the progress meter went from 0% to 100% only once, and never went backwards, so implementing it by itself it would be an improvement on the current behavior.

The next problem would be that the progress bar started off quickly (when F was small) and then slowed down depressingly as F became larger. (The progress meter in Internet Explorer for Windows has this problem, probably for the same reason.) The solution to this would be to scale the above function using a curve that incorporates a hard-coded constant for the *average* number of extra repository files (r) a typical repository file refers to. In other words, adjust the progress to be slower near the beginning and faster near the end, exactly counterbalancing the average gradual increase in F. Unfortunately I don't know enough maths to know what that curve would be (though I'll go out on a limb and guess that it involves a logarithm to the base of r).