This sounds like a good idea. I'll see if I can get some time budgeted
to help with this during Q1.
Cheers,
David
On 30/10/15 15:09, Honza Bambas wrote:
> This is exactly what I want Backtrack for
> (http://www.janbambas.cz/new-gecko-performance-tool-backtrack/). That
> tool will allow you to d
On 10/30/2015 2:35, Ehsan Akhgari wrote:
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.
I have posted an early patch on bug 1219145 that approximates
"animating" to "is anyone listening for vsync". If anybody knowledgeable
could take a look, I'd be grateful.
Cheers,
David
On 30/10/15 02:33, Karl Tomlinson wrote:
> David Rajchenbach-Teller writes:
>
>> To improve the Performance St
Note that I'm looking for a way to track this across the entire process,
not a single document. I'd rather avoid having to track all documents
(both XUL and HTML) in the process if I can find a simpler solution.
On 30/10/15 01:18, Brian Birtles wrote:
> For CSS animations/transitions (not includin
Yes, that's also my guess. I'd appreciate if someone could confirm that.
Also, I haven't found a public API for this, so I'm digging in the
source of the refresh driver, and I haven't found confirmation yet.
Cheers,
David
On 30/10/15 02:33, Karl Tomlinson wrote:
> David Rajchenbach-Teller writes
Recall that I'm not interested in measuring all latency, only (for the
time being) latency caused by JS code executing on the main thread or
waiting for a CPOW. This simplifies a lot the implementation (when I
execute JS code, I just need to check whether I'm currently dealing with
a user-issued ev
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 last
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 t
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 meas
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 respo
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/animatio
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
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, D
13 matches
Mail list logo
