OMTC on Windows

[Bas Schouten]

Hey all,

After quite a lot of waiting we've switched on OMTC on Windows by default today 
(bug 899785). This is a great move towards moving all our platforms onto OMTC 
(only linux is left now), and will allow us to remove a lot of code that we've 
currently been duplicating. Furthermore it puts us on track for enabling other 
features on desktop like APZ, off main thread animations and other improvements.

Having said that we realize that what we've currently landed and turned on is 
not completely bug free. There's several bugs still open (some more serious 
than others) which we will be addressing in the coming weeks, hopefully before 
the merge to Aurora. The main reason we've switched it on now is that we want 
to get as much data as possible from the nightly channel and our nightly user 
base before the aurora merge, as well as wanting to prevent any new regressions 
from creeping in while we fix the remaining problems. This was extensively 
discussed both internally in the graphics team and externally with other people 
and we believe we're at a point now where things are sufficiently stabilized 
for our nightly audience. OMTC is enabled and disabled with a single pref so if 
unforeseen, serious consequences occur we can disable it quickly at any stage. 
We will inevitably find new bugs in the coming weeks, please link any bugs you 
happen to come across to bug 899785, if anything se
 ems very serious, please let us know, we'll attempt to come up with a solution 
on the short-term rather than disabling OMTC and reducing the amount of 
feedback we get.

There's also some important notes to make on performance, which we expect to be 
reported by our automated systems:

- Bug 1000640 is about WebGL. Currently OMTC regresses WebGL performance 
considerably, patches to fix this are underway and this should be fixed on the 
very short term.

- Several of the Talos test suite numbers will change considerably (especially 
with Direct2D enabled), this means Tscroll for example will improve by ~25%, 
but tart will regress by ~20%, and several other suites will regress as well. 
We've investigated this extensively and we believe the majority of these 
regressions are due to the nature of OMTC and the fact that we have to do more 
work. We see no value in holding off OMTC because of these regressions as we'll 
have to go there anyway. Once the last correctness and stability problems are 
all solved we will go back to trying to find ways to get back some of the 
performance regressions. We're also planning to move to a system more like 
tiling in desktop, which will change the performance characteristics 
significantly again, so we don't want to sink too much time into optimizing the 
current situation.

- Memory numbers will increase somewhat, this is unavoidable, there's several 
steps which have to be taken when doing off main thread compositing (like 
double-buffering), which inherently use more memory.

- On a brighter note: Async video is also enabled by these patches. This means 
that when the main thread is busy churning JavaScript, instead of stuttering 
your video should now happily continue playing!

- Also there's some indications that there's a subjective increase in scrolling 
performance as well.


If you have any questions please feel free to reach out to myself or other 
members of the graphics team!


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

Gecko style: Formatting function return type and specifiers

[Birunthan Mohanathas]

For top-level function definitions, the recommended style is:

template
static inline T
Foo()
{
  // ...
}

However, for function declarations and inline member functions, there
does not seem to be a definitive style. Some use:

int Foo();

class Bar
{
  virtual int Baz()
  {
// ...
  }
};

... and others use:

int
Foo();

class Bar
{
  virtual int
  Baz()
  {
// ...
  }
};

Which one should be preferred?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Gecko style: Line-continuation backslash in macros

[Birunthan Mohanathas]

(Note: Use a monospace font to view this message or use
.)

The placement of the line-continuation backslash in macros is wildly
inconsistent. Some put the backslash directly after the line:

#define NS_IMPL_CYCLE_COLLECTION_CAN_SKIP_IN_CC_BEGIN(_class) \
  NS_IMETHODIMP_(bool) \
  NS_CYCLE_COLLECTION_CLASSNAME(_class)::CanSkipInCCReal(void *p) \
  { \
_class *tmp = DowncastCCParticipant<_class >(p);


Others align the backslashes with that of the longest line:

#define NS_IMPL_CYCLE_COLLECTION_CAN_SKIP_IN_CC_BEGIN(_class) \
  NS_IMETHODIMP_(bool)\
  NS_CYCLE_COLLECTION_CLASSNAME(_class)::CanSkipInCCReal(void *p) \
  {   \
_class *tmp = DowncastCCParticipant<_class >(p);


And the rest put the backslashes at the 80th column:

#define NS_IMPL_CYCLE_COLLECTION_CAN_SKIP_IN_CC_BEGIN(_class)  \
  NS_IMETHODIMP_(bool) \
  NS_CYCLE_COLLECTION_CLASSNAME(_class)::CanSkipInCCReal(void *p)  \
  {\
_class *tmp = DowncastCCParticipant<_class >(p);


Of these options, I personally dislike the second style as it will
result in unnecessary churn whenever the longest line changes. Is
there a preferred style?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Gecko style: Braces with enums and uninons

[Birunthan Mohanathas]

While working on bug 995730, I bumped into a few things that the Gecko
style guide leaves unspecified. I have described one such case below.
I'll create separate threads for the other things in order to maximize
the number of bikeshedding threads (and for readability).

For classes and structs, braces are placed like so:

class Foo
{
  // ...
};

How should they be placed for enums and unions? What about with
anonymous enums and unions?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OMTC on Windows

[Armen Zambrano G.]

What kind of bugs could we expect seeing?
Any place you would like us to put focus on testing?

Thanks for all the hard work to get this in.

cheers,
Armen

On 2014-05-18, 3:16 AM, Bas Schouten wrote:
> Hey all,
> 
> After quite a lot of waiting we've switched on OMTC on Windows by default 
> today (bug 899785). This is a great move towards moving all our platforms 
> onto OMTC (only linux is left now), and will allow us to remove a lot of code 
> that we've currently been duplicating. Furthermore it puts us on track for 
> enabling other features on desktop like APZ, off main thread animations and 
> other improvements.
> 
> Having said that we realize that what we've currently landed and turned on is 
> not completely bug free. There's several bugs still open (some more serious 
> than others) which we will be addressing in the coming weeks, hopefully 
> before the merge to Aurora. The main reason we've switched it on now is that 
> we want to get as much data as possible from the nightly channel and our 
> nightly user base before the aurora merge, as well as wanting to prevent any 
> new regressions from creeping in while we fix the remaining problems. This 
> was extensively discussed both internally in the graphics team and externally 
> with other people and we believe we're at a point now where things are 
> sufficiently stabilized for our nightly audience. OMTC is enabled and 
> disabled with a single pref so if unforeseen, serious consequences occur we 
> can disable it quickly at any stage. We will inevitably find new bugs in the 
> coming weeks, please link any bugs you happen to come across to bug 899785, 
> if anything 
 seems ver
y serious, please let us know, we'll attempt to come up with a solution on the 
short-term rather than disabling OMTC and reducing the amount of feedback we 
get.
> 
> There's also some important notes to make on performance, which we expect to 
> be reported by our automated systems:
> 
> - Bug 1000640 is about WebGL. Currently OMTC regresses WebGL performance 
> considerably, patches to fix this are underway and this should be fixed on 
> the very short term.
> 
> - Several of the Talos test suite numbers will change considerably 
> (especially with Direct2D enabled), this means Tscroll for example will 
> improve by ~25%, but tart will regress by ~20%, and several other suites will 
> regress as well. We've investigated this extensively and we believe the 
> majority of these regressions are due to the nature of OMTC and the fact that 
> we have to do more work. We see no value in holding off OMTC because of these 
> regressions as we'll have to go there anyway. Once the last correctness and 
> stability problems are all solved we will go back to trying to find ways to 
> get back some of the performance regressions. We're also planning to move to 
> a system more like tiling in desktop, which will change the performance 
> characteristics significantly again, so we don't want to sink too much time 
> into optimizing the current situation.
> 
> - Memory numbers will increase somewhat, this is unavoidable, there's several 
> steps which have to be taken when doing off main thread compositing (like 
> double-buffering), which inherently use more memory.
> 
> - On a brighter note: Async video is also enabled by these patches. This 
> means that when the main thread is busy churning JavaScript, instead of 
> stuttering your video should now happily continue playing!
> 
> - Also there's some indications that there's a subjective increase in 
> scrolling performance as well.
> 
> 
> If you have any questions please feel free to reach out to myself or other 
> members of the graphics team!
> 
> 
> Bas
> 


-- 
Zambrano Gasparnian, Armen (armenzg)
Mozilla Senior Release Engineer
https://mozillians.org/en-US/u/armenzg/
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OMTC on Windows

[Gavin Sharp]

> but tart will regress by ~20%, and several other suites will regress as well.
> We've investigated this extensively and we believe the majority of these
> regressions are due to the nature of OMTC and the fact that we have to do
> more work.

Where can I read more about the TART investigations? I'd like to
understand why it is seen as inevitable, and get some of the details
of the regression. OMTC is important, and I'm excited to see it land
on Windows, but the Firefox and Performance teams have just come off a
months-long effort to make significant wins in TART, and the thought
of taking a 20% regression (huge compared to some of the improvements
we fought for) is pretty disheartening.

Gavin

On Sun, May 18, 2014 at 12:16 AM, Bas Schouten  wrote:
> Hey all,
>
> After quite a lot of waiting we've switched on OMTC on Windows by default 
> today (bug 899785). This is a great move towards moving all our platforms 
> onto OMTC (only linux is left now), and will allow us to remove a lot of code 
> that we've currently been duplicating. Furthermore it puts us on track for 
> enabling other features on desktop like APZ, off main thread animations and 
> other improvements.
>
> Having said that we realize that what we've currently landed and turned on is 
> not completely bug free. There's several bugs still open (some more serious 
> than others) which we will be addressing in the coming weeks, hopefully 
> before the merge to Aurora. The main reason we've switched it on now is that 
> we want to get as much data as possible from the nightly channel and our 
> nightly user base before the aurora merge, as well as wanting to prevent any 
> new regressions from creeping in while we fix the remaining problems. This 
> was extensively discussed both internally in the graphics team and externally 
> with other people and we believe we're at a point now where things are 
> sufficiently stabilized for our nightly audience. OMTC is enabled and 
> disabled with a single pref so if unforeseen, serious consequences occur we 
> can disable it quickly at any stage. We will inevitably find new bugs in the 
> coming weeks, please link any bugs you happen to come across to bug 899785, 
> if anything 
 se
>  ems very serious, please let us know, we'll attempt to come up with a 
> solution on the short-term rather than disabling OMTC and reducing the amount 
> of feedback we get.
>
> There's also some important notes to make on performance, which we expect to 
> be reported by our automated systems:
>
> - Bug 1000640 is about WebGL. Currently OMTC regresses WebGL performance 
> considerably, patches to fix this are underway and this should be fixed on 
> the very short term.
>
> - Several of the Talos test suite numbers will change considerably 
> (especially with Direct2D enabled), this means Tscroll for example will 
> improve by ~25%, but tart will regress by ~20%, and several other suites will 
> regress as well. We've investigated this extensively and we believe the 
> majority of these regressions are due to the nature of OMTC and the fact that 
> we have to do more work. We see no value in holding off OMTC because of these 
> regressions as we'll have to go there anyway. Once the last correctness and 
> stability problems are all solved we will go back to trying to find ways to 
> get back some of the performance regressions. We're also planning to move to 
> a system more like tiling in desktop, which will change the performance 
> characteristics significantly again, so we don't want to sink too much time 
> into optimizing the current situation.
>
> - Memory numbers will increase somewhat, this is unavoidable, there's several 
> steps which have to be taken when doing off main thread compositing (like 
> double-buffering), which inherently use more memory.
>
> - On a brighter note: Async video is also enabled by these patches. This 
> means that when the main thread is busy churning JavaScript, instead of 
> stuttering your video should now happily continue playing!
>
> - Also there's some indications that there's a subjective increase in 
> scrolling performance as well.
>
>
> If you have any questions please feel free to reach out to myself or other 
> members of the graphics team!
>
>
> Bas
> ___
> 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: OMTC on Windows

[Chris Peterson]

That's awesome news, Bas! OMTC on Windows has been one of the major 
dependencies for e10s.


AFAIU, Nightly users on Windows should now be able to test per-window 
e10s without tweaking any prefs or restarting the browser. To open an 
e10s window, open "File (or Hamburger)" menu then "New e10s Window" menu 
item.


(Nightly users on OS X have been able to test per-window e10s for a 
couple months now.)



chris


On 5/18/14, 12:16 AM, Bas Schouten wrote:

Hey all,

After quite a lot of waiting we've switched on OMTC on Windows by default today 
(bug 899785). This is a great move towards moving all our platforms onto OMTC 
(only linux is left now), and will allow us to remove a lot of code that we've 
currently been duplicating. Furthermore it puts us on track for enabling other 
features on desktop like APZ, off main thread animations and other improvements.

Having said that we realize that what we've currently landed and turned on is not completely bug free. There's several bugs still open (some more serious than others) which we will be addressing in the coming weeks, hopefully before the merge to Aurora. The main reason we've switched it on now is that we want to get as much data as possible from the nightly channel and our nightly user base before the aurora merge, as well as wanting to prevent any new regressions from creeping in while we fix the remaining problems. This was extensively discussed both internally in the graphics team and externally with other people and we believe we're at a point now where things are sufficiently stabilized for our nightly audience. OMTC is enabled and disabled with a single pref so if unforeseen, serious consequences occur we can disable it quickly at any stage. We will inevitably find new bugs in the coming weeks, please link any bugs you happen to come across to bug 899785, if anything 

seems ver
y serious, please let us know, we'll attempt to come up with a solution on the 
short-term rather than disabling OMTC and reducing the amount of feedback we 
get.


There's also some important notes to make on performance, which we expect to be 
reported by our automated systems:

- Bug 1000640 is about WebGL. Currently OMTC regresses WebGL performance 
considerably, patches to fix this are underway and this should be fixed on the 
very short term.

- Several of the Talos test suite numbers will change considerably (especially 
with Direct2D enabled), this means Tscroll for example will improve by ~25%, 
but tart will regress by ~20%, and several other suites will regress as well. 
We've investigated this extensively and we believe the majority of these 
regressions are due to the nature of OMTC and the fact that we have to do more 
work. We see no value in holding off OMTC because of these regressions as we'll 
have to go there anyway. Once the last correctness and stability problems are 
all solved we will go back to trying to find ways to get back some of the 
performance regressions. We're also planning to move to a system more like 
tiling in desktop, which will change the performance characteristics 
significantly again, so we don't want to sink too much time into optimizing the 
current situation.

- Memory numbers will increase somewhat, this is unavoidable, there's several 
steps which have to be taken when doing off main thread compositing (like 
double-buffering), which inherently use more memory.

- On a brighter note: Async video is also enabled by these patches. This means 
that when the main thread is busy churning JavaScript, instead of stuttering 
your video should now happily continue playing!

- Also there's some indications that there's a subjective increase in scrolling 
performance as well.


If you have any questions please feel free to reach out to myself or other 
members of the graphics team!


Bas



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

Re: OMTC on Windows

[Bas Schouten]

Hi Gavin,

There have been several e-mails on different lists, and some communication on 
some bugs. Sadly the story is at this point not anywhere in a condensed form, 
but I will try to highlight a couple of core points, some of these will be 
updated further as the investigation continues. The official bug is bug 946567 
but the numbers and the discussion there are far outdated (there's no 400% 
regression ;)):

- What OMTC does to tart scores differs wildly per machine, on some machines we 
saw up to 10% improvements, on others up to 20% regressions. There also seems 
to be somewhat more of a regression on Win7 than there is on Win8. What the 
average is for our users is very hard to say, frankly I have no idea.
- One core cause of the regression is that we're now dealing with two D3D 
devices when using Direct2D since we're doing D2D drawing on one thread, and 
D3D11 composition on the other. This means we have DXGI locking overhead to 
synchronize the two. This is unavoidable.
- Another cause is that we're now having two surfaces in order to do double 
buffering, this means we need to initialize more resources when new layers come 
into play. This again, is unavoidable.
- Yet another cause is that for some tests we composite 'ASAP' to get 
interesting numbers, but this causes some contention scenario's which are less 
likely to occur in real-life usage. Since the double buffer might copy the area 
validated in the last frame from the front buffer to the backbuffer in order to 
prevent having to redraw much more. If the compositor is compositing all the 
time this can block the main thread's rasterization. I have some ideas on how 
to improve this, but I don't know how much they'll help TART, in any case, some 
cost here will be unavoidable as a natural additional consequence of double 
buffering.
- The TART number story is complicated, sometimes it's hard to know what 
exactly they do, and don't measure (which might be different with and without 
OMTC) and how that affects practical performance. I've been told this by Avi 
and it matches my practical experience with the numbers. I don't know the exact 
reasons and Avi is probably a better person to talk about this than I am :-).

These are the core reasons that we were able to identify from profiling. Other 
than that the things I said in my previous e-mail still apply. We believe we're 
offering significant UX improvements with async video and are enabling more 
significant improvements in the future. Once we've fixed the obvious problems 
we will continue to see if there's something that can be done, either through 
tiling or through other improvements, particularly in the last point I 
mentioned there might be some, not 'too' complex things we can do to offer some 
small improvement.

If we want to have a more detailed discussion we should probably pick a list to 
have this on and try not to spam people too much :-).

Bas

- Original Message -
From: "Gavin Sharp" 
To: "Bas Schouten" 
Cc: "dev-tree-management" , 
dev-tech-...@lists.mozilla.org, "release-drivers" 
, "mozilla.dev.platform group" 

Sent: Sunday, May 18, 2014 6:23:58 PM
Subject: Re: OMTC on Windows

> but tart will regress by ~20%, and several other suites will regress as well.
> We've investigated this extensively and we believe the majority of these
> regressions are due to the nature of OMTC and the fact that we have to do
> more work.

Where can I read more about the TART investigations? I'd like to
understand why it is seen as inevitable, and get some of the details
of the regression. OMTC is important, and I'm excited to see it land
on Windows, but the Firefox and Performance teams have just come off a
months-long effort to make significant wins in TART, and the thought
of taking a 20% regression (huge compared to some of the improvements
we fought for) is pretty disheartening.

Gavin

On Sun, May 18, 2014 at 12:16 AM, Bas Schouten  wrote:
> Hey all,
>
> After quite a lot of waiting we've switched on OMTC on Windows by default 
> today (bug 899785). This is a great move towards moving all our platforms 
> onto OMTC (only linux is left now), and will allow us to remove a lot of code 
> that we've currently been duplicating. Furthermore it puts us on track for 
> enabling other features on desktop like APZ, off main thread animations and 
> other improvements.
>
> Having said that we realize that what we've currently landed and turned on is 
> not completely bug free. There's several bugs still open (some more serious 
> than others) which we will be addressing in the coming weeks, hopefully 
> before the merge to Aurora. The main reason we've switched it on now is that 
> we want to get as much data as possible from the nightly channel and our 
> nightly user base before the aurora merge, as well as wanting to prevent any 
> new regressions from creeping in while we fix the remaining problems. This 
> was extensively discussed both internally in the graphics team and extern

Re: OMTC on Windows

[avihal]

Re TART regressions and Gavin's concerns - as always, we should not trust the 
numbers blindly.

The first thing we need is probably taking few windows machines with different 
performance characteristics and compare tab animation perf on those machines, 
especially on the cases where TART shows regression (TART measures 10 cases of 
animation - like when opening a new tab, closing a tab, in several DPIs, etc), 
and preferably listen to subjective assessments on this from more than one 
person.

We should also remember that tests tend to be more reliable when the stuff they 
measure is in their "comfort zone". The more specialized the test is - the more 
it expects the test subject to behave within tighter constraints, and vice 
verse - the higher level the test is, the more it could treat its subject like 
a black box, and cares less about internal details.

TART happens to be quite specialized and OMTC is a major shift in graphics 
implementation. Even if TART is already running and providing useful results 
with OMTC on OS X, it could still be out of its "comfort zone" with OMTC on 
windows.

This is true about all tests. The more specialized the test is - the more it 
needs to be kept aligned with test subject, and the more it could produce less 
reliable results when it isn't.

So, we should take the regression numbers with a grain of salt, and try to make 
sure first that the results are still good, and if they are, see what we can do 
about it, etc.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OMTC on Windows

[Bas Schouten]

Hi Armen,

You -could- be seeing all kinds of bugs, but the most likely things I'd be 
expecting is things while window shapes and such are updating (i.e. resizing, 
pop-up windows, awesomebar, etc.) particularly since those type of short-lived 
compositors are not typical on mobile devices where we've been using OMTC for 
the longest, as well as being very platform-specific in their behavior.

Thanks!
Bas

- Original Message -
From: "Armen Zambrano G." 
To: dev-platform@lists.mozilla.org
Sent: Sunday, May 18, 2014 5:50:50 PM
Subject: Re: OMTC on Windows

What kind of bugs could we expect seeing?
Any place you would like us to put focus on testing?

Thanks for all the hard work to get this in.

cheers,
Armen

On 2014-05-18, 3:16 AM, Bas Schouten wrote:
> Hey all,
> 
> After quite a lot of waiting we've switched on OMTC on Windows by default 
> today (bug 899785). This is a great move towards moving all our platforms 
> onto OMTC (only linux is left now), and will allow us to remove a lot of code 
> that we've currently been duplicating. Furthermore it puts us on track for 
> enabling other features on desktop like APZ, off main thread animations and 
> other improvements.
> 
> Having said that we realize that what we've currently landed and turned on is 
> not completely bug free. There's several bugs still open (some more serious 
> than others) which we will be addressing in the coming weeks, hopefully 
> before the merge to Aurora. The main reason we've switched it on now is that 
> we want to get as much data as possible from the nightly channel and our 
> nightly user base before the aurora merge, as well as wanting to prevent any 
> new regressions from creeping in while we fix the remaining problems. This 
> was extensively discussed both internally in the graphics team and externally 
> with other people and we believe we're at a point now where things are 
> sufficiently stabilized for our nightly audience. OMTC is enabled and 
> disabled with a single pref so if unforeseen, serious consequences occur we 
> can disable it quickly at any stage. We will inevitably find new bugs in the 
> coming weeks, please link any bugs you happen to come across to bug 899785, 
> if anything 
 seems ver
y serious, please let us know, we'll attempt to come up with a solution on the 
short-term rather than disabling OMTC and reducing the amount of feedback we 
get.
> 
> There's also some important notes to make on performance, which we expect to 
> be reported by our automated systems:
> 
> - Bug 1000640 is about WebGL. Currently OMTC regresses WebGL performance 
> considerably, patches to fix this are underway and this should be fixed on 
> the very short term.
> 
> - Several of the Talos test suite numbers will change considerably 
> (especially with Direct2D enabled), this means Tscroll for example will 
> improve by ~25%, but tart will regress by ~20%, and several other suites will 
> regress as well. We've investigated this extensively and we believe the 
> majority of these regressions are due to the nature of OMTC and the fact that 
> we have to do more work. We see no value in holding off OMTC because of these 
> regressions as we'll have to go there anyway. Once the last correctness and 
> stability problems are all solved we will go back to trying to find ways to 
> get back some of the performance regressions. We're also planning to move to 
> a system more like tiling in desktop, which will change the performance 
> characteristics significantly again, so we don't want to sink too much time 
> into optimizing the current situation.
> 
> - Memory numbers will increase somewhat, this is unavoidable, there's several 
> steps which have to be taken when doing off main thread compositing (like 
> double-buffering), which inherently use more memory.
> 
> - On a brighter note: Async video is also enabled by these patches. This 
> means that when the main thread is busy churning JavaScript, instead of 
> stuttering your video should now happily continue playing!
> 
> - Also there's some indications that there's a subjective increase in 
> scrolling performance as well.
> 
> 
> If you have any questions please feel free to reach out to myself or other 
> members of the graphics team!
> 
> 
> Bas
> 


-- 
Zambrano Gasparnian, Armen (armenzg)
Mozilla Senior Release Engineer
https://mozillians.org/en-US/u/armenzg/
http://armenzg.blogspot.ca
___
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 implement and ship: navigator.hardwareConcurrency

[Rik Cabanier]

FYI this attribute landed in WebKit today:
http://trac.webkit.org/changeset/169017


On Thu, May 15, 2014 at 1:26 AM, Rik Cabanier  wrote:

>
>
>
> On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari 
> wrote:
>
>> On 2014-05-13, 9:01 PM, Rik Cabanier wrote:
>>
>>> ...
>>>
>>> The problem is that the API doesn't really make it obvious that
>>> you're not supposed to take the value that the getter returns and
>>> just spawn N workers.  IOW, the API encourages the wrong behavior by
>>> design.
>>>
>>>
>>> That is simply untrue.
>>>
>>
>> I'm assuming that the goal of this API is to allow authors to spawn as
>> many workers as possible so that they can exhaust all of the cores in the
>> interest of finishing their computation faster.
>>
>
> That is one way of using it but not the only one.
> For instance, let's say that I'm writing on a cooperative game. I might
> want to put all my network logic in a worker and want to make sure that
> worker is scheduled. This worker consumes little (if any) cpu, but I want
> it to be responsive.
> NumCores = 1 -> do everything in the main thread and try to make sure the
> network code executes
> NumCores = 2 -> spin up a worker for the network code. Everything else in
> the main thread
> NumCores = 3 -> spin up a worker for the network code + another one for
> physics and image decompression. Everything else in the main thread
>
>
>>  I have provided reasons why any thread which is running at a higher
>> priority on the system busy doing work is going to make this number an over
>> approximation, I have given you two examples of higher priority threads
>> that we're currently shipping in Firefox (Chrome Workers and the
>> MediaStreamGraph thread)
>
>
> You're arguing against basic multithreading functionality. I'm unsure how
> ANY thread framework in a browser could fix this since there might be other
> higher priority tasks in the system.
> For your example of Chrome Workers and MediaStreamGraph, I assume those
> don't run at a constant 100% so a webapp that grabs all cores will still
> get more work done.
>
>
>> and have provided you with experimental evidence of running Eli's test
>> cases trying to exhaust as many cores as it can fails to predict the number
>> of cores in these situations.
>
>
> Eli's code is an approximation. It doesn't prove anything.
> I don't understand your point here.
>
>
>>  If you don't find any of this convincing, I'd respectfully ask us to
>> agree to disagree on this point.
>
>
> OK.
>
>
>>  For the sake of argument, let's say you are right. How are things worse
>>> than before?
>>>
>>
>> I don't think we should necessarily try to find a solution that is just
>> not worse than the status quo, I'm more interested in us implementing a
>> good solution here (and yes, I'm aware that there is no concrete proposal
>> out there that is better at this point.)
>
>
> So, worst case, there's no harm.
> Best case, we have a more responsive application.
>
>  ...
>>>
>>>
>>> That's fine but we're coming right back to the start: there is no way
>>> for informed authors to make a decision today.
>>>
>>
>> Yes, absolutely.
>>
>>
>>  The "let's build something complex that solves everything" proposal
>>> won't be done in a long time. Meanwhile apps can make responsive UI's
>>> and fluid games.
>>>
>>
>> That's I think one fundamental issue we're disagreeing on.  I think that
>> apps can build responsive UIs and fluid games without this today on the Web.
>>
>
> Sure. You can build apps that don't tax the system or that are
> specifically tailored to work well on a popular system.
>
>
>>  There were 24,000 hits for java which is on the web and a VM but now you
>>> say that it's not a vote of popularity?
>>>
>>
>> We may have a different terminology here, but to me, "positive feedback
>> from web developers" should indicate a large amount of demand from the web
>> developer community for us to solve this problem at this point, and also a
>> strong positive signal from them on this specific solution with the flaws
>> that I have described above in mind.  That simply doesn't map to searching
>> for API names on non-Web technologies on github. :-)
>>
>
> This was not a simple search. Please look over the examples especially the
> node.js ones and see how it's being used.
> This is what we're trying to achieve with this attribute.
>
>
>> Also, FTR, I strongly disagree that we should implement all popular Java
>> APIs just because there is a way to run Java code on the web.  ;-)
>
>  ...
>>>
>>> Can you restate the actual problem? I reread your message but didn't
>>> find anything that indicates this is a bad idea.
>>>
>>
>> See above where I re-described why this is not a good technical solution
>> to achieve the goal of the API.
>>
>> Also, as I've mentioned several times, this API basically ignores the
>> fact that there are AMP systems shipping *today* and dies not take the fact
>> that future Web engines may try to use as many cores as they can at a

Re: Intent to implement and ship: navigator.hardwareConcurrency

[Xidorn Quan]

IMO, though we may have a better model in the future, it is at least not
harmful to have such attribute with some limitation. The WebKit guys think
it is not a fingerprinting when limiting the max value to 8. I think it
might be meaningful to also limit the number to power of 2 (very few people
has 3 or 6 cores so they will be fingerprinting as well).

And I think it makes sense to announce that, UA does not guarantee this
value a constant, so that UA can return whatever value it feels comfortable
with when the getter is invoked. Maybe in the future, we can even have an
event to notify the script that the number has been changed.

In addition, considering that WebKit has landed this feature, and Blink is
also going to implement that, it is not a bad idea for us to have the
attribute as well.


On Mon, May 19, 2014 at 9:23 AM, Rik Cabanier  wrote:

> FYI this attribute landed in WebKit today:
> http://trac.webkit.org/changeset/169017
>
>
> On Thu, May 15, 2014 at 1:26 AM, Rik Cabanier  wrote:
>
> >
> >
> >
> > On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari  >wrote:
> >
> >> On 2014-05-13, 9:01 PM, Rik Cabanier wrote:
> >>
> >>> ...
> >>>
> >>> The problem is that the API doesn't really make it obvious that
> >>> you're not supposed to take the value that the getter returns and
> >>> just spawn N workers.  IOW, the API encourages the wrong behavior
> by
> >>> design.
> >>>
> >>>
> >>> That is simply untrue.
> >>>
> >>
> >> I'm assuming that the goal of this API is to allow authors to spawn as
> >> many workers as possible so that they can exhaust all of the cores in
> the
> >> interest of finishing their computation faster.
> >>
> >
> > That is one way of using it but not the only one.
> > For instance, let's say that I'm writing on a cooperative game. I might
> > want to put all my network logic in a worker and want to make sure that
> > worker is scheduled. This worker consumes little (if any) cpu, but I want
> > it to be responsive.
> > NumCores = 1 -> do everything in the main thread and try to make sure the
> > network code executes
> > NumCores = 2 -> spin up a worker for the network code. Everything else in
> > the main thread
> > NumCores = 3 -> spin up a worker for the network code + another one for
> > physics and image decompression. Everything else in the main thread
> >
> >
> >>  I have provided reasons why any thread which is running at a higher
> >> priority on the system busy doing work is going to make this number an
> over
> >> approximation, I have given you two examples of higher priority threads
> >> that we're currently shipping in Firefox (Chrome Workers and the
> >> MediaStreamGraph thread)
> >
> >
> > You're arguing against basic multithreading functionality. I'm unsure how
> > ANY thread framework in a browser could fix this since there might be
> other
> > higher priority tasks in the system.
> > For your example of Chrome Workers and MediaStreamGraph, I assume those
> > don't run at a constant 100% so a webapp that grabs all cores will still
> > get more work done.
> >
> >
> >> and have provided you with experimental evidence of running Eli's test
> >> cases trying to exhaust as many cores as it can fails to predict the
> number
> >> of cores in these situations.
> >
> >
> > Eli's code is an approximation. It doesn't prove anything.
> > I don't understand your point here.
> >
> >
> >>  If you don't find any of this convincing, I'd respectfully ask us to
> >> agree to disagree on this point.
> >
> >
> > OK.
> >
> >
> >>  For the sake of argument, let's say you are right. How are things worse
> >>> than before?
> >>>
> >>
> >> I don't think we should necessarily try to find a solution that is just
> >> not worse than the status quo, I'm more interested in us implementing a
> >> good solution here (and yes, I'm aware that there is no concrete
> proposal
> >> out there that is better at this point.)
> >
> >
> > So, worst case, there's no harm.
> > Best case, we have a more responsive application.
> >
> >  ...
> >>>
> >>>
> >>> That's fine but we're coming right back to the start: there is no way
> >>> for informed authors to make a decision today.
> >>>
> >>
> >> Yes, absolutely.
> >>
> >>
> >>  The "let's build something complex that solves everything" proposal
> >>> won't be done in a long time. Meanwhile apps can make responsive UI's
> >>> and fluid games.
> >>>
> >>
> >> That's I think one fundamental issue we're disagreeing on.  I think that
> >> apps can build responsive UIs and fluid games without this today on the
> Web.
> >>
> >
> > Sure. You can build apps that don't tax the system or that are
> > specifically tailored to work well on a popular system.
> >
> >
> >>  There were 24,000 hits for java which is on the web and a VM but now
> you
> >>> say that it's not a vote of popularity?
> >>>
> >>
> >> We may have a different terminology here, but to me, "positive feedback
> >> from web developers" should indicate a large amount of demand from the
> web
> >> d

Re: OMTC on Windows

[Boris Zbarsky]

On 5/18/14, 2:23 PM, Gavin Sharp wrote:

OMTC is important, and I'm excited to see it land
on Windows, but the Firefox and Performance teams have just come off a
months-long effort to make significant wins in TART, and the thought
of taking a 20% regression (huge compared to some of the improvements
we fought for) is pretty disheartening.


My question here is whether we have data that indicates why there is a 
regression.  Are we painting more, or are we waiting on things more?


In particular, if I understand correctly TART uses a somewhat bizarre 
configuration: it tries to run refresh drivers at 10,000 frames per 
second (yes, 10kHz).  That may not going interact at all well with 
compositing at 60Hz, and I'm not even sure how well it'll interact with 
the work to trigger the refresh driver off vsync.


In any case, it's entirely possible to get regressions on TART that have 
nothing to do with actual slowdowns at normal frame rates.  That may not 
be the case here, but it's a distinct possibility that it is.  For 
example, on Mac we ended up special-casing the TART configuration and 
doing non-blocking buffer swaps in it (see bug 99) precisely because 
otherwise TART ended up gated on things other than actual rendering 
time.  I would not be terribly surprised if something like that needs to 
be done on Windows too...


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

Intent to implement: ResourceStats API

[Borting Chen]

Summary:
  ResourceStats API supports resource statistics and cost control for network 
usage and power consumption. Resource statistics provides resource usage 
information about the whole system, a system service, or an application. Cost 
control notifies user when resource usage exceeds a defined threshold.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=951976

Link to standard: N/A

Link to public discussion: 
https://groups.google.com/forum/#!topic/mozilla.dev.webapi/tWkgbD1v_Gg

Platform coverage: Firefox OS

Estimated or target release: TBD

Preference behind which this will be implemented: "dom.resource_stats.enabled"

--
Borting Chen
Intern of Mozilla Taiwan

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

Re: Intent to implement and ship: navigator.hardwareConcurrency

[Rik Cabanier]

On Sun, May 18, 2014 at 4:51 PM, Xidorn Quan  wrote:

> IMO, though we may have a better model in the future, it is at least not
> harmful to have such attribute with some limitation. The WebKit guys think
> it is not a fingerprinting when limiting the max value to 8. I think it
> might be meaningful to also limit the number to power of 2 (very few people
> has 3 or 6 cores so they will be fingerprinting as well).
>

There are CPU's from Intel [1], AMD [2], Samsung [3] and possible others
that have 6 cores. I'm unsure why we would treat them differently since
they're not high-value systems.

And I think it makes sense to announce that, UA does not guarantee this
> value a constant, so that UA can return whatever value it feels comfortable
> with when the getter is invoked. Maybe in the future, we can even have an
> event to notify the script that the number has been changed.
>

Yes, if a user agent wants to return a lower number (ie so a well-behaved
application leaves a CPU free), it's free to do so.
I'm unsure if the event is needed but that can be addressed later.


> In addition, considering that WebKit has landed this feature, and Blink is
> also going to implement that, it is not a bad idea for us to have the
> attribute as well.
>

The WebKit patch limits the maximum number to 8. The blink patch currently
does not limit what it returns.
My proposed mozilla patch [4] makes the maximum return value configurable
through a "dom.maxHardwareConcurrency" preference key. It currently has a
default value of 8.

1: http://ark.intel.com/products/63697 http://ark.intel.com/products/77780
2:
http://products.amd.com/en-us/DesktopCPUDetail.aspx?id=811&f1=&f2=&f3=&f4=&f5=&f6=&f7=&f8=&f9=&f10=&f11=&f12=
3:
http://www.samsung.com/global/business/semiconductor/minisite/Exynos/products5hexa.html
4: https://bugzilla.mozilla.org/show_bug.cgi?id=1008453


> On Mon, May 19, 2014 at 9:23 AM, Rik Cabanier  wrote:
>
>> FYI this attribute landed in WebKit today:
>> http://trac.webkit.org/changeset/169017
>>
>>
>> On Thu, May 15, 2014 at 1:26 AM, Rik Cabanier  wrote:
>>
>> >
>> >
>> >
>> > On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari <
>> ehsan.akhg...@gmail.com>wrote:
>> >
>> >> On 2014-05-13, 9:01 PM, Rik Cabanier wrote:
>> >>
>> >>> ...
>> >>>
>> >>> The problem is that the API doesn't really make it obvious that
>> >>> you're not supposed to take the value that the getter returns and
>> >>> just spawn N workers.  IOW, the API encourages the wrong behavior
>> by
>> >>> design.
>> >>>
>> >>>
>> >>> That is simply untrue.
>> >>>
>> >>
>> >> I'm assuming that the goal of this API is to allow authors to spawn as
>> >> many workers as possible so that they can exhaust all of the cores in
>> the
>> >> interest of finishing their computation faster.
>> >>
>> >
>> > That is one way of using it but not the only one.
>> > For instance, let's say that I'm writing on a cooperative game. I might
>> > want to put all my network logic in a worker and want to make sure that
>> > worker is scheduled. This worker consumes little (if any) cpu, but I
>> want
>> > it to be responsive.
>> > NumCores = 1 -> do everything in the main thread and try to make sure
>> the
>> > network code executes
>> > NumCores = 2 -> spin up a worker for the network code. Everything else
>> in
>> > the main thread
>> > NumCores = 3 -> spin up a worker for the network code + another one for
>> > physics and image decompression. Everything else in the main thread
>> >
>> >
>> >>  I have provided reasons why any thread which is running at a higher
>> >> priority on the system busy doing work is going to make this number an
>> over
>> >> approximation, I have given you two examples of higher priority threads
>> >> that we're currently shipping in Firefox (Chrome Workers and the
>> >> MediaStreamGraph thread)
>> >
>> >
>> > You're arguing against basic multithreading functionality. I'm unsure
>> how
>> > ANY thread framework in a browser could fix this since there might be
>> other
>> > higher priority tasks in the system.
>> > For your example of Chrome Workers and MediaStreamGraph, I assume those
>> > don't run at a constant 100% so a webapp that grabs all cores will still
>> > get more work done.
>> >
>> >
>> >> and have provided you with experimental evidence of running Eli's test
>> >> cases trying to exhaust as many cores as it can fails to predict the
>> number
>> >> of cores in these situations.
>> >
>> >
>> > Eli's code is an approximation. It doesn't prove anything.
>> > I don't understand your point here.
>> >
>> >
>> >>  If you don't find any of this convincing, I'd respectfully ask us to
>> >> agree to disagree on this point.
>> >
>> >
>> > OK.
>> >
>> >
>> >>  For the sake of argument, let's say you are right. How are things
>> worse
>> >>> than before?
>> >>>
>> >>
>> >> I don't think we should necessarily try to find a solution that is just
>> >> not worse than the status quo, I'm more interested in us implementing a
>> >> good solution 

Re: Gecko style: Braces with enums and uninons

[Dave Hylands]

My interpretation of this is that the only time braces go on the end of the 
line is when you're starting a "control structure" 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Control_Structures
 

structs, enums, classes, and functions are not control structures, so the 
opening brace should be at the appropriate indentation level on a line of its 
own. 

Dave Hylands 

- Original Message -

> From: "Birunthan Mohanathas" 
> To: "dev-platform" 
> Sent: Sunday, May 18, 2014 4:21:52 AM
> Subject: Gecko style: Braces with enums and uninons

> While working on bug 995730, I bumped into a few things that the Gecko
> style guide leaves unspecified. I have described one such case below.
> I'll create separate threads for the other things in order to maximize
> the number of bikeshedding threads (and for readability).

> For classes and structs, braces are placed like so:

> class Foo
> {
> // ...
> };

> How should they be placed for enums and unions? What about with
> anonymous enums and unions?
> ___
> 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: Gecko style: Formatting function return type and specifiers

[Dave Hylands]

I've seen both styles used, although I think that 

int Foo(); 

is the most common style when declaring a function prototype in a class header. 

Generally speaking its more important to be consistent with the rest of the 
file. 

Dave Hylands 

- Original Message -

> From: "Birunthan Mohanathas" 
> To: "dev-platform" 
> Sent: Sunday, May 18, 2014 4:27:07 AM
> Subject: Gecko style: Formatting function return type and specifiers

> For top-level function definitions, the recommended style is:

> template
> static inline T
> Foo()
> {
> // ...
> }

> However, for function declarations and inline member functions, there
> does not seem to be a definitive style. Some use:

> int Foo();

> class Bar
> {
> virtual int Baz()
> {
> // ...
> }
> };

> ... and others use:

> int
> Foo();

> class Bar
> {
> virtual int
> Baz()
> {
> // ...
> }
> };

> Which one should be preferred?
> ___
> 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: Gecko style: Formatting function return type and specifiers

[Karl Tomlinson]

Birunthan Mohanathas writes:

> For top-level function definitions, the recommended style is:
>
> template
> static inline T
> Foo()
> {
>   // ...
> }

The main reasons for having the function name at the start of a
new line, I assume, was to help some tools (including diff) that
look there for function names.

> However, for function declarations and inline member functions, there
> does not seem to be a definitive style.

For indented declarations within a class, AFAIK the only reason
for a line break would be if there is a limit on the number of
characters in a line.  (diff and other tools are not going to
find the function name anyway.)  Then it comes down to judgement
re whether to split the line before the function name, or between
parameters, etc.

If there are no parameters, then there is usually no need to break
the line.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OMTC on Windows

[avihal]

On Monday, May 19, 2014 4:36:49 AM UTC+3, Boris Zbarsky wrote:
> On 5/18/14, 2:23 PM, Gavin Sharp wrote:
> 
> > OMTC is important, and I'm excited to see it land
> 
> > on Windows, but the Firefox and Performance teams have just come off a
> 
> > months-long effort to make significant wins in TART, and the thought
> 
> > of taking a 20% regression (huge compared to some of the improvements
> 
> > we fought for) is pretty disheartening.
> 
> 
> 
> My question here is whether we have data that indicates why there is a 
> 
> regression.  Are we painting more, or are we waiting on things more?
> 
> 
> 
> In particular, if I understand correctly TART uses a somewhat bizarre 
> 
> configuration: it tries to run refresh drivers at 10,000 frames per 
> 
> second (yes, 10kHz).  That may not going interact at all well with 
> 
> compositing at 60Hz, and I'm not even sure how well it'll interact with 
> 
> the work to trigger the refresh driver off vsync.
> 
> 
> 
> In any case, it's entirely possible to get regressions on TART that have 
> 
> nothing to do with actual slowdowns at normal frame rates.  That may not 
> 
> be the case here, but it's a distinct possibility that it is.  For 
> 
> example, on Mac we ended up special-casing the TART configuration and 
> 
> doing non-blocking buffer swaps in it (see bug 99) precisely because 
> 
> otherwise TART ended up gated on things other than actual rendering 
> 
> time.  I would not be terribly surprised if something like that needs to 
> 
> be done on Windows too...
> 
> 
> 
> -Boris

It's not really 10K. It just means that the refresh driver sets the timeout to 
its next iteration as 0 or 1 ms, instead of aiming at 16-17 ms intervals. On OS 
X it indeed also includes non-blocking swap, and on windows - I don't know.

We call it ASAP mode, and it's used on several tests (tscrollx, tsvgx, TART, 
CART). Since we started using it, those tests became much more sensitive and 
much better in detecting perf changes, with very few false positives, if at all.

But ASAP is not that weird. Except for the non-blocking swap, the refresh 
driver can set its intervals to 0-1 ms also under normal conditions - when the 
load is high. In ASAP mode we explicitly induce this state even when the load 
is low.

Without this mode, those tests would (and have) just flatline around 16.7 ms, 
thus not detecting regressions (or improvements) and in practice quite useless.

Sure, it's different than "normal" mode, and possibly changes some internal 
balances into less than optimal ones, but overall, for measuring rendering 
throughputs (and changes of those), we don't have a better tool right now, and 
it has proved useful and reliable.

Its problem, however, is that the numbers we measure with OMTC are not 
necessarily comparable to the numbers without OMTC. As long as it's without 
OMTC - it's reliable, and as long as it's with OMTC it's also reliable (bug 
946567). But the perf changes which we measure on the switch itself might not 
be reliable, if only for the fact that defining "throughput" is not easy on 
OMTC.

The gfx/layout guys are aware of these factors, and we occasionally try to 
check if we could come up with something better than ASAP mode, but so far 
there isn't something better which we're aware of.

As I mentioned earlier, for this kind of switch, it would help to use few real 
machines with different human eyes looking at them and assessing if there's an 
observable difference.

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