Re: All the processes
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
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
On 3/3/2017 4:15 PM, Nicholas Nethercote wrote: - plugin process: just for Flash now? On 32-bit Windows, there are multiple plugin processes because Firefox runs Flash in a plugin process and then Flash spawns one (or more?) of its own "Protected Mode" processes. IIUC, the Protected Mode processes are locked down tighter and broker file access/etc through the main plugin process. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: All the processes
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
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
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, they can > > essentially take an arbitrary long amo
Re: ANN: Default bug view for BMO changed today!
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
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!
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&component=User%20Interface:%20Modal&format=__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
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!
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