Closed Bug 825846 Opened 7 years ago Closed 7 years ago
Show the downloads in chunks when scrolling the list
Currently the best option to speed up opening of the new view is to show contents in chunks, unhiding new entries when scrolling down the list. This is feasible per https://bugzilla.mozilla.org/attachment.cgi?id=696370 though it needs some throbber-ish UI and some additional fix.
Provided this is hackish, it seems to do its job. Thus, I'd like to get some feedback at this point. Since this is an interim solution I tried to keep it simple, for example doesn't manage lazy loading of search results, it just caps them to a usable limit. And it doesn't hide again elements unhidden by a search when clearing it. This doesn't have any kind of UI so far, but I honestly don't feel much the lack of it and could be done apart too.
paolo notified me a couple errors in the patch, will fix shortly
since the patch has some dependency on Mano's patches, I fired a try build to test behavior, should be notified here
the right one
Try run for d5336f0a980b is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=d5336f0a980b Results (out of 4 total builds): success: 4 Builds (or logs if builds failed) available at: http://email@example.com
Comment on attachment 698269 [details] [diff] [review] patch v1.2 Alice, would you please check these trybuilds and report if it helps with your hangs?
(In reply to Marco Bonardo [:mak] from comment #7) > Comment on attachment 698269 [details] [diff] [review] > patch v1.2 > > Alice, would you please check these trybuilds and report if it helps with > your hangs? I teste with win32 try build. http://hg.mozilla.org/try/rev/d5336f0a980b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20130105 Firefox/20.0 ID:20130105035353 1: after I chose Downloads in left tree ---It takes about 3sec . it improved about 8sec to 3 sec. but still slower than old view(it display almost instantly). 2.Open any link while stay Library window Bug 825242 ---Tab throbber icon freeze for about 3sec , and then loading start. it is still very slow and BECOME HUGE PROBLEM OF PERFORMANCE NOT IMPROVED ENOUGH 3.Close Browser (File>exit) while stay Library window.The elapsed time when a process disappears from a task manager ---It takes about 2sec . it improved. However, If the new download view scrolled and after listed items completely 2.Open any link while stay Library window Bug 825242 ---Tab throbber icon freeze for about 12sec , and then loading start. it is unusable and HUGE PROBLEM OF PERFORMANCE. NOTHING IMPROVED 3.Close Browser (File>exit) while stay Library window.The elapsed time when a process disappears from a task manager Bug 824260 ---It takes about 15sec, NOTHING IMPROVED
(In reply to Alice0775 White from comment #8) > However, If the new download view scrolled and after listed items completely This is a minor use-case, the really old downloads are there just for link coloring but the probability you actually need to scroll to them is lower the older they are. Both the fact you have thousands of items and the fact you have to scroll to the oldest make the probability very low. On the other side, I was hoping to improve the other case far more than 3 seconds, will check again in the profiler.
(In reply to Alice0775 White from comment #8) > 2.Open any link while stay Library window Bug 825242 > ---Tab throbber icon freeze for about 3sec I can probably fix this in the result, it's likely onVisit doing useless stuff.
Comment on attachment 698269 [details] [diff] [review] patch v1.2 I got all the feedback I needed for now.
My tests on bug 824260 show that having thousands of plain richlistitems in a richlistbox doesn't actually have any notable impact on performance. That's exactly what we're going to have once bug 827405 lands: "inactive" downloads don't get the download binding attached until they're activated (if at all). That, along with the "lazily activate" change in general, eliminates the immediate need for such a complex change. I'd rather wait for it to be implemented in richlistbox "back-end" (to be precise, I'd rather wait for a richlistbox back-end to exist...).
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.