Fix it!

Confirmed. With many tabs, animations are non-existant and speed go to an halt. This problem is true for Firefox as a whole, not just for Panorama. Isolating the main JS thread from the Interface JS thread would fix the problem. It does not even need full JS multithreading, just a second thread just for the gui. I

(In reply to comment #1) > Confirmed. With many tabs, animations are non-existant and speed go to an halt. > This problem is true for Firefox as a whole, not just for Panorama. Isolating > the main JS thread from the Interface JS thread would fix the problem. It does > not even need full JS multithreading, just a second thread just for the gui. > I Actually, as noted in my comments on bug 591709, it looks like the limiting factor here seems to be waiting for the session store to restore the tab data, not synchronicity.

I suggest the following setup for testing: -Direct 2D enabled -image.mem.decodeondraw = true -image.mem.discardable = true -100-200 tabs with big or many images open (opening a large bunch of flickr galleries should do the job) I've experienced severe slowdowns with this configuration and and occasional freezes in firefox (not just inside tabcandy), but i cannot test if it's due to tabcandy or not since there is no option to disable it.

Tabcandy is most useful for large numbers of tabs, but performance degrades significantly with larger numbers of tabs. -On restart of Firefox the Panorama/Group your Tabs page paints the tabs about 1-3 per second, for 150+ tabs this is too long - 50 seconds . From Ian Gilman I understand this is because Firefox renders each tab to get the thumbnail. As thumbnails are tiny - probably 1-5K I suggest that thumbnails are generated when a page is rendered, and saved on exit, and the thumbnail directly loaded on restart. -Target should be for Panorama page to paint at similar speed to any other web page - 1 to 5 seconds. -Numerous events seem also to interrupt painting of the Panorama page - a PDF open in a tab is one, or a modal dialog saying "A script on this page is not responding - wait or continue" (this can come about when lots of tabs are opening at once) -Some tabs do not get loaded sometimes - seems to be the last ones opened, these can get "lost" in bottom right of screen not in a group. -(Related) the Bartab extension is not fully compatible - this unloads inactive tabs using the session manager, and TabCandy loads a lot faster with Bartab enabled, but does not always get all tabs - some of the disabled/unloaded tabs do not get loaded.

John, this is a meta (tracking) bug so I encourage you to create multiple bugs for specific action items or bugs and mark them as blocking this bug. I believe bugs exist for some of the issues you mentioned.

Requesting blocking final+.

(In reply to comment #6) > Requesting blocking final+. I'll go you one better - we should make these changes in time to get beta feedback on them - blocking betaN+.

(In reply to comment #2) > Actually, as noted in my comments on bug 591709, it looks like the limiting > factor here seems to be waiting for the session store to restore the tab data, > not synchronicity. Sorry to spam your tracking bug, but my experience seemed to not have to do with session restore. I restarted my browser hours before I invoked panorama with maybe 25 tabs. It took a few good seconds to render the UI. I have not since seen that happen again, perhaps my browser was busy expiring places records or syncing, you never know. Also, this was on a dual-core 1.6 Ghz thinkpad.

It may be worth using the idea presented in 591912 to help accomplish this goal. That is, load groups which are larger before groups that are smaller.

Beta8 has 1 bug left on it, moving our blockers to b9

Do we still need this meta bug, or should we roll it into bug 604213? At any rate, we've already made progress in this area; not sure how to know when it's good enough.

Not blocking on meta bugs. Please nominate particular deps as necessary.

Has anybody profiled this? Are we spending all of our time encoding images? It doesn't seem that this has been investigated much and it's still pretty slow.

(In reply to comment #14) > Has anybody profiled this? Are we spending all of our time encoding images? > It doesn't seem that this has been investigated much and it's still pretty > slow. I don't know that anyone's done formal profiling on it. It wouldn't be generating the thumbnails from the pages, as that happens as a periodic process outside of the loading sequence. It could be instantiating all of the cached thumbnails, however, or it could be creating all of the DOM elements.

bugspam (moving b9 to b10)

bugspam (removing b9)

(In reply to comment #15) > I don't know that anyone's done formal profiling on it. > > It wouldn't be generating the thumbnails from the pages, as that happens as a > periodic process outside of the loading sequence. It could be instantiating all > of the cached thumbnails, however, or it could be creating all of the DOM > elements. I profiled this today with chromebug and attached the report as a PDF file. These are the results (using UI.init() as starting point) having 5 tabs opened in 2 tab groups. Note that at least some of the TabCanvas.paint() calls are synchronous - the stack trace when setting breakpoints tells that they're directly called from UI.init().

So we're spending our time drawWindow()ing? That doesn't seem to mesh with comment 15.

Tim et al: should we add other dependencies for in-progress work here OR should we close this OR should we punt to the future but keep it open?

bugspam. Moving b10 to b11

bugspam. Removing b10

I'm punting this. Tim, if it's still of use to you, we can keep it open (but punted); otherwise go ahead and close it... I don't think we need yet another perf meta bug.

I'm totally with you.