Re: Off-main-thread Painting
On 12 February 2013 13:05:33, Jean-Marc Desperrier wrote: Matt Woodrow a écrit : to improve both performance and responsiveness of the browser, we are planning on moving painting to happen on a separate thread. I think you should take some time to consider what impact it has on the synchronization between interactive events and what is visible. - Browser receive the order to draw Y above X - I click on X that I'm still seeing - Browser asynchronously actually draws Y What does the browser consider I clicked on ? It may happen that the browser considers I clicked Y while I was seeing X. Especially if the intend is to improve responsiveness, which means that I can click whilst the browser is painting, so it may be unclear what I intended to click on. I'm not sure this situation is really affected at all. This would be an issue currently with just OMTC, as well as under the proposed scheme. A similar situation that could happen is that you scroll down and the page changes in response to the scroll change. This would still be an issue with current asynchronous compositing, but the difference is you may get to an area with just OMTC that would be blank, where as it would more likely be visible (and incorrect) under this scheme. Neither of these situations are an issue until rendering takes a significant amount of time, though. The proposed scheme might actually make this easier to fix. We currently do hit detection by drawing a pixel of the display list (I think?) and seeing what gets drawn. If we're separating the display list from external dependencies, we could theoretically use it for hit detection so that there isn't a mismatch between what's on the screen and the current Gecko-side state. I think it'd be more sensible to look into this if it ever becomes an issue, but certainly something to consider. --Chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: HTML Working Group
On 2/8/2013 5:37 PM, L. David Baron wrote: W3C is proposing a revised charter for the HTML Working Group. For more details, see: http://lists.w3.org/Archives/Public/public-new-work/2013Feb/0009.html http://www.w3.org/html/wg/charter/2012/ Mozilla has the opportunity to send comments or objections through Tuesday, March 12. Please reply to this thread if you think there's something we should say. The only really interesting thing in the new charter seems to be the explicit call for standardizing playback of protected content for the HTMLMediaElement, which is pretty much codewords for DRM. DRM is fundamentally at odds with the notion of an open web and the HTML specification. The purpose of good specifications is to make it possible for anyone to implement a browser that can render the web. The purpose of DRM is to make it possible for content owners to give only some browsers the ability to play their content. DRM also defeats save, sharing, and remixing, which are fundamental aspects of the web. Whether or not there are practical short-term compromises that should be made to make a better alternative to Silverlight, I don't think that it should be within the scope of HTML to do that; it should be a separate effort, highly targeted at solving the devices based on HTML currently can't play netflix content problem without making any long-term commitments to DRM in the browser. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
On Tuesday 2013-02-12 11:17 +, Chris Lord wrote: Sounds good, I'd like to help if I can. How would this affect the display-list optimisation process - would we transfer across the unoptimised display list and re-optimise and process for each viewport change? I assume with OMTC, we'd still async scroll like we do now, but paints would just come in much faster? Constructing and transferring an unoptimized display list for an entire page (rather than just a viewport of it) seems to me like something that would be too expensive for large pages, especially without a way to update just a piece of it in response to dynamic changes. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
I think we need a stronger statement than worthwhile in this: It would be worthwhile to wait for the Layers refactoring to be completed to avoid too many conflicts. when it comes to actually landing code. Something like we should or even we must comes to mind :-) That doesn't preclude conversations, design, etc., we just can't afford to delay the layers refactoring. Milan On 2013-02-12, at 2:21 AM, Matt Woodrow mwood...@mozilla.com wrote: Hi All As an effort to improve both performance and responsiveness of the browser, we are planning on moving painting to happen on a separate thread. My initial draft plan to do this can be found here: https://wiki.mozilla.org/Gecko:OffMainThreadPainting Some of the details still need to be worked out, in particular coordinating with other platform teams to make sure everything we need is available off the main thread. Please let me know if you have an queries, input or want to be involved. - Matt ___ 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
Re: Off-main-thread Painting
On Feb 12, 2013, at 9:50 AM, Milan Sreckovic msrecko...@mozilla.com wrote: I think we need a stronger statement than worthwhile in this: It would be worthwhile to wait for the Layers refactoring to be completed to avoid too many conflicts. when it comes to actually landing code. Something like we should or even we must comes to mind :-) That doesn't preclude conversations, design, etc., we just can't afford to delay the layers refactoring. I am a little concerned that we are putting so many things on hold for the refactoring. Do we have a somewhat established schedule for that now, or is the timing still fairly open-ended? Is there any chance that we can start landing some parts of it incrementally? Andreas Milan On 2013-02-12, at 2:21 AM, Matt Woodrow mwood...@mozilla.com wrote: Hi All As an effort to improve both performance and responsiveness of the browser, we are planning on moving painting to happen on a separate thread. My initial draft plan to do this can be found here: https://wiki.mozilla.org/Gecko:OffMainThreadPainting Some of the details still need to be worked out, in particular coordinating with other platform teams to make sure everything we need is available off the main thread. Please let me know if you have an queries, input or want to be involved. - Matt ___ 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
Re: Off-main-thread Painting
I assume we would send the same diff we use for DLBI over to the painting thread to minimize the cost. How would this new design interact with the current refresh driver scheduling? --Jet - Original Message - From: L. David Baron dba...@dbaron.org To: Chris Lord cl...@mozilla.com Cc: dev-platform@lists.mozilla.org, Matt Woodrow mwood...@mozilla.com, Robert O'Callahan r...@ocallahan.org Sent: Tuesday, February 12, 2013 8:04:38 AM Subject: Re: Off-main-thread Painting On Tuesday 2013-02-12 11:17 +, Chris Lord wrote: Sounds good, I'd like to help if I can. How would this affect the display-list optimisation process - would we transfer across the unoptimised display list and re-optimise and process for each viewport change? I assume with OMTC, we'd still async scroll like we do now, but paints would just come in much faster? Constructing and transferring an unoptimized display list for an entire page (rather than just a viewport of it) seems to me like something that would be too expensive for large pages, especially without a way to update just a piece of it in response to dynamic changes. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ 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
Re: Off-main-thread Painting
I'm not too concerned about the landing schedule here as I don't expect to see OMTP landing too soon (though mwoodrow has surprised us before.) We should have plenty of runway between the required Layers work and OMTP. Let's put OMTP (and prerequisites) on the next Rendering call agenda. This should be a lively discussion. --Jet - Original Message - From: Milan Sreckovic msrecko...@mozilla.com To: Matt Woodrow mwood...@mozilla.com Cc: Robert O'Callahan r...@ocallahan.org, dev-platform@lists.mozilla.org Sent: Tuesday, February 12, 2013 6:50:42 AM Subject: Re: Off-main-thread Painting I think we need a stronger statement than worthwhile in this: It would be worthwhile to wait for the Layers refactoring to be completed to avoid too many conflicts. when it comes to actually landing code. Something like we should or even we must comes to mind :-) That doesn't preclude conversations, design, etc., we just can't afford to delay the layers refactoring. Milan On 2013-02-12, at 2:21 AM, Matt Woodrow mwood...@mozilla.com wrote: Hi All As an effort to improve both performance and responsiveness of the browser, we are planning on moving painting to happen on a separate thread. My initial draft plan to do this can be found here: https://wiki.mozilla.org/Gecko:OffMainThreadPainting Some of the details still need to be worked out, in particular coordinating with other platform teams to make sure everything we need is available off the main thread. Please let me know if you have an queries, input or want to be involved. - Matt ___ 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
Re: Off-main-thread Painting
There is definitely a lot of prerequisites we can work on first. Making all the DL code self-containing means eliminating much of nsCSSRendering.cpp, which is probably quite some refactoring work we can do right now. Andreas On Feb 12, 2013, at 12:24 PM, Jet Villegas j...@mozilla.com wrote: I'm not too concerned about the landing schedule here as I don't expect to see OMTP landing too soon (though mwoodrow has surprised us before.) We should have plenty of runway between the required Layers work and OMTP. Let's put OMTP (and prerequisites) on the next Rendering call agenda. This should be a lively discussion. --Jet - Original Message - From: Milan Sreckovic msrecko...@mozilla.com To: Matt Woodrow mwood...@mozilla.com Cc: Robert O'Callahan r...@ocallahan.org, dev-platform@lists.mozilla.org Sent: Tuesday, February 12, 2013 6:50:42 AM Subject: Re: Off-main-thread Painting I think we need a stronger statement than worthwhile in this: It would be worthwhile to wait for the Layers refactoring to be completed to avoid too many conflicts. when it comes to actually landing code. Something like we should or even we must comes to mind :-) That doesn't preclude conversations, design, etc., we just can't afford to delay the layers refactoring. Milan On 2013-02-12, at 2:21 AM, Matt Woodrow mwood...@mozilla.com wrote: Hi All As an effort to improve both performance and responsiveness of the browser, we are planning on moving painting to happen on a separate thread. My initial draft plan to do this can be found here: https://wiki.mozilla.org/Gecko:OffMainThreadPainting Some of the details still need to be worked out, in particular coordinating with other platform teams to make sure everything we need is available off the main thread. Please let me know if you have an queries, input or want to be involved. - Matt ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Sparse localizations of toolkit and the chrome registry's getSelectedLocale()
Hi Benjamin, Dave, for mobile (and fxos) we're looking into doing sparse localizations of toolkit. The work on the mobile side is bug 792077. The current attempt is to leave the 'global' and other toolkit packages untranslated, and use chrome overrides to supply a few localized files, as needed by fx-android or -os. That's all kinda nice and shiny, but it horribly breaks getSelectedLocale(package), as that returns 'en-US' for 'global' and friends. Breaks all kinds of url reporters and rtl detection. Next step is to figure out if there's an acceptable way to make this work still. I had three ways in my head: - make the chrome urls/channels fall back to en-US and really have sparse toolkit localizations. This sounds really intrusive, and probably hard. - make all call-sites of getSelectedLocale work around that, which I don't think is feasible. - add a prefbranch that gives package overrides or so, so that the chrome reg would return the selected locale for the override package instead of the one it's getting asked for, something like pref(chrome.locale.override.global, browser); https://bugzilla.mozilla.org/show_bug.cgi?id=792077#c17 I personally favor the third option. Does that sound feasible to you? Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linux Firefox extension on ff17 needs gcc 4.5
On 13-02-08 3:18 AM, kv wrote: Can some body help me how can i compile native extension on 32 bit RHEL with gcc 4.5.2, if the package is not available for update. It doesn't look like there's an official package for rhel 5 or 5. You can compile and install 4.5.2 (or the latest version) and use that to build your extension. =r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Sparse localizations of toolkit and the chrome registry's getSelectedLocale()
On 2/12/2013 12:41 PM, Axel Hecht wrote: Hi Benjamin, Dave, for mobile (and fxos) we're looking into doing sparse localizations of toolkit. The work on the mobile side is bug 792077. The current attempt is to leave the 'global' and other toolkit packages untranslated, and use chrome overrides to supply a few localized files, as needed by fx-android or -os. That's all kinda nice and shiny, but it horribly breaks getSelectedLocale(package), as that returns 'en-US' for 'global' and friends. Breaks all kinds of url reporters and rtl detection. Why does getSelectedLocale(package) matter? Who uses that API to make important decisions? And can we just change the callers to do something different? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: HTML Working Group
On Tuesday, February 12, 2013 11:02:16 AM UTC-5, Benjamin Smedberg wrote: On 2/8/2013 5:37 PM, L. David Baron wrote: W3C is proposing a revised charter for the HTML Working Group. For more details, see: http://lists.w3.org/Archives/Public/public-new-work/2013Feb/0009.html http://www.w3.org/html/wg/charter/2012/ Mozilla has the opportunity to send comments or objections through Tuesday, March 12. Please reply to this thread if you think there's something we should say. Is it just me, or is this fundamentally flawed from a security standpoint as well - malicious content able to hide from analysis by browser-enforced DRM? No thanks. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
We need to have a cheap snapshot mechanism. There are a number of options that have different cost models. Options include: * Locking * Defensive copying * COW (Copy-on-write) * Immutable trees O(log n) I'd like to see less of the first two and more of the last two. We need to create better abstractions for COW and immutable trees. On 13/02/13 06:17, Jet Villegas wrote: I assume we would send the same diff we use for DLBI over to the painting thread to minimize the cost. How would this new design interact with the current refresh driver scheduling? --Jet - Original Message - From: L. David Baron dba...@dbaron.org To: Chris Lord cl...@mozilla.com Cc: dev-platform@lists.mozilla.org, Matt Woodrow mwood...@mozilla.com, Robert O'Callahan r...@ocallahan.org Sent: Tuesday, February 12, 2013 8:04:38 AM Subject: Re: Off-main-thread Painting On Tuesday 2013-02-12 11:17 +, Chris Lord wrote: Sounds good, I'd like to help if I can. How would this affect the display-list optimisation process - would we transfer across the unoptimised display list and re-optimise and process for each viewport change? I assume with OMTC, we'd still async scroll like we do now, but paints would just come in much faster? Constructing and transferring an unoptimized display list for an entire page (rather than just a viewport of it) seems to me like something that would be too expensive for large pages, especially without a way to update just a piece of it in response to dynamic changes. -David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
On Wed, Feb 13, 2013 at 6:17 AM, Jet Villegas j...@mozilla.com wrote: I assume we would send the same diff we use for DLBI over to the painting thread to minimize the cost. No, the plan is to ship the entire unoptimized display list over to the painting thread and do optimization and DLBI processing there. This should be similar in overall cost to what we do today (but more parallel). How would this new design interact with the current refresh driver scheduling? Not much. The refresh driver would still run on the main thread and work like it does today. The painting thread would be an extra stage whose execution would probably be triggered by the completion of the display list in the refresh driver, i.e. implicitly scheduled by the refresh driver. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
On Wed, Feb 13, 2013 at 9:43 AM, Robert O'Callahan rob...@ocallahan.orgwrote: A large chunk of the work of off-main-thread painting is refactoring display lists to be independent of frames, which definitely can and should be done incrementally and could be done in parallel with the layers refactoring. I still think it should wait till after the layers refactoring so all possible resources are on deck for layers. Also there are a couple of simplifications to the display list stuff I'd like to make before we do this: -- Stop using explict nsDisplayClip items and simply attach clipping data to each display item (making display list construction do what FrameLayerBuilder already does internally). Large numbers of nsDisplayClips slow down display list processing, especially on B2G. -- Make BuildDisplayList infallible. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Sparse localizations of toolkit and the chrome registry's getSelectedLocale()
On 12.02.13 20:27, Benjamin Smedberg wrote: On 2/12/2013 12:41 PM, Axel Hecht wrote: Hi Benjamin, Dave, for mobile (and fxos) we're looking into doing sparse localizations of toolkit. The work on the mobile side is bug 792077. The current attempt is to leave the 'global' and other toolkit packages untranslated, and use chrome overrides to supply a few localized files, as needed by fx-android or -os. That's all kinda nice and shiny, but it horribly breaks getSelectedLocale(package), as that returns 'en-US' for 'global' and friends. Breaks all kinds of url reporters and rtl detection. Why does getSelectedLocale(package) matter? Who uses that API to make important decisions? And can we just change the callers to do something different? --BDS http://mxr.mozilla.org/mozilla-central/ident?i=getSelectedLocalefilter= is the call-sites. There's a bunch of .getSelectedLocale(global) to determine the currently active locale, independent of OS settings on linux. The other half of it is http://mxr.mozilla.org/mozilla-central/ident?i=IsLocaleRTL, which is a tad harder to resolve. That depends all over the place. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: HTML Working Group
2013/2/12 Robert O'Callahan rob...@ocallahan.org On Wed, Feb 13, 2013 at 5:02 AM, Benjamin Smedberg benja...@smedbergs.us wrote: The only really interesting thing in the new charter seems to be the explicit call for standardizing playback of protected content for the HTMLMediaElement, which is pretty much codewords for DRM. DRM is fundamentally at odds with the notion of an open web and the HTML specification. The purpose of good specifications is to make it possible for anyone to implement a browser that can render the web. The purpose of DRM is to make it possible for content owners to give only some browsers the ability to play their content. DRM also defeats save, sharing, and remixing, which are fundamental aspects of the web. Whether or not there are practical short-term compromises that should be made to make a better alternative to Silverlight, I don't think that it should be within the scope of HTML to do that; it should be a separate effort, highly targeted at solving the devices based on HTML currently can't play netflix content problem without making any long-term commitments to DRM in the browser. If you really care about this, please contribute to the discussions on public-html-admin/public-html-media. Thanks :-) I agree wholeheartedly with Benjamin and care about this, but I don't have a lot of time to get into this presumably time-consuming discussion on a W3C mailing list --- so I'd just like to express support to any Mozilla representative fighting this fight there. Beyond the objection of principle (which I agree too -- DRM is incompatible with the notion of open standards), I'd also make the argument that we shouldn't let content owners impress us too easily with claims that particular protection measures would be a requirement before serious content would move to open Web standards. In the WebGL working group we've received input from content developers/owners claiming that various flavors of protection (e.g. they wanted binary shader formats) were a requirement before any serious commercial content would move to the open Web platform. We just ignored them, and big content started moving to WebGL anyways. Benoit Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ 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
Re: Off-main-thread Painting
I agree in part with the assertion about testing - that the existing reftests will catch most regressions stemming from this. But I think we also need some measurements around scrolling/responsiveness in order to verify that off main thread painting is giving us the wins we hope it will give us. Part of that is knowing where we are now, and then seeing how that measurement will change once this work lands. We can use Eideticker for doing some of this measurement (particularly for blackbox end-to-end measurements, but it would be even better if there were some way to instrument the paint pipeline so that we could get measurements from inside Gecko itself. If we can instrument it, we can run those tests per-checkin on all our products. So I'd encourage you to put a bit of thought into how you might do some light weight instrumentation in this code so we can verify we make the gains we hope to make here. Clint ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
Hi, 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. There is a discussion about experimental memory measurements in comment 305 and 309 in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=678392#c305 https://bugzilla.mozilla.org/show_bug.cgi?id=678392#c309 We attempted to land the patch late last week but ran into test failures caused (most-likely) by not forcing a clobber. The upside of it is that it gave us feedback from Talos and an opportunity to email the list for feedback before making another attempt at landing the patch. The Trace Malloc MaxHeap regression is documented in this graph: http://graphs.mozilla.org/graph.html#tests=[[29,63,22]]sel=1360274365000,1360447165000displayrange=7datatype=running We'd like to make sure that this increase is acceptable before landing the patch. If you have any feedback, please let me know. Thanks, Stephen ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
On 13/02/13 09:52, Robert O'Callahan wrote: On Wed, Feb 13, 2013 at 9:20 AM, Anthony Jones ajo...@mozilla.com mailto:ajo...@mozilla.com wrote: We need to have a cheap snapshot mechanism. We don't need that for this. The display list can be constructed on the main thread and ownership transferred to the painting thread. We always construct the display list from scratch today so this is not architecturally difficult. It will be significantly more responsive if we can process repaints (for scrolling) without being blocked by scripts. What do we need to do to make that happen? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
Stephen: We talked about extracting this snapshot from the GFx Layers. Have you explored that possibility? Taking the screencap from the raster data we already paint should help here. BTW, 20 seems to be a very high number to cache per tab. The biggest problem I'd like to solve is that I often accidentally swipe back, and that's almost always just 1 page back. --Jet - Original Message - From: Stephen Pohl sp...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Tuesday, February 12, 2013 2:11:12 PM Subject: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations Hi, 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. There is a discussion about experimental memory measurements in comment 305 and 309 in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=678392#c305 https://bugzilla.mozilla.org/show_bug.cgi?id=678392#c309 We attempted to land the patch late last week but ran into test failures caused (most-likely) by not forcing a clobber. The upside of it is that it gave us feedback from Talos and an opportunity to email the list for feedback before making another attempt at landing the patch. The Trace Malloc MaxHeap regression is documented in this graph: http://graphs.mozilla.org/graph.html#tests=[[29,63,22]]sel=1360274365000,1360447165000displayrange=7datatype=running We'd like to make sure that this increase is acceptable before landing the patch. If you have any feedback, please let me know. Thanks, Stephen ___ 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
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
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! :-( I hope it's not adding noise to say, what Ed said. -Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
Hi Jet, Extracting the snapshot from the GFx layer has not been explored yet. I think we discussed this in the context of the time it takes to create the snapshots. Since this will be handled off the main thread (bug 817700) we expect a pretty good performance there. I believe we would still incur the memory cost however to store the snapshots. Do I recall this conversation correctly? The limit of 20 snapshots is currently per window (not per tab). In bug 839549, I'd like to switch to a WeakMap to store the snapshots and make the limit of 20 global to all windows. I'm not very familiar with the Trace Malloc MaxHeap tests, but if they use lots of windows, it may explain a jump of 20% in memory utilization and I may have to address bug 839549 sooner than later. I hope this clarifies things. -Stephen Original Message Subject: Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations From: Jet Villegas j...@mozilla.com To: Stephen Pohl sp...@mozilla.com Cc: dev-platform@lists.mozilla.org Date: 2/12/13 3:29 PM Stephen: We talked about extracting this snapshot from the GFx Layers. Have you explored that possibility? Taking the screencap from the raster data we already paint should help here. BTW, 20 seems to be a very high number to cache per tab. The biggest problem I'd like to solve is that I often accidentally swipe back, and that's almost always just 1 page back. --Jet - Original Message - From: Stephen Pohl sp...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Tuesday, February 12, 2013 2:11:12 PM Subject: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations Hi, 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. There is a discussion about experimental memory measurements in comment 305 and 309 in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=678392#c305 https://bugzilla.mozilla.org/show_bug.cgi?id=678392#c309 We attempted to land the patch late last week but ran into test failures caused (most-likely) by not forcing a clobber. The upside of it is that it gave us feedback from Talos and an opportunity to email the list for feedback before making another attempt at landing the patch. The Trace Malloc MaxHeap regression is documented in this graph: http://graphs.mozilla.org/graph.html#tests=[[29,63,22]]sel=1360274365000,1360447165000displayrange=7datatype=running We'd like to make sure that this increase is acceptable before landing the patch. If you have any feedback, please let me know. Thanks, Stephen ___ 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
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
On Tue, Feb 12, 2013 at 3:29 PM, Jet Villegas j...@mozilla.com wrote: BTW, 20 seems to be a very high number to cache per tab. The biggest problem I'd like to solve is that I often accidentally swipe back, and that's almost always just 1 page back. That was my first thought, too. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
On Wed, Feb 13, 2013 at 12:28 PM, Matt Woodrow mwood...@mozilla.com wrote: This is the second half of the plan. Third paragraph of 'Proposed Solution' The basic idea is that the display list owned by the painting thread already contains all the information required to render the page at any scroll position. As dbaron said, we can't do this for literally *any* scroll position. We can't for example create a display list for the entire HTML5 spec. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
Can we compress these screenshots to JPEG or something? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
We use canvas.toBlob() to compress the snapshots to PNG. I ran a few experiments with JPG, but the results seemed to even out between PNG and JPG (with 100% quality). Choosing a lower quality for JPG compression quickly started to look bad, especially on retina displays. Comment 176 had a few details around this: https://bugzilla.mozilla.org/show_bug.cgi?id=678392#c176 -Stephen Original Message Subject: Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations From: Robert O'Callahan rob...@ocallahan.org To: Stephen Pohl sp...@mozilla.com Cc: dev-platform@lists.mozilla.org Date: 2/12/13 4:44 PM Can we compress these screenshots to JPEG or something? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
New Release Notes Process (relnote-firefox flag)
[x-post to dev.planning and dev.platform]
In relation to release notes process, we've gotten a couple of pieces of
feedback in recent memory:
1) It's not clear how to mark something as a release notes candidate (some have
used the relnote keyword in the past)
2) It's not clear whether something will actually be noted
3) Sometimes a feature or known issue is (correctly or otherwise) release noted
without devs being aware
We're creating a new tracking flag to resolve all three of these issues. You'll
now find relnote-firefox on any bug that can be nominated for tracking. If
you'd like a feature or known issue considered for release noting, just set
relnote-firefox:?. If we agree, we'll either set the flag to
relnote-firefox:{version}+ for the first version of Firefox the feature will be
present in, or just relnote-firefox:+ for known issues that will be noted until
resolution. If we do not intend to release note something in any way, drivers
will set relnote-firefox:-.
Please make sure to only nominate those features and issues that are
significant. See https://www.mozilla.org/en-US/firefox/18.0.2/releasenotes/ for
an example of recent notes.
-Alex
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
TimeStamp::NowLoRes()
This new method provides much lower performance hit time interval where high precision timing is not needed. Implemented in bug 827287, landed on m-c today. On the Windows platform it gives resolution of aprox 16ms, using GetTickCount() which is by a magnitude cheaper to call then QueryPerformanceCounter() on most hardware. Use NowLoRes() method when the expected time duration you are about to work with should be more then aprox 150 milliseconds, mainly longer timeouts. I plan to migrate some places of our code to use it where appropriate. This may give some performance benefit on older or exotic machines running any version of Windows since XP to 8. -hb- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
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
Running mousemove events from the refresh driver
Context: bug 837985. At times we can be flooded by OS-level mousemove events. I think it would make sense to process mousemoves at most once per refresh driver tick. This matters for a couple of reasons: mousemove processing can cause arbitrary JS handlers to run which can do slow things, and also for performance reasons we currently don't flush layout before all mousemoves, but we really should (and we've been burned by bugs where we didn't). If we dispatch mousemoves in the refresh driver that should reduce the impact of having to flush, since the refresh driver flushes layout anyway. I think I'd do this by usurping the synthetic-mouse-move code to dispatch real mousemoves as well, so platform-level mousemove events do nothing but notify the presshell that a mousemove is needed and schedule a refresh driver tick. Can anyone see any problems with this? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Wed, Feb 13, 2013 at 4:45 PM, Rob Arnold tell...@gmail.com wrote: Would you want to predict the mouse location based on past events when you dispatch the synthetic event? I guess it depends on how frequently you get the events but this is done for touches on mobile where the input frequency is close (with 2x) the display frequency. If not, what would the timestamp on the event be? I hadn't thought about that. Is it really necessary? I think without prediction, we'd get the same visual results as we do today. With prediction we might make drags seem to track the mouse a bit better, although it sounds a bit scary to have the user mouse over something they actually didn't. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
Hey Asa, where does the magic 20 pages deep history number come from? Why not 1? Or 999? Andreas 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
Re: Running mousemove events from the refresh driver
On Tue, Feb 12, 2013 at 7:57 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Wed, Feb 13, 2013 at 4:45 PM, Rob Arnold tell...@gmail.com wrote: Would you want to predict the mouse location based on past events when you dispatch the synthetic event? I guess it depends on how frequently you get the events but this is done for touches on mobile where the input frequency is close (with 2x) the display frequency. If not, what would the timestamp on the event be? I hadn't thought about that. Is it really necessary? I think without prediction, we'd get the same visual results as we do today. With prediction we might make drags seem to track the mouse a bit better, although it sounds a bit scary to have the user mouse over something they actually didn't. I agree; it should be no worse than today. I do have some concerns with dispatching a mouse move event that contains coordinates the mouse may not have been at but the visual results for scrolling ought to be nice. Only other concern is if there are applications that make use of the higher frequency mouse events to do extra processing (ex: a finger painting app would want more samples for curve reconstruction). Otherwise I think it makes sense. -Rob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
L. David Baron wrote: On Tuesday 2013-02-12 18:40 -0800, Asa Dotzler wrote: doing something horribly wrong with memory. This is simply a memory-expensive feature and it's a feature we *must* land. Why is it simply a memory-expensive feature? Why does it require any additional memory overhead at all, other than while an animation is happening? -David Currently, when navigating back/forward in the browser history, we don't keep track of the rendered pages. So, without storing snapshots of pages in history, we only have the current page to animate. The previous/next pages would appear blank. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
There is some context to the magic number 20 in comment 305 in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=678392#c305 In summary, it seems to match what other browsers are doing and the memory consumption during experiments remained below 10mb. -Stephen Andreas Gal wrote: Hey Asa, where does the magic 20 pages deep history number come from? Why not 1? Or 999? Andreas 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
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
On Tuesday 2013-02-12 20:17 -0800, Stephen Pohl wrote: L. David Baron wrote: On Tuesday 2013-02-12 18:40 -0800, Asa Dotzler wrote: doing something horribly wrong with memory. This is simply a memory-expensive feature and it's a feature we *must* land. Why is it simply a memory-expensive feature? Why does it require any additional memory overhead at all, other than while an animation is happening? Currently, when navigating back/forward in the browser history, we don't keep track of the rendered pages. So, without storing snapshots of pages in history, we only have the current page to animate. The previous/next pages would appear blank. But we store the pages themselves in the bfcache, and it seems like we ought to be able to paint them into the needed image (or other lower-level graphical buffer) right before we do the animation. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Wed, Feb 13, 2013 at 5:14 PM, Rob Arnold tell...@gmail.com wrote: I agree; it should be no worse than today. I do have some concerns with dispatching a mouse move event that contains coordinates the mouse may not have been at but the visual results for scrolling ought to be nice. Only other concern is if there are applications that make use of the higher frequency mouse events to do extra processing (ex: a finger painting app would want more samples for curve reconstruction). Otherwise I think it makes sense. I did some tests with various browsers on Windows and we normally only get 60-ish mouse-moves per second max. So if we're keep our frame rate up, we should be OK. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
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
