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

Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations

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 fa

Re: Running mousemove events from the refresh driver

On Wed, Feb 13, 2013 at 5:14 PM, Rob Arnold 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 i

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-expen

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

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 a

Re: Running mousemove events from the refresh driver

On Tue, Feb 12, 2013 at 7:57 PM, Robert O'Callahan wrote: > On Wed, Feb 13, 2013 at 4:45 PM, Rob Arnold 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 do

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 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 proce

Re: Running mousemove events from the refresh driver

On Wed, Feb 13, 2013 at 4:45 PM, Rob Arnold 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 (wi

Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations

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 whi

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

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-rec

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 QueryPerfor

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

Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations

We use .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

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 fr

Re: Off-main-thread Painting

On Wed, Feb 13, 2013 at 12:28 PM, Matt Woodrow 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.

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 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 _

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

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 no

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

Re: Off-main-thread Painting

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. We could retain the display list on the painting thread (until

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 > 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 transfer

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 undoubted

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 utilizati

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

Re: Proposed W3C Charter: HTML Working Group

2013/2/12 Robert O'Callahan > On Wed, Feb 13, 2013 at 5:02 AM, Benjamin Smedberg >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

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 packa

Re: Proposed W3C Charter: HTML Working Group

On Wed, Feb 13, 2013 at 5:02 AM, Benjamin Smedberg 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 wi

Re: Off-main-thread Painting

On Wed, Feb 13, 2013 at 9:43 AM, Robert O'Callahan wrote: > 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

Re: Off-main-thread Painting

On Wed, Feb 13, 2013 at 9:20 AM, Anthony Jones 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 t

Re: Off-main-thread Painting

On Wed, Feb 13, 2013 at 6:17 AM, Jet Villegas 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

Re: Off-main-thread Painting

On Wed, Feb 13, 2013 at 5:50 AM, Andreas Gal wrote: > 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

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 abstr

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 >

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

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 us

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 neede

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 wrote: > I'm not too con

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

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" To: "Chris Lord" Cc: dev-platform@lists.mozilla.or

Re: Off-main-thread Painting

On Feb 12, 2013, at 9:50 AM, Milan Sreckovic 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

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

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 sti

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 objection

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 synchroniza

Re: Off-main-thread Painting

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. - Br

Re: Off-main-thread Painting

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 com