I think people are legitimately concerned about the memory use of this feature. I don't think anyone is trying to dismiss anything here. I still don't fully understand why we need a full size screenshot of the last N pages. Is the last page sufficient and we redraw the rest while we animate? I am sure you guys considered this, so I am curious why this was excluded.
Thanks, Andreas On Feb 12, 2013, at 11:29 PM, Asa Dotzler <a...@mozilla.com> wrote: > On 2/12/2013 8:05 PM, Andreas Gal wrote: >> Hey Asa, >> >> where does the magic 20 pages deep history number come from? Why not 1? Or >> 999? >> >> Andreas > > The goal of the feature is to work when ever the user engages it and not just > "for the first couple of pages". > > Just have one and too many users would fall off of their back stack very > quickly. Nine hundred ninety nine and we'd be wasting memory for all but a > very small minority of users who accumulate and navigate through that much > history. > > We have Test Pilot data we could use to fine tune this, maybe we only need > 15, or maybe we actually need 25. > > My point isn't to quarrel about the depth of that back stack, but to say that > it is not OK to simply dismiss a new feature because it increases memory > footprint. Features vs footprint is a balancing act. Both sides must be > weighed and that wasn't what I saw happening here. What I saw happening was > the out of hand dismissal of a feature based on no consideration other than > increased memory footprint. That cannot be how we roll. > > - A > > >> >> On Feb 12, 2013, at 9:40 PM, Asa Dotzler <a...@mozilla.com> wrote: >> >>> On 2/12/2013 3:08 PM, Ed Morley wrote: >>>> On 12 February 2013 22:11:12, Stephen Pohl wrote: >>>>> I wanted to give a heads up that we're in the process of finalizing >>>>> the patch for bug 678392 which will give us history swipe animations >>>>> on Mac OSX 10.7+. Since we will be taking snapshots of the 20 >>>>> most-recently visited pages, this will undoubtedly lead to an increase >>>>> in memory utilization on these platforms. >>>> >>>> To save everyone having to look at the graph - the initial landing >>>> showed a consistent 20% regression in trace malloc maxheap. If this were >>>> a 1-5% regression, then I think it would be worth discussing the >>>> trade-off. At 20%, I really don't see how we can take this, sorry! :-( >>>> >>>> Ed >>> >>> I don't see how we can *not* take this. Of course it's going to mean using >>> more memory. If it doesn't leak, and it doesn't put us over some magic >>> limit where a significant portion of our users end up paging or something >>> like that, then I don't see how we can reject it. >>> >>> Without context, 1-5% or 20% growth are just meaningless numbers. The >>> context here is not some accidental regression or a feature doing something >>> horribly wrong with memory. This is simply a memory-expensive feature and >>> it's a feature we *must* land. >>> >>> I'm all for smart people looking for ways to get this memory usage as low >>> as it can be without undermining the value of the feature, but if we cannot >>> find those wins, we should land this as it is. >>> >>> >>> - A >>> _______________________________________________ >>> dev-platform mailing list >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >> > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
