Re: All the processes

[Ben Kelly]

On Fri, Mar 3, 2017 at 7:15 PM, Nicholas Nethercote 
wrote:

> Do I have any of these details wrong? Have I missed any?
>

We plan to ship a "worker" process that will run ServiceWorker (and
eventually SharedWorker) threads as part of:

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

In the future we may optionally schedule workers in other content
processes, but we are aiming for a separate process to start for a couple
reasons.  It ensures we have no accidental dependencies on running in the
same process as the content page.  It also helps us work around perf issues
with many operations requiring the main thread which is often busy during
page load in content processes.

I also think it would be worth investigating a separate process for the
network stack:

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

I don't think anyone is working on that, though.

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

Re: All the processes

[Andrew McCreight]

On Fri, Mar 3, 2017 at 4:15 PM, Nicholas Nethercote 
wrote:

> Hi,
>
> I want to understand all the different processes that we can and will have
> in Firefox. Here's a list I constructed off the top of my head.
>
> - main process
>
> - content process(es): 1 on release for most users; 2 on Nightly
>
> - plugin process: just for Flash now?
>
> - gfx compositor process (bug 1264543, in Fx53)
>

I think this is generally referred to as the "GPU process". One relevant
detail is that I believe it is Windows-only right now.


>
> - file:// URL access process (bug 1147911, in Fx53)
>
> IIRC there was a proposal for a thumbnail generation process a while back
> but judging by bug 1187441 that was scrapped.
>

I think in non-e10s a content process is used for thumbnail generation, but
it is run in the regular content process in e10s.


>
> Do I have any of these details wrong? Have I missed any?
>
> Thanks.
>
> Nick
> ___
> 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: All the processes

[Kris Maglione]

On Sat, Mar 04, 2017 at 11:15:29AM +1100, Nicholas Nethercote wrote:

Hi,

I want to understand all the different processes that we can and will have
in Firefox. Here's a list I constructed off the top of my head.

- main process

- content process(es): 1 on release for most users; 2 on Nightly

- plugin process: just for Flash now?

- gfx compositor process (bug 1264543, in Fx53)

- file:// URL access process (bug 1147911, in Fx53)


- Extension process (1 for now, possibly more in the future)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

All the processes

[Nicholas Nethercote]

Hi,

I want to understand all the different processes that we can and will have
in Firefox. Here's a list I constructed off the top of my head.

- main process

- content process(es): 1 on release for most users; 2 on Nightly

- plugin process: just for Flash now?

- gfx compositor process (bug 1264543, in Fx53)

- file:// URL access process (bug 1147911, in Fx53)

IIRC there was a proposal for a thumbnail generation process a while back
but judging by bug 1187441 that was scrapped.

Do I have any of these details wrong? Have I missed any?

Thanks.

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

Re: Intent to ship: WebVR on Windows in Release

[Ehsan Akhgari]

On Fri, Mar 3, 2017 at 12:36 PM,  wrote:

> Hi Ehsan!
>
> I believe all IPC messages can be changed to async except GetSensorState
> and SubmitFrame.  We cache the results from GetSensorState and re-use it
> until the next frame.
>

Hmm, not sure if I understand correctly.  Did you actually mean "except"
there?  If we can't guarantee to be able to return the result of
GetSensorState in the same frame as when it was requested in (which is the
case on Nightly right now), caching it for the rest of the frame duration
should be the least of our worries...


> I would like to do some changes to how IPC in WebVR works...
>
> First, I'd like to move the parent side of PVRManager to its own thread or
> possibly a dedicated process.  WebVR can be impacted by busy message
> queues.  PVRManager is already a top-level protocol and the methods on the
> parent side are self contained in preparation for this.
>

You probably want PBackground for this purpose, although if you're planning
to communicate with the background parent actor synchronously that may not
end up being good enough either.  A separate process sounds overkill, and
probably opens the door to solving more problems that you can probably
avoid solving (such as dealing with the additional memory usage of a helper
process.)


> Secondly, we may benefit from using another IPC mechanism for sharing
> per-frame state, which is updating at 90hz and broadcasting the same
> information to multiple children.  A fundamental difference with WebVR is
> that children are interested in getting the latest state rather than state
> in a serial fashion.  A carefully fenced or double buffered structure (like
> Chromium's gamepad IPC) may provide the low latency, nom-blocking IPC here.
>

Is this something we can use shared memory for?  Or would the cost of
locking access to the shared memory undo the benefits?


> For the near-term, I would like to make sure all messages that occur
> outside of WebVR presentation


Sorry, I'm not familiar with all of the terminology here.  Which messages
are those, and what parts of WebVR would still use synchronous IPC
communication with your suggestion?


> (ie GetDisplays) are async first, then work on a different IPC mechanism
> and move WebVR's messages into another parent thread / queue..  Would this
> make sense?
>

My first suggestion is to gather some profiles of some WebVR test runs to
get a better sense of what the current situation looks like.   Still it
seems to me that we shouldn't have any sync IPC on the path of the DOM APIs
that are exposed to the page.

Cheers,
Ehsan


> Thanks for the feedback!
>
> Cheers,
>   - Kip
>
> > On Mar 3, 2017, at 6:47 AM, Ehsan Akhgari 
> wrote:
> >
> > Hi Kearwood,
> >
> > I and a few other engineers have been studying the performance of
> > Firefox for several weeks now as part of the Quantum Flow project and
> > one of the serious performance issues that we have been finding in
> > various parts of the browser have been synchronous IPC messages sent
> > from the content process to the parent process.  We are tracking the
> > overall issue in bug 1331674, and I had seen WebVR sync IPC messages
> > come up in our measurements as being particularly bad but unfortunately
> > I hadn't gotten a chance to file a bug yet because I didn't realize
> > WebVR is close to being shipped, so sorry for the last minute alarm, but
> > what is our performance story for WebVR?  We have some telemetry probe
> > that suggest that some of the DOM APIs that we expose can potentially
> > blow away your entire frame budget.  For example,
> > PVRManager::Msg_GetSensorState (which, as far as I can tell is how we
> > implement VRDisplay.getFrameData() and VRDisplay.getPose()) is one of
> > the slowest ones.  On Nightly, more than 50% of the calls to this
> > synchronous IPC take between 8 to 20ms.  This means calling one WebVR
> > API currently can run the risk of blowing away your entire frame budget.
> > I have filed bug 1344216 for this.
> >
> > I don't have any VR hardware myself so I have done no profiling myself,
> > but what is our performance story here?  I think the current
> > implementation strategy of sending synchronous messages to the parent
> > process isn't going to be viable long term, and honestly it seems to me
> > that for WebVR specifically it may not even be good enough for a first
> > implementation.  Do you have some Gecko Profiler profiles to share,
> > ideally from lower end hardware that can run VR demos so that we can get
> > a sense of what the performance of Gecko on a VR workload looks like?
> > Has there been though of other implementation strategies?
> >
> > (FWIW it has recently became quite clear that sync IPC messages can be
> > *much* worse than sync IO even, we have seen many profiles where sync
> > IPC messages can easily take *seconds*, so even if they show up as super
> > fast on a fast machine when the machine isn't under load, 

Re: ANN: Default bug view for BMO changed today!

[Jörg Knobloch]

On 03/03/2017 12:10, Gervase Markham wrote:

Or if you just want to see it, mouse over and read the tooltip.
The requirement explicitly stated was: I'd also like to see the full 
date and hour in a *copyable* form.


I raised some usability issues in bug 1344233 as requested.

Jörg.


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

Re: Intent to ship: WebVR on Windows in Release

[Ehsan Akhgari]

Hi Kearwood,

I and a few other engineers have been studying the performance of
Firefox for several weeks now as part of the Quantum Flow project and
one of the serious performance issues that we have been finding in
various parts of the browser have been synchronous IPC messages sent
from the content process to the parent process.  We are tracking the
overall issue in bug 1331674, and I had seen WebVR sync IPC messages
come up in our measurements as being particularly bad but unfortunately
I hadn't gotten a chance to file a bug yet because I didn't realize
WebVR is close to being shipped, so sorry for the last minute alarm, but
what is our performance story for WebVR?  We have some telemetry probe
that suggest that some of the DOM APIs that we expose can potentially
blow away your entire frame budget.  For example,
PVRManager::Msg_GetSensorState (which, as far as I can tell is how we
implement VRDisplay.getFrameData() and VRDisplay.getPose()) is one of
the slowest ones.  On Nightly, more than 50% of the calls to this
synchronous IPC take between 8 to 20ms.  This means calling one WebVR
API currently can run the risk of blowing away your entire frame budget.
 I have filed bug 1344216 for this.

I don't have any VR hardware myself so I have done no profiling myself,
but what is our performance story here?  I think the current
implementation strategy of sending synchronous messages to the parent
process isn't going to be viable long term, and honestly it seems to me
that for WebVR specifically it may not even be good enough for a first
implementation.  Do you have some Gecko Profiler profiles to share,
ideally from lower end hardware that can run VR demos so that we can get
a sense of what the performance of Gecko on a VR workload looks like?
Has there been though of other implementation strategies?

(FWIW it has recently became quite clear that sync IPC messages can be
*much* worse than sync IO even, we have seen many profiles where sync
IPC messages can easily take *seconds*, so even if they show up as super
fast on a fast machine when the machine isn't under load, they can
essentially take an arbitrary long amount of time in less ideal cases...
 I myself have certainly been guilty of adding a fair number of sync IPC
messages before measuring how bad they are in practice.)

Thanks,
Ehsan

On 2017-03-01 3:50 PM, kgilb...@mozilla.com wrote:
> As of March 1, 2017 I intend to turn WebVR on by default on Windows.  It has 
> been developed behind the dom.vr.enabled preference and has been enabled by 
> default on Firefox Nightly and Dev Edition since November 2015.  Other UAs 
> shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel.  
> Microsoft Edge and Google Chrome are also intending to ship.  Google Chrome 
> has enabled WebVR on Android with an Origin Trial.
> 
> This feature was previously discussed in this "intent to ship" thread, for 
> non-release builds:
>  
> https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion
>  
> Bug to turn on by default:
>  
> https://bugzilla.mozilla.org/show_bug.cgi?id=1343368
>  
> We will support Oculus and HTC Vive by default.  Oculus is already enabled; 
> HTC Vive support with OpenVR has been developed behind the 
> “dom.vr.openvr.enabled” preference and will be turned on with this bug:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1343374
> 
> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/
> 
> Since the initial implementation, a W3C working group was formed including 
> members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has 
> stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is 
> being conceived.
>  
> Windows only support for WebVR would be enabled by default in Firefox 54.  
> OSX is not yet supported by current VR headsets.  Beta Linux support for HTC 
> Vive has very recently landed, and will be supported by Firefox after the 
> Firefox 54 uplift.
> 
> Cheers,
> Kearwood “Kip” Gilbert
> :kip
> 
> ___
> 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: ANN: Default bug view for BMO changed today!

[Honza Bambas]

Few questions:

- Are there any plans on a higher contrast version of the new UI? 
Honestly, having titles overs comments light gray on a light gray 
background is at least pretty sad.  Also citations are again gray making 
navigation among comments pretty hard just making my eyes more tired.


- How long will the other old themes be around?  Specifically Dusk, 
which I've been using for nearly 10 years.  With Dusk it's way easier to 
distinct sections (status and flags/attachments/comments, specially the 
first one) each from another than in the new UI.  I'd like to keep Dusk 
for few more years ahead for old dogs like me if the new UI doesn't improve.


Thanks

-hb-

On 01/03/2017 21:47, David Lawrence wrote:

Today, the BMO Team changed the default bug view to the new modal
view that has been in development for a while. For those who would like
to use the old form, instructions on how to switch back are below in the
background information. The old form will, however, be removed one day,
so please try to use the new one and make suggestions on how it can be
improved.

 As some of you may already know, and maybe even have been using it
for a while, the BMO [1] team has been working on a new bug view page
(a.k.a. show_bug.cgi) for some time [2] . The older, stock bug form was
not well laid out and was difficult to understand, with all of the
fields visible regardless of how often they were used. The stock form
was originally designed to  display all of a bug’s data, and users had
to adapt their workflows accordingly. The BMO team designed a completely
new and more efficient view for the workflows of the majority of BMO users.

 The new bug-editing form has been added to BMO alongside the stock
form and can be enabled by toggling a user preference [3]. We have been
incrementally improving it and collecting feedback by those brave enough
to use it early on. The new form is using more modern design practices
and therefore is easier for us to improve and expand on. Any new
enhancements will be done only on the new form going forward. It was
code named ‘Bug Modal’ due to the modular layout of the page. Each
submodule can be collapsed out of view and expanded when needed.

 At this time we feel that the form is feature complete and has now
become the new default bug form for BMO. We have finished all the
blockers in our tracking bug report [4]. The older, stock bug view form
will still be around, and you can use the user preferences form to
switch back to the old one [3]. In the future, we will be removing the
old form completely after fixing a few more bugs [6], and we will make
another announcement before doing so. Removing the old code will make it
easier on us from a maintenance standpoint. Any bugs, comments, or ideas
for improvement of the modal form can be reported in BMO [5].

Thanks!
BMO Team

[1] https://bugzilla.mozilla.org
[2] https://globau.wordpress.com/2015/03/31/bmo-new-look
[3]
https://bugzilla.mozilla.org/userprefs.cgi?tab=settings#ui_experiments_row
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1150541
[5]
https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org=User%20Interface:%20Modal=__default__
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1273046
___
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

Fwd: CodeCoverage: First Monthly Update

[Kyle Lahnakoski]

It was pointed out that my email address did not have enough "L"s in
it.  Here is my real email address:

klahnako...@mozilla.org



 Forwarded Message 
Subject:CodeCoverage: First Monthly Update
Date:   Thu, 2 Mar 2017 21:29:10 -0500
From:   Kyle Lahnakoski 
To: dev-platform@lists.mozilla.org




It is my pleasure to introduce you all to our project to collect code
coverage!


Motivation

Knowing code coverage statistics and code coverage specifics can help
evaluate risk in code: It can show what test suites cover what lines, it
can show if new code is covered by an existing test.  There are many
other exciting insights we can extract from code coverage. But first, we
must collect it.

The Problem

The biggest problem we face is scale:  Firefox has many LoC, it is
composed of multiple languages, it is run on multiple platforms, and the
test suites are split among hundreds of machines for a single build.

History

For just over a year, this CodeCoverage project has had number of
excellent contributors from various Universities across Canada[1].  They
did the exploratory work required to solve the problems of scaling
collection and aggregation so to handle the Mozilla-scale problem with
code coverage.  If any of those contributors are reading this: Thank you!

The Plan

For the next month we will be working on c++ coverage, Rust coverage and
validating the data and process.  There are many unknowns and I will
have more concrete deliverables in the next update.  The details of that
plan is in our freshly minted planning document [2].  There you can find
bugs, and code links.  If you are interested in more, please contact me [3]

I will send out monthly emails with our progress, some links where you
see our progress, and our future plans.


[1] UCOSP (Undergraduate Capstone Open Source Projects)http://ucosp.ca/

[2] The actual plan:
https://docs.google.com/document/d/1dOWi18qrudwaOThNAYoCMS3e9LzhxGUiMLLrQ_WVR9w/edit#

[3] Kyle Lahnakoski email: klahnako...@mozilla.org  irc: ekyle on
#at...@irc.mozilla.org

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

Re: ANN: Default bug view for BMO changed today!

[Gervase Markham]

On 02/03/17 17:11, Byron Jones wrote:
> set "Use absolute format instead of relative time when viewing a bug"

Or if you just want to see it, mouse over and read the tooltip.

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