Finding out if the main thread is currently animating

[David Rajchenbach-Teller]

To improve the Performance Stats API, I'm looking for a way to find out
if we are currently animating something on the main thread.

My definition of animating is pretty large, i.e. "will the user probably
notice if some computation on the main thread lasts more than 32ms".

Do we have a reliable way to do that?

-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding out if the main thread is currently animating

[David Rajchenbach-Teller]

The main thread of the current chrome/content process.

Indeed, animations are one of my two use cases, the other one being
user-input latency, but I'm almost sure I know how to deal with the latter.

Cheers,
 David


On 29/10/15 14:32, Benjamin Smedberg wrote:
> On the main thread of which process?
> 
> Please consider non-"animation" use-cases. In particular, users do
> notice the latency of typing into edit boxes as much as anything else.
> So let's make sure that editing latency triggers this as much as a
> current animation.
> 
> --BDS


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merge moved to Thursday 29th

[Masatoshi Kimura]

I missed two commits for 44 branch.
https://treeherder.mozilla.org/#/jobs?repo=fx-team=6b3c99e54177
Uplift requests will not help because they are string changes.

On 2015/10/29 5:10, Sylvestre Ledru wrote:
> Hello,
> 
> Because we want to synchronize the release of 42 and 44 devedition (next
> Tuesday),
> we are planning to perform the merge tomorrow, Thursday.
> As a consequence, nightly = 45, aurora = 44 and beta = 43 (42 is already
> in release).
> This will give us enough time to validate the first aurora build.
> 
> I apologize for the very late notice. Of course, we will be friendly
> with uplift requests.
> 
> Sylvestre
> 
> 
> ___
> 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: Merge moved to Thursday 29th

[Sylvestre Ledru]

Please request the uplift. Under specific circumstances (like this one), we 
take string changes in aurora.

Thanks
Sylvestre

Le 29/10/2015 13:39, Masatoshi Kimura a écrit :
> I missed two commits for 44 branch.
> https://treeherder.mozilla.org/#/jobs?repo=fx-team=6b3c99e54177
> Uplift requests will not help because they are string changes.
>
> On 2015/10/29 5:10, Sylvestre Ledru wrote:
>> Hello,
>>
>> Because we want to synchronize the release of 42 and 44 devedition (next
>> Tuesday),
>> we are planning to perform the merge tomorrow, Thursday.
>> As a consequence, nightly = 45, aurora = 44 and beta = 43 (42 is already
>> in release).
>> This will give us enough time to validate the first aurora build.
>>
>> I apologize for the very late notice. Of course, we will be friendly
>> with uplift requests.
>>
>> Sylvestre
>>
>>
>> ___
>> 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: Finding out if the main thread is currently animating

[Benjamin Smedberg]

On the main thread of which process?

Please consider non-"animation" use-cases. In particular, users do 
notice the latency of typing into edit boxes as much as anything else. 
So let's make sure that editing latency triggers this as much as a 
current animation.


--BDS

On 10/29/2015 9:14 AM, David Rajchenbach-Teller wrote:

To improve the Performance Stats API, I'm looking for a way to find out
if we are currently animating something on the main thread.

My definition of animating is pretty large, i.e. "will the user probably
notice if some computation on the main thread lasts more than 32ms".

Do we have a reliable way to do that?



___
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: Merge moved to Thursday 29th

[Axel Hecht]

I'm also commented in the bug:

If we're doing uplifts, I'm not sure we're winning by uplifting 
pre-landed strings.


Either way, I think the risk assessment of the patch should be that of 
the actual patch that uses the strings, not "just adding strings".


Also, I'd appreciate an ETA for the patch, as that's also going in to 
the risk that a patch comes with.


Axel

On 10/29/15 1:41 PM, Sylvestre Ledru wrote:

Please request the uplift. Under specific circumstances (like this one), we 
take string changes in aurora.

Thanks
Sylvestre

Le 29/10/2015 13:39, Masatoshi Kimura a écrit :

I missed two commits for 44 branch.
https://treeherder.mozilla.org/#/jobs?repo=fx-team=6b3c99e54177
Uplift requests will not help because they are string changes.

On 2015/10/29 5:10, Sylvestre Ledru wrote:

Hello,

Because we want to synchronize the release of 42 and 44 devedition (next
Tuesday),
we are planning to perform the merge tomorrow, Thursday.
As a consequence, nightly = 45, aurora = 44 and beta = 43 (42 is already
in release).
This will give us enough time to validate the first aurora build.

I apologize for the very late notice. Of course, we will be friendly
with uplift requests.

Sylvestre


___
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: Finding out if the main thread is currently animating

[David Rajchenbach-Teller]

On 29/10/15 16:32, Benoit Girard wrote:
> We've explored several different ways of measuring this. Several of
> these are in the tree. Generally what I have found the most useful is to
> measure how we're servicing the content' main thread. This measurement
> is great because its measures how responsive Firefox is not only for
> scrolling/animations but nearly all use cases like typing latency.
> 
> There's EventTracer.h which is our best general responsiveness
> measurement at the moment. However it only traces the event loop up to
> each 20ms so it's a laggy indicator.

Thanks. However, I'm not really looking for a detector, only a flag that
will let me prune false positives.

The Performance Stats API already detects [a subset of] lag, and the
Addon Watcher informs the user when this lag is attributed to an add-on.
Experience shows, however, that it regularly informs the user of
invisible lag. In particular, Jetpack causes a CPOW when we're focusing
Firefox, even if this has no impact on the user, AdBlock slows down some
parts of loading, even if it generally makes loading faster on the
whole, etc. While the event loop is not serviced as well as usual, from
the point of view of the user, these are false positives.

Hence my quest for a way to determine whether the main thread is
currently in a jank-critical section (user-interaction or animation).

Note that there are secondary applications to this, e.g. bug 1178972.

Cheers,
 David

-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding out if the main thread is currently animating

[Benoit Girard]

We've explored several different ways of measuring this. Several of these
are in the tree. Generally what I have found the most useful is to measure
how we're servicing the content' main thread. This measurement is great
because its measures how responsive Firefox is not only for
scrolling/animations but nearly all use cases like typing latency.

There's EventTracer.h which is our best general responsiveness measurement
at the moment. However it only traces the event loop up to each 20ms so
it's a laggy indicator.

On Thu, Oct 29, 2015 at 9:47 AM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:

> The main thread of the current chrome/content process.
>
> Indeed, animations are one of my two use cases, the other one being
> user-input latency, but I'm almost sure I know how to deal with the latter.
>
> Cheers,
>  David
>
>
> On 29/10/15 14:32, Benjamin Smedberg wrote:
> > On the main thread of which process?
> >
> > Please consider non-"animation" use-cases. In particular, users do
> > notice the latency of typing into edit boxes as much as anything else.
> > So let's make sure that editing latency triggers this as much as a
> > current animation.
> >
> > --BDS
>
>
> --
> David Rajchenbach-Teller, PhD
>  Performance Team, Mozilla
>
>
> ___
> 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: Intent to ship: WebVR

[vladimir]

On Monday, October 26, 2015 at 9:39:57 PM UTC-4, Ehsan Akhgari wrote:
> First things first, congratulations on getting this close!
> 
> What's the status of the specification?  I just had a quick skim and it 
> seems extremely light on details.

The spec is still a draft, and the API is expected to change significantly 
(specifically the fullscreen window integration is going to change).  The 
intent to ship here is a bit premature; the intent is to pref it on in nightly 
& aurora, not ship it all the way to release.

> There is quite a bit of details missing.  The security model is 
> essentially blank, and the descriptions in section 4 seem to be 
> high-level overviews of what the DOM interfaces do, rather that detailed 
> descriptions that can be used in order to implement the specification.

Yep.

> Also some things that I was expecting to see in the API seem to be 
> missing.  For example, what should happen if the VR device is 
> disconnected as the application is running?  It seems like right now the 
> application can't even tell that happened.

Also something that's coming in an upcoming revision of the API.

> Another question: do you know if Chrome is planning to ship this feature 
> at some point?  Has there been interoperability tests?

They are currently in the same boat as us, shipping it in dev or one-off 
builds.  We're working with them on the specification, and we're generally 
interoperable currently.

- Vlad

> On 2015-10-26 3:19 PM, Kearwood "Kip" Gilbert wrote:
> > As of Oct 29, 2015 I intend to turn WebVR on by default for all
> > platforms. It has been developed behind the dom.vr.enabled preference.
> > A compatible API has been implemented (but not yet shipped) in Chromium
> > and Blink.
> >
> > Bug to turn on by default:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1218482
> >
> > Link to standard: https://mozvr.github.io/webvr-spec/webvr.html
> >
> >
> > ___
> > 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: Intent to ship: WebVR

[vladimir]

On Wednesday, October 28, 2015 at 11:38:26 AM UTC-4, Gervase Markham wrote:
> On 26/10/15 19:19, Kearwood "Kip" Gilbert wrote:
> > As of Oct 29, 2015 I intend to turn WebVR on by default for all
> > platforms. It has been developed behind the dom.vr.enabled preference. 
> > A compatible API has been implemented (but not yet shipped) in Chromium
> > and Blink.
> 
> At one point, integrating with available hardware required us to use
> proprietary code. Is shipping proprietary code in Firefox any part of
> this plan, or not?

No.

 - Vlad
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR

[Ehsan Akhgari]

On 2015-10-29 1:10 PM, vladi...@mozilla.com wrote:

On Monday, October 26, 2015 at 9:39:57 PM UTC-4, Ehsan Akhgari wrote:

First things first, congratulations on getting this close!

What's the status of the specification?  I just had a quick skim and it
seems extremely light on details.


The spec is still a draft, and the API is expected to change significantly 
(specifically the fullscreen window integration is going to change).  The intent to 
ship here is a bit premature; the intent is to pref it on in nightly & aurora, 
not ship it all the way to release.


Oh OK, turning this on on non-release builds sounds good to me.  It 
doesn't really require an intent email...


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Partial updates temporarily disabled for Nightly and Dev-Edition

[Chris AtLee]

We've temporarily disabled generation of partial updates for Nightly and
Dev-Edition (Aurora) versions of Firefox.

Given that Dev-Edition updates are currently frozen as part of our uplift
process, the main impact of this is on Nightly users.

We hope to have partial update generation re-enabled in the next few days.

Sorry for the inconvenience.

Chris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Collecting web platform features implementation status

[Tom Schuster]

Seems like this kind of died. I still would like to see this happening. Is
this on somebody's agenda?

On Tue, Jul 21, 2015 at 8:40 PM, Tom Schuster  wrote:

> I see 3 (now 4) old pull requests that are unmerged.
>
> On Tue, Jul 21, 2015 at 8:19 PM, Anthony Ricaud  wrote:
>
>> On 16/07/15 21:26, Anthony Ricaud wrote:
>>
>>> Potch and I are working on a website to present Mozilla's point of view
>>> on various web platform features. Other browsers have similar websites
>>> [1] [2] [3]. This project has been in lingo for a while so, to get it
>>> out the door, we're going to focus on one information: what is Mozilla's
>>> opinion on features that have not been shipped yet. We see 4 possible
>>> answers: in development, favorable, not favorable, no opinion.
>>>
>>> In order to get accurate data and update it regularly, we need your
>>> help. Please go to the following etherpad and insert any information
>>> that can help us:
>>> https://etherpad.mozilla.org/gecko-web-platform-dashboard
>>>
>>> Thanks for your help!
>>>
>>> [1] https://www.chromestatus.com/features
>>> [2] https://status.modern.ie
>>> [3] http://www.webkit.org/status.html
>>>
>> Reminder: We need your help! Please submit a pull request against
>> https://github.com/Rik/platform-status/blob/master/features.json.
>>
>> (I've only received one pull request since moving this JSON to Github :( )
>>
>> ___
>> 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: Intent to ship: WebVR

[Boris Zbarsky]

On 10/29/15 1:10 PM, vladi...@mozilla.com wrote:

The intent to ship here is a bit premature; the intent is to pref it on in nightly 
& aurora, not ship it all the way to release.


OK.  The patches in the "enable it" bugs are enabling on all branches; 
we should probably scale that back to just !RELEASE_BUILD, sounds like.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Date, time, week, month and datetime attributes in the in Firefox

[Robert Kaiser]

Carlos Valim Coragem  schrieb:

  I asked this same question on channel #mozilla-br on IRC, a mozillian
gave me this link: https://bugzilla.mozilla.org/show_bug.cgi?id=1069609 -
the bug was opened on 09-18-2014, the last comment was day 07-24-2015,
wondering if there was any progress on that.


https://bugzilla.mozilla.org/show_bug.cgi?id=825294 is actually the bug 
for this. Fun thing is that IIRC this is in HTML5 because of Mozilla's 
"Web Forms 2.0" specification proposed earlier - and we never 
implemented it so far...


KaiRo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding out if the main thread is currently animating

[Brian Birtles]

On 2015/10/30 0:57, David Rajchenbach-Teller wrote:

On 29/10/15 16:32, Benoit Girard wrote:

We've explored several different ways of measuring this. Several of
these are in the tree. Generally what I have found the most useful is to
measure how we're servicing the content' main thread. This measurement
is great because its measures how responsive Firefox is not only for
scrolling/animations but nearly all use cases like typing latency.

There's EventTracer.h which is our best general responsiveness
measurement at the moment. However it only traces the event loop up to
each 20ms so it's a laggy indicator.


Thanks. However, I'm not really looking for a detector, only a flag that
will let me prune false positives.


For CSS animations/transitions (not including SVG SMIL animations), you 
could use:


  document.timeline.getAnimations().some(
anim => anim.playState == 'running')

(Soon to become just document.getAnimations())

We could likewise just check if the DocumentTimeline is observing the 
refresh driver since we should stop doing that when CSS 
animations/transitions are at rest.


For rAF animations we could use the the js::NotifyAnimationActivity 
information? Or else look for registered frame request callbacks?


I think we could probably detect SVG SMIL animations too, if needed 
(perhaps by exposing the mRegisteredWithRefreshDriver member of 
nsSMILAnimationController although that might be too broad).

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Date, time, week, month and datetime attributes in the in Firefox

[Carlos Valim Coragem]

Hi my friends!

 I'm not sure where I can ask this question, so I'm sorry in advance :P

 I'm having trouble using the attributes in the : date, time, week,
month and datetime - in Firefox.

 During a class in college, last Tuesday, the teacher taught HTML elements
when several students, including myself, could not test these attributes
in Firefox D:

 From what we have seen in the specifications of the W3C[1], these
attributes are in HTML5, as I know that Firefox really understand this
version of HTML, I was surprised that these attributes did not work or
they have not been implemented. Is there any particular reason not to
work?

 I asked this same question on channel #mozilla-br on IRC, a mozillian
gave me this link: https://bugzilla.mozilla.org/show_bug.cgi?id=1069609 -
the bug was opened on 09-18-2014, the last comment was day 07-24-2015,
wondering if there was any progress on that.

 It seems that this problem only happens in the desktop version and not in
mobile, I just did a test with the same webpage in version 34.0.1 of
Firefox to Android and it worked!

 Here on my desktop I'm using the version 38.2.1 of Iceweasel in Debian
GNU/Linux. College students were using Windows 7 and Firefox 38.

 In Chrome, Opera and even IE it worked, only in our beloved red panda
browser we had this problem.

 Does anyone have any knowledge about this case?

[1] http://www.w3.org/TR/html-markup/input.html

Keep on rockin'!

Coragem

-- 
Carlos A C Valim [@_Coragem]
www.coragem.info
Eu sou um membro da FSF - Ajude-nos a apoiar o software livre!
http://my.fsf.org/register_form?referrer=9618
LPIC-1 #LPI ID LPI000205754
http://lpi.org

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Making tests e10s compatible

[Patrick Brosset]

Thanks for this Blake.
Somewhat related: for those of you using ESLint, I recently filed a bug to
create a new custom ESLint rule that should help automatically detect CPOW
usage in tests: https://bugzilla.mozilla.org/show_bug.cgi?id=1218412

On Thu, Oct 29, 2015 at 12:44 AM, Blake Kaplan  wrote:

> Hello everybody,
>
> You might have heard that we're working on getting our testing situation
> in line for e10s. To help people get started, I'm compiling a list of tips
> that are useful to know when working on e10s tests (and e10s in general).
> You can find it at .
>
> There isn't a catch-all solution to use to fix these tests, but there are
> a few things to look out for. The key is to find places in tests where
> objects from both chrome (like browser DOM nodes or chrome windows, etc.)
> and content (docshells, content windows, etc.) are needed and to use
> SpecialPowers or ContentTask to remote that bit to the other process.
>
> If a test is disabled because of a bug in e10s, please ensure that a bug
> is on file and the e10s team has triaged it.
>
> I'm happy to answer questions as needed.
> --
> Blake
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merge moved to Thursday 29th

[Sylvestre Ledru]

Le 29/10/2015 02:11, Ehsan Akhgari a écrit :
> On 2015-10-28 4:10 PM, Sylvestre Ledru wrote:
>> Hello,
>>
>> Because we want to synchronize the release of 42 and 44 devedition (next
>> Tuesday),
>> we are planning to perform the merge tomorrow, Thursday.
>> As a consequence, nightly = 45, aurora = 44 and beta = 43 (42 is already
>> in release).
>> This will give us enough time to validate the first aurora build.
>
> We've been working very hard to prepare Service Workers to be released in 44. 
>  We're down to a few remaining bugs, and since we were hoping to get testing 
> on Aurora on this feature (hopefully with web developers experimenting with 
> it!)  I have a couple of questions that would help us figure out
> how this changes our plans (probably not in a great way!).
>
> It would be very helpful if we can get our last changes onto Aurora after 
> this uplift.  What's the approval process involved?  Is it the same as the 
> normal process?
Yes. We are going to fast track the approvals.
>
> Also I think this essentially means that we would have no chance to get our 
> changes into the first Aurora build.  So we would need to rely on the 
> updates.  Are Aurora updates made nightly these days or are there small 
> "releases" on the Aurora branch?
Aurora/Devedition builds are nightly builds.
If you can get your changes into aurora Thursday or Friday, we can retrigger a 
build to make sure your changes are in the Tuesday release.

Hope this helps,
Sylvestre

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Date, time, week, month and datetime attributes in the in Firefox

[Xidorn Quan]

On Fri, Oct 30, 2015 at 10:25 AM, Ehsan Akhgari  wrote:
> On 2015-10-29 7:21 PM, Carlos Valim Coragem  wrote:
>>
>>   It seems that this problem only happens in the desktop version and not
>> in
>> mobile, I just did a test with the same webpage in version 34.0.1 of
>> Firefox to Android and it worked!
>
>
> Your experience is expected.  We have an implementation of these form
> controls on Android, but not on desktop.  We have been waiting for UX specs
> for this feature on desktop, as you have discovered.  :-)

We really should push UX people to have that done. It is a pain that
those things are not usable. Having those input types will save plenty
of time for frontend developers to make their apps support Firefox.
(Otherwise, they might just drop the Firefox support.)

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Date, time, week, month and datetime attributes in the in Firefox

[Ehsan Akhgari]

On 2015-10-29 7:21 PM, Carlos Valim Coragem  wrote:

  It seems that this problem only happens in the desktop version and not in
mobile, I just did a test with the same webpage in version 34.0.1 of
Firefox to Android and it worked!


Your experience is expected.  We have an implementation of these form 
controls on Android, but not on desktop.  We have been waiting for UX 
specs for this feature on desktop, as you have discovered.  :-)


Also, one note about HTML5, HTML5 is the name of a modern specification 
 that web browsers including 
Firefox implement.  Don't think of this as a version 5, it is a "living 
standard", which means that we add things to it and fix the bugs in it 
over time.  Each browser engine usually lacks implementation of a few 
features, as there is always a gap between the standardization and 
implementation of feature.  Sometimes by years!


To find out what engine supports which part of the Web platform, you can 
use tools such as .


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding out if the main thread is currently animating

[Karl Tomlinson]

David Rajchenbach-Teller writes:

> To improve the Performance Stats API, I'm looking for a way to find out
> if we are currently animating something on the main thread.
>
> My definition of animating is pretty large, i.e. "will the user probably
> notice if some computation on the main thread lasts more than 32ms".
>
> Do we have a reliable way to do that?

I would guess that our main thread animations all run off a single
60 Hz throttle, which I assume is the RefreshDriver.  If that
throttle has no jobs scheduled to run, then I expect there are no
animations in progress.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding out if the main thread is currently animating

[Ehsan Akhgari]

On 2015-10-29 9:47 AM, David Rajchenbach-Teller wrote:

The main thread of the current chrome/content process.

Indeed, animations are one of my two use cases, the other one being
user-input latency, but I'm almost sure I know how to deal with the latter.


Out of curiosity, how are you planning to measure input latency?  Based 
on event timestamps?


The reason I'm asking is that with e10s, I sometimes see long (even 
multi-second!) delays between for example clicking the new tab button, 
or for the title of a new tab to appear after the tab being initially 
painted) that are very visible to the user, and can't be detected that 
way.  I think it would be nice to come up with a set of user actions in 
the primary UI and manually measure their delay based on the knowledge 
that we have about the asynchronous nature of their implementation.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform