With a good heuristic, I think it will be very unlikely that we'll kill a renderer that has useful state. What are the chances that a tab on a site that I don't go to often, and that I opened 30 tabs ago has js/dom state that is critical for me? Mobile browsers already euthanize unused tabs aggressively. Since so few users have 20+ tabs open at once perhaps we can just reset their expectations for what happens if they accumulate a large number of tabs. Perhaps the heuristic could be tied to the mythical great overflow UI. For all of these heavy users I suspect they would prefer chrome to remain zippy fast with large tab sets rather than paging a renderer that 99.9% of the time doesn't have any interesting state. Linus
On Tue, Jul 21, 2009 at 2:03 PM, Scott Hess <sh...@chromium.org> wrote: > > I don't think it's reasonable to require the user to specify which > tabs to suspend, except, perhaps, if we develop a metric for > power-hungry tabs and expose that. > > I think there is some potential for UI geared towards particular > use-cases which could be overloaded to also allow more aggressive > suspend. For instance, WRT my earlier posting, I would expect my > pinned tabs to be given stronger priority, and my on-deck-to-read tabs > to be treated more like preloaded/rendered bookmarks. There could be > other UI advantages in there, like the on-deck tabs for a particular > project could group under a single tab with other UI widgets to select > which document within the group. > > -scott > > > On Tue, Jul 21, 2009 at 1:50 PM, Ryosuke Niwa<rn...@google.com> wrote: > > Is it possible to provide an intuitive UI that allows users to choose > which > > tabs to be suspended? > > For example, just like users can click buttons on taskbar to pop up a > > particular window, we could provide a small window that pop-in tabs / > > windows. And then we can suspend all windows / tab that are popped into. > > Ryosuke > > > > On Tue, Jul 21, 2009 at 9:32 AM, Erik Kay <erik...@chromium.org> wrote: > >> > >> You may be on to something, but I think it's more complex than this. > For > >> example bookmark systems don't work because people use them for a number > of > >> conflicting purposes (my list of things to read every day, a simple > history > >> system, a 'to read' list, a collection of links for research), which > have > >> different UI requirements. I think the same thing has happened with > tabs > >> (and there's a surprising amount of overlap). Here are the use cases I > know > >> I wind up using: > >> - a few long running apps that need to keep running, potentially > notifying > >> me of new events (calendar, mail, chat, buildbot, etc.) > >> - a few pages that I'm currently actively using (a screenshot from a bug > >> I'm looking at, some reference documentation, a writely page I'm editing > >> between compiles, etc.) > >> - a "to read" list of pages that I started reading but didn't finish yet > >> (sometimes this is a collection of related pages when researching > something) > >> - I'm sure there are others. > >> In my use case, 80% of my tabs could easily be killed / suspended (or > even > >> hidden altogether) without any downside to me. The problem is that > there > >> isn't a way to automatically figure out which ones are which. Which > ones > >> have pending state that might be lost? (yes, some of this is bad app > design, > >> but there are many like this) Which ones do I expect to keep running > all of > >> the time because of notifications? What about that flash game that I > left > >> running in the background? > >> Maybe we could come up with some heuristics that could detect some of > this > >> automatically, but I worry that there will be so many exceptions that it > >> won't work. That means we'd need to come up with a better UI to express > >> these concepts where the user chose to treat tabs differently in some > >> explicit way. There are a number of extensions that try to do this for > some > >> specific use cases (to read lists, pinned tabs, etc.). I'm not sure > that > >> these are better than bandaids though. > >> Erik > >> > >> On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee <de...@chromium.org> > wrote: > >>> > >>> I feel like people are using tabs as a replacement for a good history > >>> system. At least in all current browser implementations, tabs are > >>> "running". Even if we can make the UI scale to 1000 tabs, the 500 > >>> flash instances that are likely running aren't really going to > >>> perform. The making tab performance scale is a separate technical > >>> issue that will hopefully also improve. > >>> > >>> Looking at a lot of these design videos, they looked more like good > >>> ideas to me for history navigation than tab navigation. If history > >>> was good, I think people wouldn't be so worried about "losing > >>> something" by closing a tab. Having had bad history systems for so > >>> many years, people are now trained to keep tabs open if they ever > >>> might want to look at that page again in the future :\ > >>> > >>> On Sat, Jul 18, 2009 at 1:16 AM, Peter Kasting<pkast...@google.com> > >>> wrote: > >>> > http://design-challenge.mozilla.com/summer09/ > >>> > The results of the "Reinventing Tabs in the Browser" challenge have > >>> > been > >>> > announced. > >>> > "Collapsible Tab Groups" includes among others some things I've > >>> > proposed, > >>> > including grouping and collapsing groups. > >>> > "Favitabs" reminds me of some old brainstorming ideas from pamg about > >>> > converting certain tabs into favicon buttons. > >>> > Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do > >>> > well > >>> > to take a look at some of these. > >>> > PK > >>> > > > >>> > > >>> > >>> > >> > >> > >> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
