Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

On Thu, May 26, 2016 at 7:49 PM, Tzu-Hao Kuo wrote: > *Link to standard*: No standard. This API was first discussed at Mozlando > and has been discussed online here( > https://github.com/w3c/mediacapture-worker/issues/33). The discussion has > been led to a stream-based design

Re: Intent to ship: Canvas CSS/SVG filters

Can you also get results on Windows? -Jeff On Wed, Jun 1, 2016 at 3:05 PM, Tobias Schneider wrote: > I got the following numbers running > https://dl.dropboxusercontent.com/u/55355076/benchmark.html?filters=true > on my MacBook Pro (Mid 2014): > > Firefox Developer

Re: Intent to ship: Canvas CSS/SVG filters

I'm surprised to see Skia (which I assume is also Chrome 53's canvas backend) lagging behind CoreGraphics and even Cairo here. Do we have a bug to track that down? This is the same code that powers our CSS filters, so a speedup there should help both canvas and content. --Jet On Wed, Jun 1, 2016

Re: How badly out of date is this?

On Wed, Jun 01, 2016 at 11:23:58AM -0400, Kartikaya Gupta wrote: On Wed, Jun 1, 2016 at 10:06 AM, Mike Hoye wrote: On 2016-06-01 5:02 AM, L. David Baron wrote: So I tend to think it's worth keeping, but with a preface that clearly labels it as historical and no longer good

Re: How badly out of date is this?

position:fixed can be a usability nightmare on mobile. Here be dragons. On Wed, Jun 1, 2016 at 11:23 AM, Kartikaya Gupta wrote: > Or make the warning a fixed-position item, so it's on-screen > regardless of where on the page you are. > > On Wed, Jun 1, 2016 at 10:06 AM, Mike

Re: Intent to ship: Canvas CSS/SVG filters

I got the following numbers running https://dl.dropboxusercontent.com/u/55355076/benchmark.html?filters=true on my MacBook Pro (Mid 2014): Firefox Developer Edition: Skia-GL: 10fps Skia: 3fps CG:

Re: Service Worker - Offline fallback not working

Just read the same that service workers are served over https and it might solve my problem :) Thanks for your help Regards Mohit On 1 June 2016 at 07:45, Andrew Sutherland wrote: > Stack Overflow or other programmer discussion Q sites are probably > better

Re: Service Worker - Offline fallback not working

Hello I added "offline.html" in filesToCache but still the same problem arises. When i refresh the page in absence of internet connection "offline.html" doesn't show up. Github project link - https://github.com/mbj36/My-Blog/commits/gh-pages Please help Thanks Mohit On 31 May 2016 at 23:45,

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Tue, May 31, 2016, at 09:26 PM, Jeff Gilbert wrote: > On Tue, May 31, 2016 at 4:39 PM, Nicholas Nethercote > wrote: > > On Wed, Jun 1, 2016 at 1:05 AM, Benjamin Smedberg > > wrote: > >> You shouldn't need to annotate the file/line separately,

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

Awesome, this sounds like what I was after. (though actual components isn't really necessary. If that part is a pain point, I would prefer to have a tool without it, than to have no tool) On Wed, Jun 1, 2016 at 12:23 PM, Ted Mielczarek wrote: > On Tue, May 31, 2016, at 09:26

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

It would be useful to have a dashboard that collates this information better. PS: Sarcasm is unhelpful. On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote wrote: > On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert wrote: >> >> Perhaps this isn't

Intent to remove: UTF-16 encoders from the XUL platform

UTF-16 encoders are not part of the Web Platform. Therefore, it doesn't make sense to implement them in a Web-oriented encoding library that has the Encoding Standard as its conformance target. As a result, I intend not to add UTF-16 encoders to encoding-rs

Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

This will be great for writing JavaScript code that applies filters or effects to video, too. Sweet. > *Summary*: HTMLMediaElement::seekToNextFrame() is an experimental feature > which enables JS developers to access video frames one-by-one without going > through the real-time playback.

Re: Dropping support for VS2013

Hi Greg and others, I was just about to raise the issue of performance regression from this change. If we are aiming this at the 49 release, I would like for us to improve the situation described in bug 1259923, a 15% performance regression across all Talos tests covering Windows platforms, which

Re: Intent to deprecate: MacOS 10.6-10.8 support

Perhaps we can exercise restraint on doing a wholesale removal of the <10.9 code, as doing so could make uplifting to 48 and earlier more of a mess. Maybe in a few weeks? — - Milan > On May 31, 2016, at 11:16 , Benjamin Smedberg wrote: > > Yes. > > --BDS > > On

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

Not sure what you mean - the stack information is there, right? This is my workflow: Search for all the MOZ_CRASHes (e.g., moz crash reason “exists” (sometimes I just search for the graphics reasons, but we don’t have the GFX prefix on all the crashes, so that doesn’t quite work all the time)

Re: How badly out of date is this?

Or make the warning a fixed-position item, so it's on-screen regardless of where on the page you are. On Wed, Jun 1, 2016 at 10:06 AM, Mike Hoye wrote: > On 2016-06-01 5:02 AM, L. David Baron wrote: >> >> >> So I tend to think it's worth keeping, but with a preface that >>

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

Cairo graphics reports “out of memory” error condition when the author didn’t have time to figure out what went wrong. We caught a few problems that were being reported as out of memory (we would pick up the Cairo library error as out of memory, and dutifully propagate it up the chain), when

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote wrote: > If you use your favourite source code search tool to look for > "Shutdown too long", you'll find that this crash is occurring in > toolkit/components/terminator/nsTerminator.cpp. For example, here's a > DXR

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Mon, May 30, 2016 at 11:22 PM, Nicholas Nethercote < n.netherc...@gmail.com> wrote: > 6 MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle > collector found more references to an object than its refcount)509 > 0.04 % > That's bug 1266882. 15 MOZ_RELEASE_ASSERT(aRefCount !=

Re: How badly out of date is this?

On 2016-06-01 5:02 AM, L. David Baron wrote: So I tend to think it's worth keeping, but with a preface that clearly labels it as historical and no longer good practice, and perhaps with an appendix pointing to the current practices. Hey, Sheppy - Should we make a practice of stripping anchor

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On 6/1/16 2:32 AM, Nicholas Nethercote wrote: 4 MOZ_CRASH(Unexpected error during FakeBlack creation.) 16790.13 % This is https://bugzilla.mozilla.org/show_bug.cgi?id=1247977 (credit to Milan for noticing that). 49 MOZ_CRASH(Accessing the Subject Principal without an AutoJSAPI on the

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On 1/6/16 00:51, Nicholas Nethercote wrote: On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew wrote: I took a quick look at a random one of these OOMs[1], and what strikes me about it is that according to the crash report: Total Virtual Memory2147352576

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On 2016-06-01 2:32 AM, Nicholas Nethercote wrote: 37 MOZ_RELEASE_ASSERT(aInAndOutListener) (can not perform CORS checks without a listener) 23 0.00 % bug 1276943 ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

Here's an update. This one is bug 1235183: > 7 MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 % This one is covered by bug 616421 (the signature includes a combination of MOZ_CRASHes and other kinds of crashes): > 8 MOZ_CRASH(Bogus tree op)459 0.04 % Below are all