The problem being fixes is the progress meter UI will not display when we are dowloading
XPI files from the net (see bug report for more details). We were throttling the update
of progress bar based on some interval being exceeded. The problem is/was that sometimes
the XPI is downloaded faster than the specified interval (a series of these renders the
progress bar "dead", and the user has no feedback UI as to what is happening). It is not
entirely clear that the time interval computation is correct to being with. The safe thing
to do here is to simply let the UI update whenever necko invokes our progress callback,
and dispense with the throttling. This results in a smooth UI update and has minimal
performance sideaffects (we are limited more by the network I/O and disk writes that the
progress bar UI update).
This commit is contained in:
syd%netscape.com 2001-05-30 00:46:16 +00:00
Родитель e34e2a237c
Коммит 1856715b38
1 изменённых файлов: 2 добавлений и 5 удалений

Просмотреть файл

@ -78,12 +78,9 @@ static NS_DEFINE_CID(kEventQueueServiceCID, NS_EVENTQUEUESERVICE_CID);
// Mac can't handle PRTime as integers, must go through this hell
inline PRBool nsXPInstallManager::TimeToUpdate(PRTime now)
{
PRTime diff;
LL_SUB(diff, now, mLastUpdate);
// XXX lets revisit this when dveditz gets back
PRInt32 interval;
LL_L2I(interval, diff);
return (interval > 250000);
return PR_TRUE;
}
nsXPInstallManager::nsXPInstallManager()