Re: getComputedStyle now skips restyling if possible

2017-09-28 Thread Emilio Cobos Álvarez 
On 09/28/2017 11:00 AM, Wei-Cheng Pan wrote:
> Hi,
> 
> This week I landed bug 1363805[1], which will skip restyling if the
> element does
> not need that for getting correct value. Normal users should not notice any
> difference, but this change may affect some test cases which need to force
> restyle.

Awesome! Thanks a lot for getting that landed, I know it was harder than
expected! :)

Just for the record, I happened to be looking at Blink code for
unrelated reasons, and found that we can probably optimize layout
flushes a bit better too.

I filed bug 1404140 with the details. I'll try to look at it, but I'm
probably not going to be able to fix it in the short-term. If you or
someone else can grab it sooner that would be absolutely lovely!

 -- Emilio

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

Re: Follow up on clang-format

2017-09-28 Thread Randell Jesup 
>On Thursday, September 28, 2017 at 10:15:05 AM UTC+2, Chris Pearce wrote:
>Oh d'oh! Looks like I replied to an old thread, and the plan now is in fact
>to clang-format the entire tree after 57. Sweet as!

Where did you find that?  Was this plan communicated?  It's not in this
thread... (which started with smaug replying to a 2014 post by Anthony).
Personally, this will mostly make me sad/annoyed and make figuring out
why code was landed a pain (can be a real pain for people who do a lot
of reviews), but I'll deal with it.  I'm more concerned that this wasn't
communicated (or discussed!) well, since 58 is already open...

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is Quantum DOM affecting DevTools?

2017-09-28 Thread Jason Duell 
We did do some work to slow down network loads in background tabs (in order
to prioritize the active tab).  Is the issue that you need to switch to the
background tab in order to make it connect faster?  Or does the foreground
tab not load quickly unless you switch back and forth from it?  I'm hoping
the former.

If you've got reliable STR it's probably time to open a bug and cc me
(:jduell), :mcmanus and Honza (:mayhemer).

Jason

On Thu, Sep 28, 2017 at 10:19 AM, Bill McCloskey 
wrote:

> If that's caused by anything Quantum-related, it's more likely to be
> Quantum networking stuff.
> -Bill
>
> On Thu, Sep 28, 2017 at 2:30 AM, Salvador de la Puente <
> sdelapue...@mozilla.com> wrote:
>
> > Hello there!
> >
> > I was testing some WebRTC demos in two separate tabs in Nightly. I
> realized
> > I needed to switch from one to another for them to connect faster. I
> > thought it would be related to Quantum DOM throttling and I was
> > wondering...
> >
> >- Is it possible that throttling would be affecting DevTools?
> >- Would it be possible to disable throttling if DevTools are open?
> >
> > What do you think?
> >
> > --
> > 
> > ___
> > 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: getComputedStyle now skips restyling if possible

2017-09-28 Thread Bobby Holley 
This is a great optimization - thanks wcp!

On Thu, Sep 28, 2017 at 2:00 AM, Wei-Cheng Pan  wrote:

> Hi,
>
> This week I landed bug 1363805[1], which will skip restyling if the
> element does
> not need that for getting correct value. Normal users should not notice any
> difference, but this change may affect some test cases which need to force
> restyle.
>
> The optimization only happens when the element satisfies *all* the
> following
> conditions:
>
> 1. The CSS property does not depend on layout.
> 2. getComputedStyle and the element belong to the same document.
> 3. The document does not need to restyle for this element, i.e.
> 3-1. The document has a presshell.
> 3-2. The style set has not changed yet.
> 3-3. All ancestors (including the element itself) are not animating.
> 3-4. All ancestors (including the element itself) do not need to restyle
>  themselves.
> 4. All ancestor documents satisfy 3 for the sub-document.
>
> For example, getComputedStyle(document.body).color will not trigger
> restyling if
> only descendants have changed but not document.body itself. If you are
> not sure
> (or just don't care about it), choose a layout dependent property will
> do the
> trick. (e.g.: getComputedStyle(document.body).width)
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1363805
>
> Cheers,
> Wei-Cheng Pan
> ___
> 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: Is Quantum DOM affecting DevTools?

2017-09-28 Thread Bill McCloskey 
If that's caused by anything Quantum-related, it's more likely to be
Quantum networking stuff.
-Bill

On Thu, Sep 28, 2017 at 2:30 AM, Salvador de la Puente <
sdelapue...@mozilla.com> wrote:

> Hello there!
>
> I was testing some WebRTC demos in two separate tabs in Nightly. I realized
> I needed to switch from one to another for them to connect faster. I
> thought it would be related to Quantum DOM throttling and I was
> wondering...
>
>- Is it possible that throttling would be affecting DevTools?
>- Would it be possible to disable throttling if DevTools are open?
>
> What do you think?
>
> --
> 
> ___
> 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

Is Quantum DOM affecting DevTools?

2017-09-28 Thread Salvador de la Puente 
Hello there!

I was testing some WebRTC demos in two separate tabs in Nightly. I realized
I needed to switch from one to another for them to connect faster. I
thought it would be related to Quantum DOM throttling and I was wondering...

   - Is it possible that throttling would be affecting DevTools?
   - Would it be possible to disable throttling if DevTools are open?

What do you think?

-- 

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

getComputedStyle now skips restyling if possible

2017-09-28 Thread Wei-Cheng Pan 
Hi,

This week I landed bug 1363805[1], which will skip restyling if the
element does
not need that for getting correct value. Normal users should not notice any
difference, but this change may affect some test cases which need to force
restyle.

The optimization only happens when the element satisfies *all* the following
conditions:

1. The CSS property does not depend on layout.
2. getComputedStyle and the element belong to the same document.
3. The document does not need to restyle for this element, i.e.
3-1. The document has a presshell.
3-2. The style set has not changed yet.
3-3. All ancestors (including the element itself) are not animating.
3-4. All ancestors (including the element itself) do not need to restyle
 themselves.
4. All ancestor documents satisfy 3 for the sub-document.

For example, getComputedStyle(document.body).color will not trigger
restyling if
only descendants have changed but not document.body itself. If you are
not sure
(or just don't care about it), choose a layout dependent property will
do the
trick. (e.g.: getComputedStyle(document.body).width)

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1363805

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

Re: Follow up on clang-format

2017-09-28 Thread Chris Pearce 
On Thursday, September 28, 2017 at 10:15:05 AM UTC+2, Chris Pearce wrote:
> On Friday, May 23, 2014 at 3:29:48 AM UTC+2, Anthony Jones wrote:
> > Some of you may remember the discussion on clang-format and the `mach
> > clang-format` command. What we have in place right now is very temporary
> > but it is functional enough to give it a try. I have not put the effort
> > into upstreaming my changes. Depending on the feedback I receive I will
> > either:
> > 
> > * Finish my existing changes and upstream them
> > * Remove the `mach clang-format` command altogether
> > * Do nothing
> > 
> > I have personally found it useful. However I would like to hear from
> > other people who have tried it to help me decide what to do next.
> > 
> > Anthony
> 
> I use `./mach clang-format` on basically every patch I write. It has 
> eliminated the style nits that get picked up when people review my patches, 
> at least when I remember to run it!
> 
> I've considered writing a commit hook to run `./mach clang-format` before 
> every commit, but haven't gotten around to it...
> 
> `mach clang-format` is awesome, please don't remove it.
> 
> As others have pointed out, it doesn't always produce nice formatting, but 
> it's at least consistent, and enforces the major style guide recommendations.
> 
> It's also liberating not having to waste brain power deciding how to format 
> code.
> 
> 
> cpearce.

Oh d'oh! Looks like I replied to an old thread, and the plan now is in fact to 
clang-format the entire tree after 57. Sweet as!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Follow up on clang-format

2017-09-28 Thread Chris Pearce 
On Friday, May 23, 2014 at 3:29:48 AM UTC+2, Anthony Jones wrote:
> Some of you may remember the discussion on clang-format and the `mach
> clang-format` command. What we have in place right now is very temporary
> but it is functional enough to give it a try. I have not put the effort
> into upstreaming my changes. Depending on the feedback I receive I will
> either:
> 
> * Finish my existing changes and upstream them
> * Remove the `mach clang-format` command altogether
> * Do nothing
> 
> I have personally found it useful. However I would like to hear from
> other people who have tried it to help me decide what to do next.
> 
> Anthony

I use `./mach clang-format` on basically every patch I write. It has eliminated 
the style nits that get picked up when people review my patches, at least when 
I remember to run it!

I've considered writing a commit hook to run `./mach clang-format` before every 
commit, but haven't gotten around to it...

`mach clang-format` is awesome, please don't remove it.

As others have pointed out, it doesn't always produce nice formatting, but it's 
at least consistent, and enforces the major style guide recommendations.

It's also liberating not having to waste brain power deciding how to format 
code.


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