Re: Off-main-thread Painting
On 12 February 2013 21:57:53, Clint Talbert wrote: 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 It's probably worth noting that this instrumentation already exists for Android, in the form of talos pan and checkerboard tests. It would be good to have something for other platforms if it doesn't already exist though. --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 12/02/13 21:20, Benoit Jacob wrote: 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. I definitely think it's time that we had a discussion within Mozilla as to what we should do about this. It's not trivially obvious what the right thing for the web is. The internet is going to be used as a delivery mechanism for commercial high-cost-of-production video. That's undeniable. There are three ways this could play out (pun intended): A) Provide a DRM mechanism in HTML5 which keeps them happy. (How breakable or not it actually is, is a different question.) Have the video delivered that way. B) Have all the commercial video content be only available via Flash, proprietary plugins or proprietary mobile apps, thereby saying there are some things the open web just can't provide for you - you need to go closed for that. C) Hope the economic analysis is wrong and that if we kill the idea of DRM in HTML5, this content will appear un-DRMed in HTML5 form anyway because it's just easier for them and the ease outweighs the lack of DRM. My concern is that if we go for C), we'll get B), and B) might be worse than A). Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: HTML Working Group
For starters, see http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0178.html . On Wed, Feb 13, 2013 at 1:30 PM, Gervase Markham g...@mozilla.org wrote: A) Provide a DRM mechanism in HTML5 which keeps them happy. (How breakable or not it actually is, is a different question.) Have the video delivered that way. EME assumes multiple Key Systems, so EME isn't a fully contained one mechanism. It's a common part of several intentionally mutually incompatible mechanisms. (Incompatible on the key initialization level that is. They'll be intentionally compatible on the level of the large files that end up on content delivery networks.) B) Have all the commercial video content be only available via Flash, proprietary plugins or proprietary mobile apps, thereby saying there are some things the open web just can't provide for you - you need to go closed for that. I don't think we have this option. Microsoft and Google have editors on the EME spec. So this option looks more like: Have Hollywood movies available with good performance and without additional installs in IE and Chrome and *for the time being* available via Silverlight in Firefox on Windows and Mac (i.e. with additional installations, updates and performance and stability troubles and only as long as Microsoft bothers to keep Silverlight working and available). C) Hope the economic analysis is wrong and that if we kill the idea of DRM in HTML5, this content will appear un-DRMed in HTML5 form anyway because it's just easier for them and the ease outweighs the lack of DRM. My concern is that if we go for C), we'll get B), and B) might be worse than A). Indeed. And as noted above, B is likely to be worse than how you phrased it. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ ___ 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 2/12/2013 10:18 PM, Robert O'Callahan wrote: Context: bug 837985. At times we can be flooded by OS-level mousemove events. On what OSes? Windows by default coalesces mouse move events. They are like WM_PAINT events in that they are only delivered when the event queue is empty. See http://blogs.msdn.com/b/oldnewthing/archive/2011/12/19/10249000.aspx This should basically mean that we process mousemove events on windows up to 100% CPU, but we should never be flooded by them. Although I do wonder if WM_MOUSEMOVE has priority over WM_PAINT so that if the mouse is moving a lot, that could affect the latency of WM_PAINT. If other OSes don't do this, I definitely think we should consider emulating this behavior somehow; I don't know if it's possible to know on other widget layers whether the event queue is empty. --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 13/02/13 12:55, Henri Sivonen wrote: I don't think we have this option. Microsoft and Google have editors on the EME spec. So this option looks more like: Have Hollywood movies available with good performance and without additional installs in IE and Chrome and *for the time being* available via Silverlight in Firefox on Windows and Mac ...and not on Linux at all... (i.e. with additional installations, updates and performance and stability troubles and only as long as Microsoft bothers to keep Silverlight working and available). I'm not enamoured of the idea of the answer to how do I watch Netflix/LoveFilm in Firefox? being head over to Microsoft and install Silverlight; bad luck if you run anything other than Windows or Mac OS X. (AFAICT, that is the answer at the moment anyway, but at least it's the same for all browsers. LoveFilm phased out Flash a while back - I was an upset customer. I assume Netflix did the same.) Gerv ___ 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
This is kind of OT, but OTOH, if the computer has memory available, we should be using *all* of it any place we can trade memory for speed. We considered this idea in MemShrink some months ago, and we mostly dropped it. There are two essential problems that we weren't able to overcome. 1) It's not always simple to determine how much memory the system has available. This is particularly true on Mac, as it turns out; bug 789975 says we can't even accurately measure our own memory usage on Mac. The issue is that the OS keeps some types of free'd pages in a process's address space and only releases them when the system is very low on memory, but it doesn't give us any way (that I'm aware of) to measure how many of these pages there are. 2) More importantly, using as much RAM is available but no more makes Firefox the nicest process on the system. We can get into a situation where, because some other program is hogging memory, the user's swipe animations stop working as she expects. That may look like a bug in Firefox, and in any case it may not be what the user wants. Doing this makes Firefox change its behavior based upon what other processes on the system are doing, and I'm not convinced that's a safe thing to do in general. But this is a better discussion to have in the context of DDD than in the context of this bug. -Justin On Wed, Feb 13, 2013 at 9:13 AM, Benjamin Smedberg benja...@smedbergs.us wrote: On 2/13/2013 3:12 AM, Justin Lebar wrote: c) Consider adaptive techniques so that users who use this feature heavily will store more screenshots (at the cost of more memory), while those who don't use it won't pay a price. Apart from the other solution of re-rendering directly from bfcache, this seems like the obvious longer-term solution, and it ties in with Josh's proposal about ddd. I don't think there's any way to make absolute judgements about whether 2.5MB or 5MB or 10MB is reasonable for a feature, and there's a lot of room for adaptive data-driven behavior here. If the computer is memory-constrained, then we should be evicting all sorts of memory-based caches pretty aggressively, and this is one of them. OTOH, if the computer has memory available, we should be using *all* of it any place we can trade memory for speed. Other possible technical tradeoffs that might be possible: * render from bfcache if its present * when we evict from bfcache, take a high-res snapshot * when things go back far enough, compress or resample the image to a low-res snapshot. Is there a video/demo/feature page which explains what this feature actually is? I've seen status updates about a new cool swipe thing, but I don't actually know what problem its solving. Is this feature mac-only, or is it starting out on mac and we'll be porting it back to other platforms? Or is it touchscreen-only? --BDS ___ 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: Proposed W3C Charter: HTML Working Group
Gervase Markham wrote: I'm not enamoured of the idea of the answer to how do I watch Netflix/LoveFilm in Firefox? being head over to Microsoft and install Silverlight; bad luck if you run anything other than Windows or Mac OS X. (AFAICT, that is the answer at the moment anyway, but at least it's the same for all browsers. LoveFilm phased out Flash a while back - I was an upset customer. I assume Netflix did the same.) Not forgetting that Adobe phased out Flash for Linux a while back too anyway. -- Warning: May contain traces of nuts. ___ 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 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. Or better still, paint the *current* page into a temporary image, start the browser loading, then animate the image away appropriately. (If the bfcache applies, the new page will load very quickly, particularly if the user is distracted by the animation.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cycle collection for workers
Kyle Huey wrote: 1. Dealing with the different ownership model on worker threads (no cycle collector, all owning references go through JS). 2. Dealing with things that are not available off the main thread (no necko, no gfx APIs, etc). FWIW, I think the networking team has a goal of allowing nsHttpChannel to be used off of the main thread, for performance reasons. Not sure on the timeline for that though. - *Does this mean cycle collected objects can be multithreaded?* No-ish. All cycle collected objects will belong to one and only one thread, and can only be AddRefed/Released on that thread. At what point during XPCOM shutdown are workers destroyed? This seems like a great tool for implementing the worker part of the W3C WebCrypto API. But, we have to deal with the fact that during XPCOM shutdown, we have to ensure all the crypto objects are destroyed, and that has to happen on the main thread. (We're notified about shutdown on the main thread and we have to finish destroying all the objects before we return from the notification.) So, it seems like we may need some kind of Destroy all the workers API that deals with this, if we don't have it already. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming separation between resource://app and resource://gre
I've completed all the testing that I can think of to alert of us any concerns and found no regressions in the latest Nightly builds. See my comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=827354#c26 Please advise if anything more is needed. Anthony Hughes QA Engineer, Desktop Firefox Mozilla Corporation - Original Message - From: Anthony Hughes ahug...@mozilla.com To: Dave Townsend dtowns...@mozilla.com Cc: dev-platform@lists.mozilla.org Sent: Friday, February 8, 2013 9:28:33 AM Subject: Re: Upcoming separation between resource://app and resource://gre If we could identify some of the more popular add-ons that meet this criteria I can add it to my test plan. I'll be testing this in Nightly on Tuesday. Anthony Hughes QA Engineer, Desktop Firefox Mozilla Corporation - Original Message - From: Dave Townsend dtowns...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Friday, February 8, 2013 9:17:04 AM Subject: Re: Upcoming separation between resource://app and resource://gre On 2/8/2013 7:11 AM, Matt Brubeck wrote: On 2/7/2013 6:12 AM, Mike Hommey wrote: - But really, what does it change for developers? Almost nothing they shouldn't be doing already. The main difference is that resource://app/ and resource://gre/ urls are not going to point to the same location anymore, which means I won't have to file bugs about $randomFile including resource://gre/modules/something.jsm instead of resource://app/modules/something.jsm. This seems like a major add-on compatibility issue. Has anyone looked into how many add-ons will now have incorrect resource: URIs? How can we scan for these, and how can we mitigate the breakage? Any add-ons that get broken by thins would have already been broken when used on most linux distributions. That said we could search the add-ons mxr for instances of common gre modules in use without the prefix. ___ 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: Cycle collection for workers
Kyle Huey wrote: Brian Smith bsm...@mozilla.com wrote: At what point during XPCOM shutdown are workers destroyed? xpcom-shutdown-threads NSS gets shut down way before then, because it can write to the profile. Same with Necko. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cycle collection for workers
On Wed, Feb 13, 2013 at 9:20 PM, Benjamin Smedberg benja...@smedbergs.uswrote: On 2/13/2013 1:39 PM, Kyle Huey wrote: On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith bsm...@mozilla.com wrote: At what point during XPCOM shutdown are workers destroyed? xpcom-shutdown-threads What workers are these? Do workers outlast the page that loaded them? The entire DOM should be torn down at or before we shut down the profile. There's really no way workers should outlive that point either. Web workers for a given window begin to shut down when nsGlobalWindow::FreeInnerObjects is called. When exiting that's going to get called from nsDocShell::Destroy, presumably when the tabbrowser is torn down. Since workers are on another thread the shutdown process is asynchronous. Nothing guarantees that they are shutdown before proceeding further until we block on them being shutdown during xpcom-shutdown-threads. - Kyle ___ 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 Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg benja...@smedbergs.uswrote: On what OSes? Windows by default coalesces mouse move events. They are like WM_PAINT events in that they are only delivered when the event queue is empty. See http://blogs.msdn.com/b/oldnewthing/archive/2011/12/19/10249000.aspx This should basically mean that we process mousemove events on windows up to 100% CPU, but we should never be flooded by them. Although I do wonder if WM_MOUSEMOVE has priority over WM_PAINT so that if the mouse is moving a lot, that could affect the latency of WM_PAINT. We are definitely getting flooded. Here's what I think is happening on the page I'm looking at, it's pretty simple: 1) nsAppShell::ProcessNextNativeEvent checks for input events, finds a WM_MOUSE_MOVE, and dispatches it, which takes a little while because this page's mousemove handler modifies and flushes layout on every mouse move. 2) While that's happening, the mouse keeps moving. 3) After processing that WM_MOUSE_MOVE, ProcessNextNativeEvent calls PeekMessage again and finds another WM_MOUSE_MOVE is ready. Go to step 1. 4) Meanwhile the refresh driver timer has fired and queued an event, but we don't get around to running it until NATIVE_EVENT_STARVATION_LIMIT has expired (one second). I suppose we could try ignoring WM_MOUSE_MOVEs when there's a Gecko event pending, but that sounds kinda scary. I think deferring DOM mousemove events to the next refresh driver tick would be safer than that. 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
Flash plugin in xulrunner
How can I distribute my xulrunner app with flash plugin? I don't want to rely on user having flash installed, instead my app that makes use of xulrunner should have the flash plugin. I tried to create a plugins directory under xulrunner and to put there the NPSWF32.dll but it doesn't detect it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
