PSA: If you're trying to run Nightly with WebRender enabled, you will have to change some preferences...

[Milan Sreckovic]

As of the latest nightly, you just need gfx.webrender.all set to true.  
You can leave the other preferences ( gfx.webrender.enabled, 
gfx.webrender.blob-images, image.mem.shared, 
layers.acceleration.force-enabled, which are still meaningfull for 
developers) as default.


--
- Milan (mi...@mozilla.com)

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

Re: Visual Studio 2017 coming soon

[Milan Sreckovic]

Are we locked into using the same compiler for the ESR updates?  In 
other words, do we need to keep VS2015 for ESR52 builds until they are 
not needed anymore?


On 26-Oct-17 3:31, Sylvestre Ledru wrote:

Hello,


On 25/10/2017 23:48, David Major wrote:

I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
1408789.


In which version are you planning to land this change?
As we are close to the end of the 58 cycle in nightly, it would be great
to wait for 59.

Thanks,
Sylvestre

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


--
- Milan (mi...@mozilla.com)

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

Creating a content process during shutdown...

[Milan Sreckovic]

I've spoken to some of you about this, but at this point need a larger 
audience to make sure we're covering all the bases.


Do we have code in Firefox that would cause us to create a new content 
process, after we've entered shutdown?


I understand the possibility of user action that would create a new 
content process followed quickly by one that would cause shutdown, and 
the timing making it so that the new content process initialization can 
then happen out of order, but I'm more asking about the explicit scenario.


Thanks!

--
- Milan (mi...@mozilla.com)

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

Re: Keyboard APZ has landed on Inbound

[Milan Sreckovic]

In this context, we don't have the numbers for keyboard APZ; we do know 
that 14% of the page loads (last time we did a telemetry measurement) 
had non-passive event listeners.



On 23-Jul-17 22:05, Ryan Hunt wrote:

We will not do keyboard APZ, even if the event listener is marked passive.

Passive only restricts the use of preventDefault, and we also care about whether
the event listener changes the focus or selection of a page.

An example where this matters would be a page with a key listener that sets the
focus of the page to a . If the user were to hit space twice, they 
would
expect the first space to scroll the page, and the second to be input into the
.

With keyboard APZ enabled we can't guarantee that to happen, as the focus
of the page can't be guaranteed to sync to APZ in time for us to know not to
scroll the root scroll frame again.

It's not clear whether this is behaviour that is widely relied on. We're 
attempting
to be conservative in the cases we allow this.

Let me know if the example is unclear.

Thanks,
Ryan


From: Ben Kelly 
Sent: Sunday, July 23, 2017 12:26 PM
To: Ryan Hunt
Cc: dev-platform@lists.mozilla.org
Subject: Re: Keyboard APZ has landed on Inbound

On Sat, Jul 22, 2017 at 2:05 AM, Ryan Hunt 
mailto:rh...@eqrion.net>> wrote:
Keyboard APZ can't be used in every case. Currently it's disabled in the
presense of key event listeners, as they can preventDefault scrolling and that
is a non-negotiable part of the web.

Do we do keyboard APZ if the event listener is passive:true?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


--
- Milan (mi...@mozilla.com)

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

Re: Phabricator Update, July 2017

[Milan Sreckovic]

Replying in general, to a random message :)

I don't have the numbers, but I imagine reviews are happening in the 
hundreds every day (if we land almost 300 patches.)  So, I wouldn't 
expect the conversation about adding/removing/changing tools involved in 
reviews to be any less complicated, passionate and involved as what 
we're having here :)


I believe Mark is putting together an e-mail to give us a better place 
to continue these conversations; something with meta bugs for "enable 
phabricator", "disable splinter", etc.  This should let us track the 
issues that are raised, discuss decisions as to which of those should be 
blockers, and have a better record of what actually gets resolved and how.


This should leave us *just* with the decision making and communication 
rollout issues that were raised; I know we are continuously discussing 
those and trying to get better at it, but it is a separate conversation 
from the technical issues, so it's probably OK that it remains separate.



On 13-Jul-17 15:41, Randell Jesup wrote:

To answer the other part of your question, MozReview will be disabled for
active use across the board, but it is currently used by a small number of
projects.  Splinter will be disabled on a per-product basis, as there may be
some projects that can't, won't, or shouldn't be migrated to Phabricator.

Splinter is still a nice UI to look at patches already attached to bugs.
Please don't disable it.

excellent point; thanks for that feedback.

instead of disabling splinter for phabricator backed products, we could
make it a read-only patch viewer.

I would consider it a massive fail if we disabled at least read-only
splinter viewing of patches.  As noted before.  let's make sure we
don't lose things we agreed on as issues.



--
- Milan (mi...@mozilla.com)

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

Re: Phabricator Update, July 2017

[Milan Sreckovic]

Perfect, love it.

One thing that hasn't been explicitly mentioned, and I hope switching to 
phabricator would fix it (though it does sounds like an orthogonal 
issue) - the patches that are attached to bugzilla are often not the 
ones that actually landed, because last minute changes were made and 
landed manually.  Will that get better with phabricator?


On 12-Jul-17 11:54, Byron Jones wrote:


Consider that we are talking about "turning off" mozreview now.  Will 
all
the bugzilla links to those reviews go dead?  Or do we have to 
maintain a

second service in read-only mode forever?


the patches will be archived in some form.

how this looks is yet to be fully fleshed out - ideas currently 
include archiving and updating bugzilla to point to their new location 
(eg. s3), or uploading patches directly to bugzilla.




--
- Milan (mi...@mozilla.com)

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

Re: Phabricator Update, July 2017

[Milan Sreckovic]

On 12-Jul-17 11:27, Byron Jones wrote:


...
But indeed having also the patches in bugzilla would be good. 
no, it would be bad for patches to be duplicated into bugzilla. we're 
moving from bugzilla/mozreview to phabricator for code review, 
duplicating phabricate reviews back into the old systems seems like a 
step backwards (and i'm not even sure what the value is of doing so).


I believe the answer to this depends on the answer to the "what happens 
to mozreview patches" after we switch to phabricator.  If the answer was 
to be "you lose all of those", then the argument could be "we don't want 
to lose the patches once we switch from phabricator to product X in 20 
years".


--
- Milan (mi...@mozilla.com)

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

Re: Switching to per-channel profiles

[Milan Sreckovic]

I don't know how common this workflow is for others, but I do find I 
often need to use release/beta to "fix" experimental preferences when 
things go wrong.  For features that are behind a preference, in nightly, 
if I set the preference, which leads to a start up crash, the easiest 
way to reset it is to run the release on the same profile, reset the 
preferences to the default, then run nightly again.


Fairly specialized case, I agree.

On a sync note, I'm not sure if I understood the conversation correctly, 
but as long as I can run the same sync account on different machines, 
with different versions of Firefox, I'm good.



On 23-Jun-17 18:43, Dave Townsend wrote:

Does anyone think we shouldn't do this or have comments on my proposal for
implementing it?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


--
- Milan (mi...@mozilla.com)

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

Re: Quantum Flow Engineering Newsletter #5

[Milan Sreckovic]

I will repeat what I said earlier, and I should know, because I'm 
running Quantum Render.  There was never a suggestion that Photon should 
be waiting for Quantum Render, or a WebRender subset of it.  The 
graphics team has been monitoring the Photon plans to see if something 
surprising is coming up.


And there are no regressions with Quantum Render; the users that are not 
qualified for the WebRender path in Quantum Render will get something 
that's at worst as good as what they have today.


As far as the order of operations goes - I actually prefer what's 
happening today, with Photon showing up before, or at the same time as 
Quantum Render.  Jack and I just happen to disagree on that point.



On 18-Apr-17 13:53, Justin Dolske wrote:

On Tue, Apr 18, 2017 at 1:19 AM, Jack Moffitt  wrote:


Another really nice effort that is starting to unfold and I'm super

excited

about is the new Photon performance project
, which is a

focused

effort on the front-end performance.  This includes everything from
engineering the new UI with things like animations running on the
compositor in mind from the get-go, being laser focused on guaranteeing
good performance on key UI interactions such as tab opening and closing,
and lots of focused measurements and fixes to the browser front-end.

I think the order of operations here is unfortunate. What we'd prefer
is that WebRender land first, and then Photon be designed around what
is possible in the GPU-backed world.


That's a complete non-starter. Photon work is already underway, and there's
a _ton_ of work to do for the 57 release.

Blocking Photon on another major project landing first would mean canceling
Photon for 57.

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


--
- Milan (mi...@mozilla.com)

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

Re: Quantum Flow Engineering Newsletter #5

[Milan Sreckovic]

Jack are you speaking in the context of Servo?

From the Quantum Render (Gecko with the WebRender evolution we're 
working on) point of view, Proton should not count on anything getting 
better.  In other words, design for Firefox 55 and assume things will 
not get worse.  If you need them to get better, come talk to the 
graphics team.  There are currently no such requirements I'm aware of, 
specifically tied to the Proton work.


So, I don't see the order of operations being an issue, but I could be 
missing something Jack knows of.



On 18-Apr-17 9:58, Eric Rescorla wrote:

On Tue, Apr 18, 2017 at 4:19 AM, Jack Moffitt  wrote:


Another really nice effort that is starting to unfold and I'm super

excited

about is the new Photon performance project
, which is a

focused

effort on the front-end performance.  This includes everything from
engineering the new UI with things like animations running on the
compositor in mind from the get-go, being laser focused on guaranteeing
good performance on key UI interactions such as tab opening and closing,
and lots of focused measurements and fixes to the browser front-end.

I think the order of operations here is unfortunate. What we'd prefer
is that WebRender land first, and then Photon be designed around what
is possible in the GPU-backed world.


When will that landing be? How much time will that leave for designing
photon?

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


--
- Milan (mi...@mozilla.com)

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

Re: Project Stockwell (reducing intermittents) - March 2017 update

[Milan Sreckovic]

Not a reply to this message, just continuing the thread.

I'd like to see us run all the intermittently disabled tests once a ... 
week, say, or at some non-zero frequency, and automatically re-enable 
the tests that magically get better.  I have a feeling that some 
intermittent failures get fixed without us realizing it (e.g., we reduce 
memory usage, so OOMs go away, we speed things up so timeouts stop 
triggering) and it would be good to be able to re-enable those tests 
that start passing.


It'd make me feel slightly less sad that we're disabling tests that do 
their job 90% of the time...



On 09-Mar-17 14:04, jma...@mozilla.com wrote:

A lot of great discussion here, thanks everyone for taking some time out of 
your day to weigh in on this subject.  There are slight differences between a 
bug being filed and actively working on the bug once it crosses our threshold 
of 30 failures/week- I want to discuss when we have looked at the bug and have 
tried to add context/value, including a ni? request.

Let me comment on a few items here:
1) BUG_COMPONENT, I have been working this quarter to get this completed 
in-tree (https://bugzilla.mozilla.org/show_bug.cgi?id=1328351 ).  Ideally the 
sheriffs and Bug Filer tools will use this, we can work to fix that.  Part of 
this is ensuring there is an active triager responsible for those components, 
that is mostly done: 
https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html.

2) how do we get the right people to see the bugs?  We will always ni? the 
triage owner unless we know a better person to send a ni? request to.  In many 
cases we determine a specific patch causes a regression, we will also include 
the patch author with a ni? and reviewer as a cc on the bug in those cases.  
Please watch your components in bugzilla and keep your bugzilla handle updated 
with PTO.

3) to the point of not clearing the ni? on a bug where we disable the test 
case, that is easy to do, lets assume that is standard protocol if we are 
disabling a test (or hacking up the test case)

4) more granular whiteboard tags, and ones that don't use stockwell.  We will 
figure out the right naming, right now it most likely will be extra tags to 
track when we fixed a disabled test as well as differentiating between test 
fixes and product fixes.

5) When we triage a bug (initial investigation after crossing 30 failures/week), we 
will include a brief report of the configuration affected the most along with the 
number of failures, number of runs, and the percentage failure.  This will be 
retrieved by using |mach test-info | (bug 1345572 for more info) and will 
look similar to this:
Total: 307 failures in 4313 runs or 0.071 failures/run
Worst rate on linux32/debug-e10s: 73 failures in 119 runs or 0.613 failures/run

6) using a different metric/threshold for investigating a bug.  We looked at 6 
months of data from 2016 to come up with this number.  Assuming we fixed all of 
the bugs that are high frequency, Orange Factor would still be 4.78 (as of 
Monday) which is still unacceptable, we are only interested in investigating 
tests that have the highest chance of getting fixed or cause the most pain, not 
just whatever is top 10 or relatively high.  My goal is to adjust the threshold 
down to 20 in the future- that might not be as realistic as I would hope in the 
short term.

Keep in mind sheriffs are human, they make mistakes (filing bugs wrong, ni? the 
wrong person, etc.) but they are also flexible and will work with you to help 
get more information or help manage a larger volume of failures and allowing 
extra time if you are actively debugging the problem.

Thanks for the many encouraging comments in this thread and suggestions of how 
to work out the quirks with this new process.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


--
- Milan (mi...@mozilla.com)

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

Re: Doxygen output?

[Milan Sreckovic]

Not being kept up to date as far as I know.  My extraction is four years 
out of date (e.g., 
https://people-mozilla.org/~msreckovic/Extracted/MozillaCentral/html/annotated.html) 
and as you noted, Benoit's page is no longer.


The code used to create it is here: 
https://github.com/bgirard/doxygen-mozilla



On 20-Feb-17 2:05, Henri Sivonen wrote:

Our comments mostly try to follow the Doxygen format, and MDN says
that the documentation team has a tool for importing Doxygen-formatted
IDL comments into MDN articles.

Other than that, is Doxygen output from m-c input being published anywhere?

https://people-mozilla.org/~bgirard/doxygen/gfx/ is 404 these days.



--
- Milan (mi...@mozilla.com)

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

Re: Changing the representation of rectangles in platform code

[Milan Sreckovic]

First step needs to happen completely before the second step does, so I 
guess the danger is that we start and give up before we get to step 2.  
I don't think that will happen, but it is something we should always 
think about.


Third step - sure, I can see this not getting completed - examining 
places that do xmax = xmin + width instead of just getting the max X, 
for example.


On 09-Feb-17 20:56, Nicholas Nethercote wrote:

My concern is that  this will get partially done but never completed, and
we'll end up in a situation where we have two styles in place. We have a
bad track record with that sort of thing.

Nick

On Thu, Feb 9, 2017 at 1:45 PM, Jeff Muizelaar  wrote:


It's not very easy to reason about overflow issues with our current
representation. This means that we currently just pretend that they
don't happen. The idea for changing the representation came up in
response to a security bug where we didn't really have a better
solution.

Changing to x1, x2, y1, y2 will allow us to match the pixman rectangle
representation that we use for regions. The region code shows quite a
bit profiles so even a small improvement in this area is nice to have.

-Jeff

On Wed, Feb 8, 2017 at 9:19 PM, David Major  wrote:

Is there a specific problem that's being solved by this proposal? It

would

be helpful to make this a bit more concrete, like "these benchmarks go x%
faster", or "here's a list of overflow bugs that will just vanish", or
"here's some upcoming work that this would facilitate".

On Thu, Feb 9, 2017 at 1:56 PM, Botond Ballo  wrote:

Hi everyone!

I would like to propose changing the internal representation of
rectangles in platform code.

We currently represent a rectangle by storing the coordinates of its
top-left corner, its width, and its height. I'll refer to this
representation as "x/y/w/h".

I would like to propose storing instead the coordinates of the
top-left corner, and the coordinates of the bottom-right corner. I'll
refer to this representation as "x1/y1/x2/y2".

The x1/y1/x2/y2 representation has several advantages over x/y/w/h:

   - Several operations are more efficient with x1/y1/x2/y2, including
intersection,
 union, and point-in-rect.
   - The representation is more symmetric, since it stores two quantities
of the
 same kind (two points) rather than a point and a dimension
(width/height).
   - The representation is less susceptible to overflow. With x/y/w/h,
computation
 of x2/y2 can overflow for a large range of values of x/y and w/h.
However,
 with x1/y1/x2/y2, computation of w/h cannot overflow if the
coordinates are
 signed and the resulting w/h is unsigned.

A known disadvantage of x1/y1/x2/y2 is that translating the rectangle
requires translating both points, whereas translating x/y/w/h only
requires translating one point. I think this disadvantage is minor in
comparison to the above advantages.

The proposed change would affect the class mozilla::gfx::BaseRect, and
classes that derive from it (such as CSSRect, LayoutRect, etc., and,
notably, nsRect and nsIntRect), but NOT other rectangle classes like
DOMRect.

I would like to propose making the transition as follows:

   - Replace direct accesses to the 'width' and 'height' fields

throughout

 the codebase with calls to getter and setter methods. (There aren't
 that many - on the order of a few dozen, last I checked.)

   - Make the representation change, which is non-breaking now that
 the direct accesses to 'width' and 'height' have been removed.

   - Examine remaining calls to the getters and setters for width and
 height and see if any can be better expressed using operations
 on the points instead.

The Graphics team, which owns this code, is supportive of this change.
However, since this is a fundamental utility type that's used by a
variety of platform code, I would like to ask the wider platform
development community for feedback before proceeding. Please let me
know if you have any!

Thanks,
Botond

[1]
http://searchfox.org/mozilla-central/rev/672c83ed65da286b68be1d02799c35

fdd14d0134/gfx/2d/BaseRect.h#46

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



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


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


--
- Milan (mi...@mozilla.com)

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

Re: Disabling non-Skia builds

[Milan Sreckovic]

Right.  Good point to clarify.  We're not taking on the ownership of the 
patches that need to go upstream, and my original wording could be 
interpreted that way.  So, we can forward the patches to Skia, for 
example, but we'd be forwarding the whole conversation, that the patch 
author would then continue with Skia.  Once those patches are approved 
in Skia, we would consider landing them ahead of a full Skia update, to 
expedite things.  Effectively, we'd be cherry picking that particular 
change out of Skia.



On 14-Dec-16 10:41, George Wright wrote:

I'm 100% in support of this.

One thing I'd like to know though is how we're going to deal with 
upstreaming patches to Skia on behalf of third parties? In my 
experience, it's rarely been a case of simply submitting a patch and 
having it accepted; there's normally a decent amount of engineering 
effort required to make it acceptable to upstream. I think it would be 
nice to have some sort of plan figured out (even if it's "people 
submitting patches to us should probably consult upstream first") 
before we flip the kill switch here.



On 12/13/2016 4:39 PM, Milan Sreckovic wrote:
In https://bugzilla.mozilla.org/show_bug.cgi?id=1323303, we are going 
to disable the build configurations that let us leave Skia out. This 
will let us simplify the code, and make things cleaner, now that it 
is the only supported backend.  We will take patches to Gecko (or 
forward them if in Skia itself) that fix problems related to Tier 3 
platforms, although we don't anticipate anything coming in for SkiaGL.


--

- Milan

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


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


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

Disabling non-Skia builds

[Milan Sreckovic]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1323303, we are going to 
disable the build configurations that let us leave Skia out.  This will 
let us simplify the code, and make things cleaner, now that it is the 
only supported backend.  We will take patches to Gecko (or forward them 
if in Skia itself) that fix problems related to Tier 3 platforms, 
although we don't anticipate anything coming in for SkiaGL.


--

- Milan

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

Heads up on awesome change to socorro that will change crash stats...

[Milan Sreckovic]

The authors of the fix can explain in details what is going on, but since the 
users will experience (great, but new) results with currently processed crash 
reports, it was suggested I should mention it to a larger audience.

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


This is now live, which means that the new reports coming in are going to skip 
the DLLs without symbols, which means that, for example, driver crashes will 
start getting grouped together, and we will see what’s actually going on.

It also means we will start seeing the driver crashes that were processed 
before this change start dropping in frequency - probably a good idea not to 
dismiss them as “this got fixed somehow”, but instead look to see if they are 
now subsumed by a new, more awesome bug.

As an example tracked here https://bugzilla.mozilla.org/show_bug.cgi?id=1267970 
 - the crash went from 
411th to 19th (in 47) once all the different driver versions were aggregated 
and the DLLs without symbols were ignored.

And, yes, chances are we will see some over-grouping, but the worst case 
scenario is that we look at a crash that looks important, and turns out not to 
be, or that we only fix it partially, and then discover the lurkers.  Either 
way, much better scenario than not noticing problems because they’re scattered. 
—
- Milan



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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

For example, searching for “graphics critical error” containing 0x8007000e 
(Windows error code for “out of memory”) leads you to a lot of crashes/bugs 
that are not tagged as OOM (which is OK), but clearly have some aspect of 
“running out of stuff” in them.

In general, it can come in handy when the info is otherwise light (e.g., “ERROR 
NO MINIDUMP HEADER” ones :)
—
- Milan



> On Jun 2, 2016, at 13:17 , Milan Sreckovic  wrote:
> 
> If you want a treasure trove :), when it comes to graphics crashes, the 
> “graphics critical error” field is it.  It’s a recent history of barely 
> avoidable crashes and error states just before the crash actually happens.  
> Very often the real cause of the crash happens prior to the line of code 
> captured in the stack trace.
> 
> (It doesn’t necessarily make sense to search for the "graphics critical 
> error” existence, as too many bugs will show up, but for us it’s usually the 
> first step after we identify a crash to look at.)
> 
> - Milan
> 
> 
> 
>> On Jun 1, 2016, at 21:40 , Nicholas Nethercote  
>> wrote:
>> 
>> I apologize for the sarcasm. I was frustrated with this comment:
>> 
>>> I looked at the query from the first post, but it's just noise to me. If it 
>>> included the file that it
>>> crashed from, it would suddenly be very useful, since it'd then be trivial 
>>> to see if there's
>>> something relevant to me.
>> 
>> but it wasn't a good way to respond. So I'll try again.
>> 
>> Most of the results in the search identify a unique string, which *is*
>> trivial to look up. And while it's true that file and/or function
>> names would help refine the small number of cases where distinct
>> MOZ_CRASH calls, you can also do that with a simple follow-up search
>> refinement, as I showed in my previous response. The required data is
>> present. I would describe the presentation as "slightly suboptimal but
>> still highly usable".
>> 
>> I've looked at a lot of crash reports recently and one thing I've
>> learned is how inadequate they often are. Many are unactionable. Many
>> aren't even comprehensible. In comparison, this list is a treasure
>> trove, containing reports that are much more comprehensible and
>> actionable than average. It's one which I intend to revisit, and I
>> hope others will too.
>> 
>> Nick
>> 
>> 
>> On Thu, Jun 2, 2016 at 5:22 AM, Jeff Gilbert  wrote:
>>> It would be useful to have a dashboard that collates this information 
>>> better.
>>> 
>>> PS: Sarcasm is unhelpful.
>>> 
>>> On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote
>>>  wrote:
>>>> On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert  wrote:
>>>>> 
>>>>> Perhaps this isn't meant for me then? I looked at the query from the
>>>>> first post, but it's just noise to me. If it included the file that it
>>>>> crashed from, it would suddenly be very useful, since it'd then be
>>>>> trivial to see if there's something relevant to me.
>>>> 
>>>> Let's look at the top #3:
>>>> 
>>>> 
>>>> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
>>>> 129715  9.92 %
>>>> 
>>>> If you use your favourite source code search tool to look for
>>>> "Shutdown too long", you'll find that this crash is occurring in
>>>> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
>>>> DXR link:
>>>> 
>>>> https://dxr.mozilla.org/mozilla-central/search?q=%22Shutdown+too+long%22&redirect=false
>>>> 
>>>> The line in question looks like this:
>>>> 
>>>> MOZ_CRASH("Shutdown too long, probably frozen, causing a crash.");
>>>> 
>>>> 
>>>> 2  MOZ_CRASH() 25987   1.99 %
>>>> 
>>>> This one matches all calls to MOZ_CRASH() that don't provide a string
>>>> parameter. Digging into these ones is slightly harder, requiring a new
>>>> search for bugs that have "moz crash reason" set to "MOZ_CRASH()":
>>>> 
>>>> https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%3DMOZ_CRASH%28%29&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-signature
>>>> 
>>>> 
>>>> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor) 21040.16 %
>>>> 
>>>> Searching for "working D3D9 Compositor" identifies this one as coming
>>>> from gfx/layers/d3d9/CompositorD3D9.cpp.
>>>> 
>>>> 
>>>> And so on. Searching for strings in code is a useful technique in many
>>>> situations, I recommend it!
>>>> 
>>>> 
>>>> BTW, thank you to all those who have already looked through the list
>>>> and mentioned existing bugs and/or filed new bugs.
>>>> 
>>>> 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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

If you want a treasure trove :), when it comes to graphics crashes, the 
“graphics critical error” field is it.  It’s a recent history of barely 
avoidable crashes and error states just before the crash actually happens.  
Very often the real cause of the crash happens prior to the line of code 
captured in the stack trace.

(It doesn’t necessarily make sense to search for the "graphics critical error” 
existence, as too many bugs will show up, but for us it’s usually the first 
step after we identify a crash to look at.)

- Milan



> On Jun 1, 2016, at 21:40 , Nicholas Nethercote  wrote:
> 
> I apologize for the sarcasm. I was frustrated with this comment:
> 
>> I looked at the query from the first post, but it's just noise to me. If it 
>> included the file that it
>> crashed from, it would suddenly be very useful, since it'd then be trivial 
>> to see if there's
>> something relevant to me.
> 
> but it wasn't a good way to respond. So I'll try again.
> 
> Most of the results in the search identify a unique string, which *is*
> trivial to look up. And while it's true that file and/or function
> names would help refine the small number of cases where distinct
> MOZ_CRASH calls, you can also do that with a simple follow-up search
> refinement, as I showed in my previous response. The required data is
> present. I would describe the presentation as "slightly suboptimal but
> still highly usable".
> 
> I've looked at a lot of crash reports recently and one thing I've
> learned is how inadequate they often are. Many are unactionable. Many
> aren't even comprehensible. In comparison, this list is a treasure
> trove, containing reports that are much more comprehensible and
> actionable than average. It's one which I intend to revisit, and I
> hope others will too.
> 
> Nick
> 
> 
> On Thu, Jun 2, 2016 at 5:22 AM, Jeff Gilbert  wrote:
>> It would be useful to have a dashboard that collates this information better.
>> 
>> PS: Sarcasm is unhelpful.
>> 
>> On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote
>>  wrote:
>>> On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert  wrote:
 
 Perhaps this isn't meant for me then? I looked at the query from the
 first post, but it's just noise to me. If it included the file that it
 crashed from, it would suddenly be very useful, since it'd then be
 trivial to see if there's something relevant to me.
>>> 
>>> Let's look at the top #3:
>>> 
>>> 
>>> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
>>> 129715  9.92 %
>>> 
>>> If you use your favourite source code search tool to look for
>>> "Shutdown too long", you'll find that this crash is occurring in
>>> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
>>> DXR link:
>>> 
>>> https://dxr.mozilla.org/mozilla-central/search?q=%22Shutdown+too+long%22&redirect=false
>>> 
>>> The line in question looks like this:
>>> 
>>> MOZ_CRASH("Shutdown too long, probably frozen, causing a crash.");
>>> 
>>> 
>>> 2  MOZ_CRASH() 25987   1.99 %
>>> 
>>> This one matches all calls to MOZ_CRASH() that don't provide a string
>>> parameter. Digging into these ones is slightly harder, requiring a new
>>> search for bugs that have "moz crash reason" set to "MOZ_CRASH()":
>>> 
>>> https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%3DMOZ_CRASH%28%29&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-signature
>>> 
>>> 
>>> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor) 21040.16 %
>>> 
>>> Searching for "working D3D9 Compositor" identifies this one as coming
>>> from gfx/layers/d3d9/CompositorD3D9.cpp.
>>> 
>>> 
>>> And so on. Searching for strings in code is a useful technique in many
>>> situations, I recommend it!
>>> 
>>> 
>>> BTW, thank you to all those who have already looked through the list
>>> and mentioned existing bugs and/or filed new bugs.
>>> 
>>> 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: Intent to deprecate: MacOS 10.6-10.8 support

[Milan Sreckovic]

Perhaps we can exercise restraint on doing a wholesale removal of the <10.9 
code, as doing so could make uplifting to 48 and earlier more of a mess.  Maybe 
in a few weeks?
—
- Milan



> On May 31, 2016, at 11:16 , Benjamin Smedberg  wrote:
> 
> Yes.
> 
> --BDS
> 
> On Sun, May 29, 2016 at 6:59 PM, Chris Pearce  wrote:
> 
>> So, given that users won't be able to install Firefox on unsupported
>> versions of MacOSX, and unsupported users won't be upgraded, can we proceed
>> to remove all the nsCocoaFeatures::On[Mountain]LionOrLater() calls in
>> Firefox 49 and just assume everywhere that MacOSX specific Gecko code is
>> running on 10.9 or later?
>> 
>> 
>> 
>> On Fri, May 27, 2016 at 4:59 PM, Ralph Giles  wrote:
>> 
>>> On Thu, May 26, 2016 at 3:37 PM, L. David Baron 
>> wrote:
>>> 
 There's a screenshot in:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1255588#c8 (and #c9)
 (which is the bug that made the necessary changes for the Mac OS X
 support change in Firefox 49).
>>> 
>>> Ah, that's great. Thanks!
>>> 
>>> -r
>>> 
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

Not sure what you mean - the stack information is there, right?  This is my 
workflow:

Search for all the MOZ_CRASHes (e.g., moz crash reason “exists” (sometimes I 
just search for the graphics reasons, but we don’t have the GFX prefix on all 
the crashes, so that doesn’t quite work all the time)
Look at the top N signatures, pick one that looks like it could be graphics 
related
See what the MOZ_CRASH string is for that particular crash
Search for MOZ_CRASH reason that matches that string.  Just in case it returns 
more than “other reports”
DXR for the MOZ_CRASH reason - this gets me to the current version of the code, 
instead of the version specific one form the crash report itself.

—
- Milan



> On Jun 1, 2016, at 10:13 , Andrew McCreight  wrote:
> 
> On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote > wrote:
> 
>> If you use your favourite source code search tool to look for
>> "Shutdown too long", you'll find that this crash is occurring in
>> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
>> DXR link:
>> 
> 
> Sure, you can individually search for each assertion failure, but that's
> not useful if you are just trying to skim the list looking for assertions
> in code you are familiar with. The crash stack contains file information,
> so it would be nice if that could be exposed somehow in a search. I don't
> think you can do that right now, but I could be wrong.
> 
> Andrew
> ___
> 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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

Cairo graphics reports “out of memory” error condition when the author didn’t 
have time to figure out what went wrong.  We caught a few problems that were 
being reported as out of memory (we would pick up the Cairo library error as 
out of memory, and dutifully propagate it up the chain), when they weren’t and 
could be properly handled.

We will also report out of memory when we mean out of resources.  If Direct3D 
library can’t give us what we’re asking for, they will give us the out of 
memory error code, but that doesn’t mean that we are out of memory as such.  We 
could be out of file descriptors or some other resource (or contiguous memory 
on the graphics card.)  We can’t really easily tell these apart, so the best we 
can report is OOM.

I don’t know if there are any other places in our code where this kind of thing 
happens, and I don’t know if we care about the second one, but wanted to point 
out that showing a lot of available “regular” memory would be something that 
would happen in both of the cases I mentioned above.

—
- Milan



> On May 31, 2016, at 19:51 , Nicholas Nethercote  
> wrote:
> 
> On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew  wrote:
>> 
>> I took a quick look at a random one of these OOMs[1], and what strikes me
>> about it is that according to the crash report:
>> 
>>Total Virtual Memory2147352576
>> 
>>Available Virtual Memory122331136
>> 
>>System Memory Use Percentage52
>> 
>>Available Page File 4932567040
>> 
>>Available Physical Memory   1790652416
>> 
>>OOM Allocation Size 24
>> 
>> it seems like the system is still some way from running out of memory.
>> Available Virtual Memory is "only" 122MB, which admittedly isn't very much
>> in present-day terms, but stillwhy can't we successfully allocate a
>> 24-byte block? Can those 122MB really be _so_ fragmented?!
> 
> I looked at a bunch of these yesterday. It's pretty common for OOM to
> occur when there is around 200--250 MiB of available virtual memory;
> 122 MB is probably lower than normal. As bsmedberg said, jemalloc uses
> 1 MiB chunks so the size of 24 is something of a red herring here.
> (It's still useful in the sense that it's tiny, so making this
> allocation fallible is unlikely to be helpful.)
> 
> More generally, I did a search yesterday of all our "OOM | small"
> crashes for the past week. About 5% of them occur when the user has >
> 1 GiB of available virtual memory *and* > 1 GiB of available physical
> memory, which is surprising. I would love to see a scatter plot
> showing available physical memory vs. available virtual memory for all
> our "OOM | small" crashes. bsmedberg, do we have tools to extract that
> kind of data from crash-stats?
> 
> 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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

Agreed that all startup crashes are important.  The reason I focused on the 
MOZ_CRASHes is that this is where somebody explicitly said “this is as bad as 
it gets, we must crash now”, and I’d like to look at those once in a while, and 
see if that’s really the case.  Because I certainly ran into code that was more 
of the “this should never happen, and if it does I don’t understand why” with 
MOZ_CRASHes in it,  and that can be improved...
—
- Milan



> On May 31, 2016, at 12:28 , Benjamin Smedberg  wrote:
> 
> You're assuming that this happens every time, instead of randomly. If you add 
> the time since last crash to your column list, you can see that this is true 
> in some cases and not others.
> 
> I changed your link a little:
> 
> * remove "moz crash reason exists" - any startup crash is a problem
> * excluded content and plugin process crashes - those aren't "startup" 
> crashes the same way, and they don't prevent users from updating or disabling 
> addons
> * added facets on the crash reason and the abort message
> * added the time-since-last-crash to the column list
> 
> The top things on this list are:
> 
> by signature:
> 
> __RtlUserThreadStart | _RtlUserThreadStart (maybe bug 1164826 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1164826> , need to dig to 
> separate by this DLL)
> mozalloc_abort | NS_DebugBreak | ErrorLoadingBuiltinSheet (longstanding 
> problem, perhaps evidence of a bad update or install - bug 1194856 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1194856>)
> OOM | small - this is surprising and disturbing to me - I wonder how much of 
> this is actually OOM and how much is memory corruption. I filed bug 1276993 
> as a work item for this.
> EMPTY: no crashing thread identified; ERROR_NO_MINIDUMP_HEADER - again 
> normally OOM but I wouldn't expect that at startup
> 
> 
> --BDS
> 
> 
> On Tue, May 31, 2016 at 11:52 AM, Milan Sreckovic  <mailto:msrecko...@mozilla.com>> wrote:
> By the way, this is the kiss of death query.  MOZ_CRASH, start up, in safe 
> mode.  We’re basically forcing these people away.  There is nothing they can 
> do even if they really want to run Firefox (assuming this is a persistent 
> start up crash, of course.)  The numbers aren’t high, and majority of them 
> are OOMs, but I still feel like this query should never have things in it.  
> (Randomly picked 8 seconds, I know that some consider it a start up crash if 
> it crashes much later than that.)
> 
> https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%21__null__&uptime=%3C8&safe_mode=__true__&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
>  
> <https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%21__null__&uptime=%3C8&safe_mode=__true__&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature>
> 
> It’s also interesting to extend the query to specify the amount of memory the 
> machine has - how do we get an OOM on startup when the users have 2GB of RAM?
> —
> - Milan
> 
> 
> 
> >
> >> On May 31, 2016, at 2:22 , Nicholas Nethercote  >> <mailto:n.netherc...@gmail.com>> wrote:
> >>
> >> Hi,
> >>
> >> Here is a crash-stats search that shows all the crash reports in the
> >> past 7 days that have a "MozCrashReason" field -- which means they
> >> were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e.
> >> aggregated) by that field:
> >>
> >> https://crash-stats.mozilla.com/search/?product=Firefox&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-moz_crash_reason
> >>  
> >> <https://crash-stats.mozilla.com/search/?product=Firefox&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-moz_crash_reason>
> >>
> >> I've included the output below. (Apologies if it gets munged when the
> >> email is processed; just click on the link above to see the live
> >> list.)
> >>
> >> #1 by a long way is shutdown hangs. No great surprise.
> >>
> >> #2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument
> >> given. These are mostly OOMs, though there are a few ot

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

By the way, this is the kiss of death query.  MOZ_CRASH, start up, in safe 
mode.  We’re basically forcing these people away.  There is nothing they can do 
even if they really want to run Firefox (assuming this is a persistent start up 
crash, of course.)  The numbers aren’t high, and majority of them are OOMs, but 
I still feel like this query should never have things in it.  (Randomly picked 
8 seconds, I know that some consider it a start up crash if it crashes much 
later than that.)

https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%21__null__&uptime=%3C8&safe_mode=__true__&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

It’s also interesting to extend the query to specify the amount of memory the 
machine has - how do we get an OOM on startup when the users have 2GB of RAM?
—
- Milan



> 
>> On May 31, 2016, at 2:22 , Nicholas Nethercote  
>> wrote:
>> 
>> Hi,
>> 
>> Here is a crash-stats search that shows all the crash reports in the
>> past 7 days that have a "MozCrashReason" field -- which means they
>> were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e.
>> aggregated) by that field:
>> 
>> https://crash-stats.mozilla.com/search/?product=Firefox&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-moz_crash_reason
>> 
>> I've included the output below. (Apologies if it gets munged when the
>> email is processed; just click on the link above to see the live
>> list.)
>> 
>> #1 by a long way is shutdown hangs. No great surprise.
>> 
>> #2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument
>> given. These are mostly OOMs, though there are a few others in there.
>> These ones should be annotated so they show up separately.
>> 
>> From #3 down we have smaller numbers, but many of them are still
>> non-trivial, and a lot of them are probably indicative of problems
>> that are very easy to fix if the right person sees them. Please take a
>> look through the list to see if any of them are familiar to you.
>> 
>> (If you're wondering why I made this search... I've found that many
>> crash reports lack enough data to be actionable -- especially those
>> involving crashes caused by bad memory accesses. So it's worth
>> focusing to some degree on the crash reports that are more likely to
>> be actionable, and places where we deliberately abort are an obvious
>> case.)
>> 
>> Nick
>> 
>> 
>> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
>>129715  9.92 %
>> 2  MOZ_CRASH() 25987   1.99 %
>> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor)
>> 21040.16 %
>> 4  MOZ_CRASH(Unexpected error during FakeBlack creation.)  16790.13 %
>> 5  MOZ_CRASH(IPC FatalError in the parent process!)783 0.06 %
>> 6  MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
>> collector found more references to an object than its refcount)509
>>0.04 %
>> 7  MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 %
>> 8  MOZ_CRASH(Bogus tree op)459 0.04 %
>> 9  MOZ_RELEASE_ASSERT(sAliveDisplayItemDatas &&
>> sAliveDisplayItemDatas->Contains(aData))   263 0.02 %
>> 10 MOZ_CRASH(Using observer service off the main thread!)  223 0.02 %
>> 11 MOZ_RELEASE_ASSERT(!mSkipRequest.Exists()) (called mid-skipping)
>>222 0.02 %
>> 12 MOZ_CRASH(GFX_CRASH)215 0.02 %
>> 13 MOZ_RELEASE_ASSERT(NS_IsMainThread())   131 0.01 %
>> 14 MOZ_RELEASE_ASSERT(aMsg.priority() ==
>> IPC::Message::PRIORITY_NORMAL)120 0.01 %
>> 15 MOZ_RELEASE_ASSERT(aRefCount != 0) (CCed refcounted object has zero
>> refcount)   113 0.01 %
>> 16 MOZ_RELEASE_ASSERT(!mAudio.HasPromise()) (No duplicate sample
>> requests) 110 0.01 %
>> 17 MOZ_RELEASE_ASSERT(ok)  105 0.01 %
>> 18 MOZ_CRASH(GFX: D3D11 timeout)   99  0.01 %
>> 19 MOZ_CRASH(invalid process aSelector)73  0.01 %
>> 20 MOZ_CRASH(We lost the following char message)   58  0.00 %
>> 21 MOZ_CRASH(Unhandlable OOM while clearing document dependent slots.)
>>53  0.00 %
>> 22 MOZ_CRASH(TODO: sourcebuffer was deleted from under us) 52
>>0.00 %
>> 23 MOZ_RELEASE_ASSERT(prio == IPC::Message::PRIORITY_NORMAL ||
>> NS_IsMainThread())  51  0.00 %
>> 24 MOZ_CRASH(GFX: Failed to update reference draw target after device
>> reset)   45  0.00 %
>> 25 MOZ_RELEASE_ASSERT(isSystem)42  0.00 %
>> 26 MOZ_CRASH(Crash creating texture. See bug 1221348.) 41  0.00 %
>> 27 MOZ_CRASH(sandbox_init() failed)41  0.00 %
>> 28 MOZ_CRASH(Unable to get a working D3D9 Compositor)  37  0.00 %
>> 29 MOZ_CRASH(GFX: Invalid D3D11 content device)33  0.00 %
>> 30 MOZ_CRASH(Initial length is too large)  30  0.00 %
>> 31 MOZ_CRASH(Could not start cubeb stream for MSG.)27  0.00 

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

We considered that for the graphics ones, but the line number doesn’t persist 
between versions, so we weren’t sure how the search would find all the ones 
that are the same, but on different line numbers in different versions.  In the 
end we settled on using unique strings (for the interesting ones, at least.)
—
- Milan



> On May 31, 2016, at 9:18 , Gabriele Svelto  wrote:
> 
> On 31/05/2016 13:26, Gijs Kruitbosch wrote:
>> We could do a find/replace of no-arg calls to a new macro that uses
>> MOZ_CRASH with a boilerplate message, and make the argument non-optional
>> for new uses of MOZ_CRASH? That would avoid the problem for new
>> MOZ_CRASH() additions, which seems like it would be wise so the problem
>> doesn't get worse? Or is it not worth even that?
> 
> What about adding file/line number information? This way one could
> always tell where it's coming from even if it doesn't have a descriptive
> string.
> 
> Gabriele
> 
> ___
> 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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

I search for and track the ones that start with “GFX” (which is why we added 
those prefixes, to make it easier to find them all.)  Here’s a comment on the 
top few of those:

#3 is bug 1254400, filed in March, fixed in May, uplifted to 47.

#12 is a collection of different crashes, with the same message, but it will 
only crash in nightlies and auroras; in betas and releases, it turns into a 
warning message, and telemetry gets sent that the “crash was avoided, but you 
really should try to fix this”.

#18 has been tracked since February 2015, bug 1133623, and is related to 
recovering from driver resets.  Long haul on this one, that’s why we have 
“recover from driver resets” as a 2016H1 goal.

On a side note, the one that stood out for me was a “TODO” one.  A crash seems 
to be a wrong way to tag TODOs :)

—
- Milan



> On May 31, 2016, at 2:22 , Nicholas Nethercote  wrote:
> 
> Hi,
> 
> Here is a crash-stats search that shows all the crash reports in the
> past 7 days that have a "MozCrashReason" field -- which means they
> were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e.
> aggregated) by that field:
> 
> https://crash-stats.mozilla.com/search/?product=Firefox&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-moz_crash_reason
> 
> I've included the output below. (Apologies if it gets munged when the
> email is processed; just click on the link above to see the live
> list.)
> 
> #1 by a long way is shutdown hangs. No great surprise.
> 
> #2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument
> given. These are mostly OOMs, though there are a few others in there.
> These ones should be annotated so they show up separately.
> 
> From #3 down we have smaller numbers, but many of them are still
> non-trivial, and a lot of them are probably indicative of problems
> that are very easy to fix if the right person sees them. Please take a
> look through the list to see if any of them are familiar to you.
> 
> (If you're wondering why I made this search... I've found that many
> crash reports lack enough data to be actionable -- especially those
> involving crashes caused by bad memory accesses. So it's worth
> focusing to some degree on the crash reports that are more likely to
> be actionable, and places where we deliberately abort are an obvious
> case.)
> 
> Nick
> 
> 
> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
>129715  9.92 %
> 2  MOZ_CRASH() 25987   1.99 %
> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor)
> 21040.16 %
> 4  MOZ_CRASH(Unexpected error during FakeBlack creation.)  16790.13 %
> 5  MOZ_CRASH(IPC FatalError in the parent process!)783 0.06 %
> 6  MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
> collector found more references to an object than its refcount)509
>0.04 %
> 7  MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 %
> 8  MOZ_CRASH(Bogus tree op)459 0.04 %
> 9  MOZ_RELEASE_ASSERT(sAliveDisplayItemDatas &&
> sAliveDisplayItemDatas->Contains(aData))   263 0.02 %
> 10 MOZ_CRASH(Using observer service off the main thread!)  223 0.02 %
> 11 MOZ_RELEASE_ASSERT(!mSkipRequest.Exists()) (called mid-skipping)
>222 0.02 %
> 12 MOZ_CRASH(GFX_CRASH)215 0.02 %
> 13 MOZ_RELEASE_ASSERT(NS_IsMainThread())   131 0.01 %
> 14 MOZ_RELEASE_ASSERT(aMsg.priority() ==
> IPC::Message::PRIORITY_NORMAL)120 0.01 %
> 15 MOZ_RELEASE_ASSERT(aRefCount != 0) (CCed refcounted object has zero
> refcount)   113 0.01 %
> 16 MOZ_RELEASE_ASSERT(!mAudio.HasPromise()) (No duplicate sample
> requests) 110 0.01 %
> 17 MOZ_RELEASE_ASSERT(ok)  105 0.01 %
> 18 MOZ_CRASH(GFX: D3D11 timeout)   99  0.01 %
> 19 MOZ_CRASH(invalid process aSelector)73  0.01 %
> 20 MOZ_CRASH(We lost the following char message)   58  0.00 %
> 21 MOZ_CRASH(Unhandlable OOM while clearing document dependent slots.)
>53  0.00 %
> 22 MOZ_CRASH(TODO: sourcebuffer was deleted from under us) 52
>0.00 %
> 23 MOZ_RELEASE_ASSERT(prio == IPC::Message::PRIORITY_NORMAL ||
> NS_IsMainThread())  51  0.00 %
> 24 MOZ_CRASH(GFX: Failed to update reference draw target after device
> reset)   45  0.00 %
> 25 MOZ_RELEASE_ASSERT(isSystem)42  0.00 %
> 26 MOZ_CRASH(Crash creating texture. See bug 1221348.) 41  0.00 %
> 27 MOZ_CRASH(sandbox_init() failed)41  0.00 %
> 28 MOZ_CRASH(Unable to get a working D3D9 Compositor)  37  0.00 %
> 29 MOZ_CRASH(GFX: Invalid D3D11 content device)33  0.00 %
> 30 MOZ_CRASH(Initial length is too large)  30  0.00 %
> 31 MOZ_CRASH(Could not start cubeb stream for MSG.)27  0.00 %
> 32 MOZ_CRASH(IPC message size is too large)25  0.00 %
> 33 MOZ_RELEASE_ASSERT(mWorkerLoopID == MessageLoop::current()->id())
> (not on worker thread!)  

Re: All about crashes

[Milan Sreckovic]

Crashes that are charted here lead to disabling of graphics acceleration for 
these users, until next Firefox (or new graphics driver.)  So, we trade them 
one startup crash right after installation, for multiple crashes during the 
usage of video or graphics features.

—
- Milan



> On May 24, 2016, at 13:58 , Lawrence Mandel  wrote:
> 
> ... We've discussed mitigations
> for startup crashes (and implemented one for gfx). 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Milan Sreckovic]

For graphics, it’s performance if we start requiring SSE2.  Lately, canvasmark 
benchmark, and increasingly more trouble when updating Skia library.
—
- Milan



> On May 6, 2016, at 14:39 , Henri Sivonen  wrote:
> 
> On Fri, May 6, 2016 at 8:17 PM, Gregory Szorc  wrote:
>> On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg 
>> wrote:
>> 
>>> I agree that we should drop support for non-SSE2. It mattered 7 years ago
>>> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
>>> doesn't matter now.
>>> 
>> 
>> Wait - are we talking about requiring SSE or SSE2? The thread up to this
>> point was talking about requiring just SSE, not SSE2. I just want to make
>> sure we're on the same page since according to mhoye's post the non-SSE2
>> population is ~25x larger than the non-SSE population...
> 
> What does requiring SSE without requiring SSE2 buy us apart from
> VS2015 compat? Is it enough to fully avoid x87-style non-IEEE floating
> point math? (SSE2 is usually cited when talking about migrating from
> x87 to IEEE.)
> 
> It seems that requiring SSE2 is the typical discontinuity point as
> seen in Windows itself, Chromium, Rust, various codec optimizations,
> C++ compiler defaults (MSVC and, I believe, clang), etc.
> 
> That is to say, I hope the outcome here is that we start requiring SSE2.
> 
> On Fri, May 6, 2016 at 9:11 PM, Milan Sreckovic  
> wrote:
>> While I agree we should drop non-SSE (and have started a conversation to 
>> drop non-SSE2 as well :), the comparison to dropping 10.6-10.8 users is 
>> somewhat unfair.  Those users can upgrade 10.9 easier than the non-SSE users 
>> can buy a new computer.
> 
> Upgrading from Mac OS X 10.6 can be more expensive than buying a new
> entry-level Windows PC if what kept you on 10.6 was expensive PPC-era
> proprietary software (e.g. PPC-era Creative Suite for casual enough
> use that you don't need the latest for the features). Also, some Macs
> can't upgrade beyond 10.7. So the comparison is fairer than it first
> may seem.
> 
> -- 
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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: Reverting to VS2013 on central and aurora

[Milan Sreckovic]

While I agree we should drop non-SSE (and have started a conversation to drop 
non-SSE2 as well :), the comparison to dropping 10.6-10.8 users is somewhat 
unfair.  Those users can upgrade 10.9 easier than the non-SSE users can buy a 
new computer.
—
- Milan



> On May 6, 2016, at 12:22 , Gregory Szorc  wrote:
> 
> On Fri, May 6, 2016 at 7:10 AM, Mike Hoye  > wrote:
> 
>> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>> 
>>> FWIW, the crashes we've seen so far are from incorrectly emitted movss
>>> instructions. This instruction is part of the original SSE instruction
>>> set,
>>> which was initially unveiled by Intel on the Pentium 3 in 1999 and later
>>> by
>>> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
>>> need
>>> Firefox to run on processors manufactured in the 90s.
>>> 
>> Per an IRC conversation with chutten, Firefox users on CPUs that do not
>> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
>> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
>> etc), this work provides continuity of support to 0.01% of our users.
>> 
> 
> This population (0.015%) is ~100x smaller than the OS X 10.6-10.8 users we
> just decided to drop (going by bsmedberg's quote of 1.2% in the OS X
> deprecation thread). Looking at the numbers alone, I can't see how we
> wouldn't arrive at the conclusion to require SSE. Beyond the numbers, the
> modern web must be a horrible experience on ancient processors and machines
> not supporting SSE. I'm not sure what value continuing to provide Firefox
> updates to this population will add.
> 
> Reverting to VS2013 will have an unplanned negative impact on developers
> and automation. Reverting to VS2013 then deciding a short time after that
> we can use VS2015/SSE after all will have even more negative impact. It is
> desirable to avoid both these things. Therefore *I'm going to not move
> forward with reverting aurora and central to VS2013 unless someone says
> otherwise*. I have cancelled the aurora uplift requests in bug 1270664
> until a decision is made.
> ___
> 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: Reverting to VS2013 on central and aurora

[Milan Sreckovic]

If it matters for this discussion, I’m pretty sure central doesn’t build with 
VS2013 today.  At least it doesn’t for me.
—
- Milan



> On May 6, 2016, at 13:17 , Gregory Szorc  wrote:
> 
> On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg 
> wrote:
> 
>> I agree that we should drop support for non-SSE2. It mattered 7 years ago
>> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
>> doesn't matter now.
>> 
> 
> Wait - are we talking about requiring SSE or SSE2? The thread up to this
> point was talking about requiring just SSE, not SSE2. I just want to make
> sure we're on the same page since according to mhoye's post the non-SSE2
> population is ~25x larger than the non-SSE population...
> 
> 
>> 
>> We do need to avoid updating these users to a build that will crash, and
>> do the same "unsupported" messaging we're doing for old versions of MacOS.
>> Gregory, will you own that? You will probably need to add CPU feature
>> detection to the update URL/params for 47, or use some kind of system addon
>> to shunt these users off the main update path.
>> 
> 
> Given that 47 is in Beta, is it too late/risky to make this change on that
> channel? Should we revert to VS2013 on Aurora/48 and make the updater
> modifications on that channel? I think this will have minimal negative
> impact, as most of the impact to changing toolchains would be on central,
> as that is where most developers and automation live.
> 
> 
>> 
>> On Fri, May 6, 2016 at 10:10 AM, Mike Hoye  wrote:
>> 
>>> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>>> 
 FWIW, the crashes we've seen so far are from incorrectly emitted movss
 instructions. This instruction is part of the original SSE instruction
 set,
 which was initially unveiled by Intel on the Pentium 3 in 1999 and later
 by
 AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
 need
 Firefox to run on processors manufactured in the 90s.
 
>>> Per an IRC conversation with chutten, Firefox users on CPUs that do not
>>> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
>>> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
>>> etc), this work provides continuity of support to 0.01% of our users.
>>> 
>>> - mhoye
>>> 
>>> 
>>> 09:59  So, to put it clearly and precisely, of the Firefox
>>> Population in release and beta who are reporting at least base telemetry
>>> collection on machines running supported configurations, only 0.01% cannot
>>> definitively say they have SSE.
>>> 10:00  (according to a 1% random sample as stored in the
>>> longitudinal dataset)
>>> 
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>> 
>> 
>> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Milan Sreckovic]

This.  Dropping the XP support is *completely* not an engineering decision.  It 
isn’t even a community decision.  It is completely, 100% MoCo driven Firefox 
product management decision, as long as the numbers of users are where they are.

It is good to have these conversations, about potential pros of removing the 
support for XP, as they will inform us in the future.  In the immediate term, 
it will be very frustrating for people to think that any technical information 
they provide would be enough to push us in the direction of dropping XP support.

—
- Milan



> On Apr 30, 2016, at 16:26 , L. David Baron  wrote:

> I think enough of our users are on Windows XP that decisions about
> dropping Windows XP are not a purely engineering decision.  (Do we
> still have more Windows XP users than we have on all non-Windows
> platforms combined?)  Pushing those users to ESR without buy-in from
> all parts of the organization will likely lead to worse engineering
> problems than having to support XP (e.g., having to support 45ESR
> substantially longer).
> 

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Milan Sreckovic]

Release engineering is working on this decision, stay tuned.
—
- Milan



> On Apr 19, 2016, at 12:02 , Nicolas Silva  wrote:
> 
> Re-re-ping.
> Being able to use a more recent standard library would simplify a lot of
> things on our end. For example updating 3rd party libraries such as
> skia, which depends on a modern stl, is a pain, and there are plenty of
> other examples.
> 
> Cheers,
> 
> Nical
> 
> On Mon, Apr 4, 2016, at 07:33 PM, a...@imgland.xyz wrote:
>> Doesn't hombrew provide a version of g++ that includes c++11
>> 
>> 04.04.2016, 18:12, "Nathan Froyd" :
>>> Re-ping on this thread. It would be really useful to have a decision
>>> one way or the other for figuring out exactly how a C++11 STL on OS X
>>> is going to work.
>>> 
>>> -Nathan
>>> 
>>> On Thu, Mar 24, 2016 at 12:51 PM, Ralph Giles  wrote:
  Discussion seems to have wound down. Is there a decision on this?
 
   -r
  ___
  dev-platform mailing list
  dev-platform@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-platform
>>> 
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> 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: Moving XP to ESR?

[Milan Sreckovic]

What’s the “XP tax”?  Graphics usually tries to simplify the playing field as 
much as possible, but I can’t say that XP has been causing any trouble, or that 
we have been getting too many XP specific problems (certainly fewer than 
Windows 10 :)  

I don’t see XP going away soon, and as mentioned, may even go up.
—
- Milan



> On Apr 18, 2016, at 12:25 , Steve Fink  wrote:
> 
> On 04/18/2016 07:20 AM, Lawrence Mandel wrote:
>> On Mon, Apr 18, 2016 at 9:04 AM, Henri Sivonen  wrote:
>> 
>>> XP has now gone for two years without security patches from Microsoft.
>>> Additionally, as of its latest release, Chrome no longer supports XP.
>>> 
>>> When 46 ships, it would be a great time to make AUS advertise 45 ESR
>>> builds to XP (even on non-ESR) channel. This would keep XP supported
>>> through the ESR cycle but would put an end to the XP tax on trunk.
>>> 
>>> Are we already on track to doing this? If not, why not?
>>> 
>> We are not on track to do this.
>> 
>> The Firefox Product team is investigating Firefox use on XP in order to
>> make a decision about the criteria that need to be met to continue to
>> support this OS. No decision has been made about a change in support for
>> Windows XP.
> 
> Past performance is not an indicator of future results. :)
> 
> I don't see how we can estimate the trajectory of XP usage when we have the 
> discontinuity from Chrome removing XP support. I would expect an uptick in 
> our XP percentage as a result. How much of an uptick, I have no idea.
> 
> Nor do I know how we want to balance the XP equation -- supporting XP means 
> putting users at risk by allowing them to continue running an insecure OS. 
> And yet, a substantial number people will continue to run XP with or without 
> us, and abandoning them isn't doing them any favors either.
> 
> But if we're going to use number of users as a metric in the decision, I 
> think we'd have to wait to see the effects of the end of Chrome support.
> 
> XP users also aren't going to be the early adopters and thought leaders, so I 
> would think that x% of XP users is less valuable than x% of Windows 10 users. 
> (Although they may be a more loyal x%, given their lack of options and 
> resistance to change...)
> 
> ___
> 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: Coding style for C++ enums

[Milan Sreckovic]

Maybe there was a reason we didn’t have this in the style guide as a single 
choice.
—
- Milan



> On Apr 11, 2016, at 11:00 , Kartikaya Gupta  wrote:
> 
> Based on all the feedback so far I think the best compromise is to use
> enum classes with the "e" prefix on the values. As was mentioned, the
> "e" prefix is useful to distinguish between enum values and function
> pointer passing at call sites, but is a small enough prefix that it
> shouldn't be too much of a burden.
> 
> I realize not everybody is going to be happy with this but I don't
> want this discussion to drag on to the point where it's a net loss of
> productivity no matter what we end up doing. I'll update the style
> guide.
> 
> Thanks all!
> 
> kats
> 
> 
> On Sun, Apr 10, 2016 at 11:43 AM, smaug  wrote:
>> On 04/10/2016 05:50 PM, Aryeh Gregor wrote:
>>> 
>>> On Fri, Apr 8, 2016 at 8:35 PM, smaug  wrote:
 
 enum classes are great, but I'd still use prefix for the values.
 Otherwise the values look like types - nested classes or such.
 (Keeping my reviewer's hat on, so thinking about readability here.)
>>> 
>>> 
>>> In some cases I think it's extremely clear, like this:
>>> 
>>>   enum class Change { minus, plus };
>>> 
>>> whose sole use is as a function parameter (to avoid a boolean
>>> parameter), like so:
>>> 
>>>   ChangeIndentation(*curNode->AsElement(), Change::plus);
>>> 
>>> In cases where it might be mistaken for a class, it might make more
>>> sense to prefix the enum class name with "E".  I don't think this
>>> should be required as a general policy, though, because for some enums
>>> it might be clear enough without it.
>>> 
>> 
>> Indeed in your case it is totally unclear whether one is passing a function
>> pointer or enum value as param.
>> If the value was prefixed with e, it would be clear.
>> 
>> Consistency helps with reviewing (and in general code readability) a lot, so
>> the less we have optional coding style rules, or
>> context dependent rules, the better.
>> 
>> 
>> 
>> 
>> 
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: Triage Plan for Firefox Components

[Milan Sreckovic]

Valid point.

Being able to tell the status of “other team’s bugs” is critical for some 
number of people that look at bugs across all teams.  A number of directors, 
release management, I’m sure a sizeable number.  I would still guess a minor 
though; I know I am completely unaffected by the P’s and Q’s that the media 
team uses, and don’t care if they are different from what E10S is using.  And 
whatever they have seems to be working for them.

If it is important for everything to be the same, we need to consider the 
multiplier.  For example, if it’s going to make life twice as easy for Lawrence 
(hi Lawrence), but make it 10% more difficult for all the developers - I’d say 
we shouldn’t do it.  If it’s going to let us have better decision making 
because we can extract some data out of bugzilla that we otherwise couldn’t, 
then we probably should do it (“it” = be consistent.)

Sometimes we want to do things because it makes things clean and pretty.  When 
that’s the only reason to do something, we should be cautious (it would be 
clean and pretty if everybody worked 9-5, and out of an office, right?).  If 
clean and pretty leads to better data, and that data is required and used for 
better decision making, different story.

—
- Milan



> On Apr 1, 2016, at 11:16 , Andrew McCreight  wrote:
> 
> On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson 
> wrote:
> 
>> Anthony's Media Playback team has been using a simple and effective triage
>> system without special tags. All open bugs in the Audio/Video Playback
>> component are in one of four states at all times:
>> 
>> * Priority P1 bugs should be fixed ASAP.
>> * Priority P2 bugs are real bugs or features we want to fix soon.
>> * Priority P5 bugs are "patches accepted" bugs.
>> * Bugs without a priority are untriaged.
>> 
> 
> The drawback of indicating priorities in this way is that it is totally
> opaque to anybody who is not on that particular subteam, let alone somebody
> who is using Bugzilla for the first time to report breakage on a site they
> use. If this was marked "backlog" or whatever instead of "P5", and there
> was a link to an explanation of what "backlog" meant, then it would make it
> much easier for people to figure out what is going on in any bug. I think
> that is a big advantage of the proposed triaging system, even though I
> think it is reasonable for anybody to be skeptical of adding even more
> bells and whistles to the Bugzilla interface.
> 
> Andrew
> 
> 
>> P3 and P4 are not used. :) P5 sends a pretty clear message to people that
>> we will not fix that issue any time soon. However, the P5 list is pretty
>> clean because we aggressively WONTFIX bugs we truly don't want to fix
>> instead of letting them linger.
>> 
>> Bugzilla already has a lot of fields. It seems like new workflows could be
>> built with a streamlined frontend UI without changing Bugzilla's database
>> schema. The advantage of codifying existing workflows instead of adding new
>> fields is that existing bugs will be compatible with the new system.
>> 
>> IIRC, the Fennec team also tracked the "Someone is working on this"
>> proposed in Emma's plan by assigning owners to all bugs, but developers
>> would change their bug's status from NEW to ASSIGNED only when they began
>> actively working on the bug.
>> 
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: Triage Plan for Firefox Components

[Milan Sreckovic]

> On Mar 31, 2016, at 18:22 , Daniel Veditz  wrote:
> 
> On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic  <mailto:msrecko...@mozilla.com>> wrote:
> I’m going to start and keep arguing that we do not want to have an explicit 
> name for that largest bucket of “wishlist” bugs, and should instead have it 
> marked by the absence of a tag.
> 
> ​What distinguishes a bug that has not been triaged from a bug that has been 
> triaged and (mentally?) put into the third bucket if there's no explicit 
> marker?​

I understood there was an “untriaged” status set by default.

On the other hand, the latest choice of “backlog” is non-confrontational enough 
that, for the purposes of the naming discussion, is close enough to “blank" for 
me not to argue.

—
- Milan

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

Re: Triage Plan for Firefox Components

[Milan Sreckovic]

This may be somewhat long winded.  I will make it in the context of Gecko 
graphics, because that’s where I have the most data and experience.  It may or 
may not apply to other components.

Reviewing all the incoming bugs, in a timely matter, is very important to us.  
Over the past few years, the graphics team fixed about half the bugs that came 
in (roughly, we fix a thousand out of the two thousand that come in.)  The main 
goal of any kind of a bug triage process is thus to choose the right half of 
the bugs to fix, and spend as little time as possible on the rest.

With that in mind we started a much less documented and much more minimal 
process in 2015.  I don’t know that we have the data to back the “avoid issues 
falling between the cracks”, but it certainly seems that way.  One data point 
we do have - the average amount of time it took to fix the bugs triaged in 2015 
was almost half of that for 2014 and the previous four years.

This to illustrate that I believe in the bug triage, looking at bugs as they 
come in, and making some quick decisions how to proceed.

I’m also a big believer in lightweight processes and minimal documentation, so 
there are a few comments I have on what the document below describes, and in 
general.

The more states we have, the more not-so-useful conversation we’ll have about 
assigning those states.  I’m glad to see that we have a small number, currently 
named fix-now, non-urgent and wishlist (the naming is in flux and being argued 
in the document.)  I’m mentally mapping these to “blocking the release”, “can’t 
ship too many releases with this” and “I hope we eventually fix this”, but 
perhaps there is a different interpretation.

I would expect to see the majority of the graphics bugs end up in the last 
group.  Why?  Since you never plan for the full capacity, as that actually 
reduces your throughput, and since we only fix half the bugs that come in, it 
stands to reason that we should not have even close to half of the bugs in the 
first two categories.  In other words, we want to be fixing some of the 
“wishlist” bugs.  And we need to be very careful about not making the fix-now 
turn into “we really should fix this”, and only allow the “team works on 
nothing else while there are fix-now bugs open”.  Otherwise, well, it loses its 
value.

Step aside - my thoughts on the “How Triage Will Work in Bugzilla” section.  I 
would stick with the definition of the states and have dashboards that show the 
bug counts in different categories for different teams.  The current 
description is a bit too detailed and inflexible.  It suggests that we can 
figure out the best way to do this before we’ve even started doing it (the 
pilot program non-withstanding), and it mixes the mechanics with the goals.

I’m going to start and keep arguing that we do not want to have an explicit 
name for that largest bucket of “wishlist” bugs, and should instead have it 
marked by the absence of a tag.  This is not about the heavily involved 
community, those that will stick around regardless of what we do to them, and 
anybody that reads this e-mail.  This is about people that are reporting their 
first bugs, that are occasionally involved, who are vital to our success.  If I 
was one of those, and I started seeing that most, if not all, of my bugs are 
marked as wishlist or deferred or in-copious-spare-time, I’m going to get 
discouraged and stop doing it.  After all, I don’t seem to be valuably 
contributing, because I’m just telling you things you don’t care about.  Or, I 
could start arguing in the bug, that this should be higher priority, and fill 
up the comments with non-technical information.

Getting close to a full page, I’ll stop now.  I’m available for live 
conversations on the topic :)

—
- Milan



> On Mar 29, 2016, at 16:07 , Emma Humphries  wrote:
> 
> tl;dr
> 
> In Quarter Two I'm implementing the work we’ve been doing to improve
> triage, make actionable decisions on new bugs, and prevent us from shipping
> regressions in Firefox.
> 
> Today I’m asking for feedback on the plan which is posted at:
> 
> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
> 
> Allowing bugs to sit around without a decision on what we will do about
> them sends the wrong message to Mozillans about how we treat bugs, how we
> value their involvement, and reduces quality.
> 
> The Firefox quality team (myself, Mike Hoye, Ryan VanderMeulen, Mark Cote,
> and Benjamin Smedberg) want to make better assertions about the quality of
> our releases by giving you tools to make clear decisions about which bugs
> must be fixed for each release (urgent) and actively tracking those bugs.
> What We Learned From The Pilot Program
> 
> During the past 6 weeks, we have prototyped and tested a triage process
> with the DOM, Hello, and Developer Tools teams.
> 
> Andrew Overholt, who participated in the pilot for the DOM team, said, “A
> consistent bug triage process can help us s

Re: Triage Plan for Firefox Components

[Milan Sreckovic]

We do have a feature keyword today.  While it may be most used for the 
documentation purposes, the feedback graphics team got when we started using it 
to tag feature requests was positive.  As in, it’s OK to use for that. 
—
- Milan



> On Mar 29, 2016, at 22:32 , Emma Humphries  wrote:
> 
> On Tue, Mar 29, 2016 at 5:09 PM, Eric Rescorla  wrote:
> 
>> On a more substantive, less procedural note, this seems to be designed for
>> a particular workflow in which there is an assumption that bugs are for
>> immediate processing. However, in may cases we use bugs as placeholders or
>> assemble big dependency trees of all the bugs that are needed to do a large
>> complex feature. From this perspective, a three-tier system of "urgent",
>> "non-urgent", and "wishlist" is either a regression from more fine-grained
>> systems such as dependency trees/priorities or is redundant with them. This
>> is especially true for long-running efforts. In other words, this may be a
>> useful change for some components while not being useful for others. For
>> the specific case of NSS (where I currently do a lot of my work) this
>> doesn't seem like it would be a helpful change.
> 
> 
> ​This is where it would be nice to have a way of saying, feature vs. bug as
> part of the triage process, even it that's not a clean separation to make,
> because that could get long running feature work out of the triage process,
> but I don't have an immediate answer for this. It may be that we change the
> scope of components this applies to.
> 
> I'll follow up with Doug Turner to see if changing the scope of this for
> platform related bugs is warranted.
> 
> ​
> --
> ​ Emma​
> ___
> 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: Does SSE2 usage still need to be conditional?

[Milan Sreckovic]

Right - I mentioned the number earlier, but let me summarize:

99.77% of the users on all channels have SSE2 support;
51.7% of all users are on 32-bit Windows;
0.44% of all users on 32-bit Windows do not have SSE2 support.

—
- Milan



> On Feb 2, 2016, at 23:06 , Martin Thomson  wrote:
> 
> On Wed, Feb 3, 2016 at 12:54 AM, Benjamin Smedberg
>  wrote:
>>> Do we have any, say telemetry, that would move this from speculation
>>> into numbers?  Sure, numbers aren't necessarily perfect, but I'm sure
>>> that they would help.
>> 
>> Milan is quoting numbers from telemetry data. The last time I calculated
>> this was 8 months ago, but at the time our users were using an almost 50/50
>> split of 32-bit Windows and 64-bit Windows. We expect that number to grow
>> slowly over time with the device replacement cycle.
> 
> I'm afraid that those numbers don't answer the question that is asked,
> namely: does the user have SSE2?  I suspect that a very large
> proportion of users on 32-bit systems with 32-bit builds will still
> have a 64-bit processor.  Far more than 48%, that is.

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

Re: Does SSE2 usage still need to be conditional?

[Milan Sreckovic]

Right, what Benjamin said - the “if I’m reading the data correctly” meant I was 
looking at the telemetry results from the same link that I included in one of 
the earlier replies: 
http://people.mozilla.org/~danderson/moz-gfx-telemetry/www/#view=system

51.9% 32-bit Firefox on 32-bit Windows
44.7% 32-bit Firefox on 64-bit Windows
3.5% 64-bit Firefox on 64-bit Windows

—
- Milan



> On Feb 2, 2016, at 8:54 , Benjamin Smedberg  wrote:
> 
> 
> 
> On 2/1/2016 7:35 PM, Martin Thomson wrote:
>> On Tue, Feb 2, 2016 at 10:42 AM, Milan Sreckovic  
>> wrote:
>>> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit 
>>> Windows.  If I’m reading the data correctly, more than half.  A small 
>>> percentage of those don’t have SSE2.
>> Do we have any, say telemetry, that would move this from speculation
>> into numbers?  Sure, numbers aren't necessarily perfect, but I'm sure
>> that they would help.
> 
> Milan is quoting numbers from telemetry data. The last time I calculated this 
> was 8 months ago, but at the time our users were using an almost 50/50 split 
> of 32-bit Windows and 64-bit Windows. We expect that number to grow slowly 
> over time with the device replacement cycle.
> 
> --BDS
> 

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

Re: Does SSE2 usage still need to be conditional?

[Milan Sreckovic]

> On Feb 1, 2016, at 18:00 , Xidorn Quan  wrote:
> ...
> 
> It seems to me if we do, whether enabling SSE2 on x86 doesn't really
> matter unless we have a good reason. Fewer and fewer people would
> stick on x86, especially who cares about performance.

Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit 
Windows.  If I’m reading the data correctly, more than half.  A small 
percentage of those don’t have SSE2.

> 
> If we haven't yet done that, we should. It seems to me the majority
> processors which supports x64 also supports SSE2. If there are really
> some people who use a processor doesn't support SSE2 but are using
> 64bit Firefox, they could simply back to use the 32bit version.
> 
> - Xidorn
> ___
> 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: Does SSE2 usage still need to be conditional?

[Milan Sreckovic]

Telemetry reports 99.77% with SSE2…

http://people.mozilla.org/~danderson/moz-gfx-telemetry/www/#view=system 


—
- Milan



> On Jan 29, 2016, at 15:33 , Kartikaya Gupta  wrote:
> 
> I also want to highlight the thing at the end of the gist linked above
> - the majority of the non-SSE2 population are on 43.0.4. That is,
> they're keeping up-to-date, and would likely be affected by this more
> than somebody stranded on an old version.
> 
> On Fri, Jan 29, 2016 at 3:29 PM, Chris H-C  wrote:
>> tl;dr - Around 99.5% of Firefox Desktop clients on release channel
>> represented by (a 20% sample of) pings submitted by on January 21, 2016 had
>> "hasSSE2" detected.
>> 
>> Here's the analysis and results on github. Please feel free to check my
>> work: https://gist.github.com/chutten/4959c873d7fbbec0785a
>> 
>> Keep in mind we cannot prove a negative from this. I cannot state that
>> those pings without hasSSE2 correspond to clients that don't have SSE2
>> support on their machines. So I tried (and failed, see bottom section of
>> that gist) to keep analysis and discussion centred on the "hasSSE"
>> population alone.
>> 
>> :chutten
>> 
>> On Fri, Jan 29, 2016 at 2:44 PM, Mike Hoye  wrote:
>> 
>>> On 2016-01-29 2:05 PM, Cameron Kaiser wrote:
>>> 
 On 1/29/16 9:43 AM, Ashley Gullen wrote:
 
> FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
> "other settings"): http://store.steampowered.com/hwsurvey
> 
 
 For that to be valid, one must assume that the population of Firefox
 users and Steam users are sufficiently similar. I don't think that's
 necessarily true since most Steam titles have substantially higher system
 requirements.
 
>>> While that's a fair point, Microsoft turned compiling with SSE2 on by
>>> default in Visual Studio in 2012, and it's been basically impossible to buy
>>> an x86 CPU without it since...  2004 or so?
>>> 
>>> I've tapped chutten about this, and he says:
>>> 
>>> 14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"]
>>> contains "SSE2"
>>> 14:33 < chutten> or, rather, the inverse
>>> 
>>> ... which he then explained to me means "we can get our own data in short
>>> order."
>>> 
>>> He says it'll be straightforward to pull in, so he's going to do that.
>>> 
>>> 
>>> - mhoye
>>> 
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>> 
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: PSA: Enabling APZ on nightly desktop (OS X, Windows)

[Milan Sreckovic]

In the context of checkerboarding - we know there is more of it than we want, 
so we don’t need a lot of bugs on it at this point, but if you have an 
interesting or important example of it happening, please file it, and make it 
block the “paint-fast” bug 1154825 (do check for duplicates first - for 
example, the “bugzilla scrolling checkerboards a lot” is already known :)
—
- Milan



On Jul 21, 2015, at 22:29 , Kartikaya Gupta  wrote:

> Just a heads-up that I just pushed bug 1157746 to inbound, which
> enables async scrolling for trackpad/wheel scrolling by default for
> nightly OS X desktop builds. It requires e10s, and so if you have e10s
> disabled it has no effect for you. If you have e10s enabled, you
> should see smoother/more responsive scrolling, and probably more
> "checkerboarding" (scrolling into unpainted content areas).
> 
> Note that this is currently NOT riding the trains, we will leave it
> enabled on Nightly only until it is more baked, but it should be
> stable enough for general usage. Bug 1178298 tracks letting it ride
> the trains. Please file bugs in the Core::Panning and Zooming
> component if you see anything misbehaving. If you need to turn it off
> for whatever reason, you can set the layers.async-pan-zoom.enabled
> pref back to false.
> 
> Assuming this doesn't get backed out, I intend to also enable the same
> thing on Windows in the next day or two (bug 1157745). Linux will take
> a bit longer since there are some test failures we need to sort out
> first.
> 
> Cheers,
> kats
> ___
> 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

[Milan Sreckovic]

Jeff encouraged me to add more things to this thread, so I’m blaming him.  So, 
some random thoughts.

After getting paid to write code for 20+ years and then showing up at Mozilla, 
and seeing the a prefix, I thought “this is brilliant, how come we didn’t think 
of doing that before?!”, as a reasonable balance between nothing and the 
insanity of the full Hungarian.

I find a prefix useful when I’m writing code and when I’m reading it.

I have no trouble reading the code that isn’t using this convention.  I don’t 
think I ran into a situation where only some of the arguments in the function 
were using the prefix (and some were not), but I can imagine that being the 
only situation where I’d argue that it’s confusing.

In other words, as weird as it may sound, I find the prefix improving the 
readability, but the lack of it not hindering it.  And it makes no difference 
to me when I’m reviewing code, which is a couple of orders of magnitude fewer 
times than for most people on this thread.

If I was writing a new file from scratch, I’d use this convention.  If I was in 
a file that wasn’t using it, it wouldn’t bother me.

I think it would be a bad idea to force this consistency on the whole codebase 
(e.g., either clear it out, or put it everywhere), as I don’t think it would 
actually solve anything.  The “consistent is good” can be taken too far, and I 
think this would be taking it too far.

I honestly think the best thing to do here is nothing - remove it from the 
style guide if we don’t want to enforce it, but don’t stop me from using it.

Blame Jeff for the above.

—
- Milan



On Jul 7, 2015, at 20:41 , Karl Tomlinson  wrote:

> Jeff Gilbert writes:
> 
>> It can be a burden on the hundreds of devs who have to read and understand
>> the code in order to write more code.
> 
> Some people find the prefix helps readability, because it makes
> extra information immediately available in the code being
> examined, while you are indicating that this is a significant
> burden on readability.
> 
> Can you explain why the extra letter is a significant burden?
> 
> If the 'a' prefix is a burden then the 'm' prefix must be also,
> and so we should be using this->member instead of mMember.
> 
>> The opinions of a few over-harried
>> reviewers should not hold undue sway over the many many devs writing code.
> 
> unless people want code to be reviewed.
> ___
> 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

[Milan Sreckovic]

Removing the style guide for “prefix function arguments with a” will not 
preclude people from naming a variable aFoo.  At least the current style guide 
precludes people from naming non-function arguments that way, albeit indirectly.

I’m trying to understand the possible outcomes of this particular conversation:

a) Nothing happens.  We leave a prefix in the style guide, some code ignores 
it, some follows it.
b) We change the style guide to remove the a prefix
  1) We wholesale modify the code to remove the prefix, catching scenarios 
where we have a clash
  2) We don’t do a wholesale modification
 i) We get rid of a’s as we modify the code anyway
ii) We get rid of a’s one file at a time as we see fit
   iii) We get rid of a’s one function at a time
c) We change the style guide to prohibit the a prefix
  1) We wholesale modify the code to remove the prefix, catching scenarios 
where we have a clash
  2) We don’t do a wholesale modification
 i) We get rid of a’s as we modify the code anyway
ii) We get rid of a’s one file at a time as we see fit
   iii) We get rid of a’s one function at a time

I can’t imagine the mess of any option that includes “1” and wholesale code 
modification, and if you remove those, the rest of the sort of start looking 
more or less the same.

I find a’s useful, but I’ve spent enough time in different codebases that I 
don’t think those types of things are ever worth the level of energy we expend 
on them.  As long as we’re not adding _ in the variable names.  That’s just 
wrong. ;)

—
- Milan



On Jul 7, 2015, at 16:33 , Jeff Gilbert  wrote:

> ...
> 
> I have found no other style guide that recommends `aFoo`. Why are we
> different? Why do we accept reduced readability for all external
> contributors? Why do so many other Mozilla projects not use this alleged
> readability aid?
> ___
> 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: The War on Warnings

[Milan Sreckovic]

Do we have a all encompassing meta bug to collect all of the bugs that fix the 
warnings?
—
- Milan



On Jun 16, 2015, at 19:29 , Eric Rahm  wrote:

> An update on progress. I've landed bugs which should clean up ~180,000 
> warnings. I have bugs pending for another ~26,000.
> 
> The latest top 40:
> 
> *Note: I improved my normalization a bit so it might look a bit different
> 
> 18012 [N] WARNING: Subdocument container has no frame: file 
> layout/base/nsDocumentViewer.cpp, line 2520
> 14816 [N] WARNING: NS_ENSURE_SUCCESS(EnsureScriptEnvironment(), nullptr) 
> failed with result 0x: file docshell/base/nsDocShell.cpp, line 4605
> 9809 [N] WARNING: No docshells for remote frames!: file 
> dom/base/nsFrameLoader.cpp, line 459
> 8929 [N] WARNING: Someone passed native anonymous content directly into 
> frame construction.  Stop doing that!: file 
> layout/base/nsCSSFrameConstructor.cpp, line 6559
> 8062 [N] WARNING: Suboptimal indexes for the SQL statement 0x 
> (http://mzl.la/1FuID0j).: file storage/mozStoragePrivateHelpers.cpp, line 109
> 7760 [N] WARNING: NS_ENSURE_TRUE(mDocShell) failed: file 
> embedding/browser/nsWebBrowser.cpp, line 363
> 7454 [N] WARNING: anonymous nodes should not be in child lists (bug 
> 439258): file layout/base/RestyleManager.cpp, line 1439
> 6294 [N] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 
> 0x: file netwerk/base/nsFileStreams.cpp, line 492
> 6294 [N] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 
> 0x: file netwerk/base/nsFileStreams.cpp, line 205
> 6131 [N] WARNING: No outer window available!: file 
> dom/base/nsGlobalWindow.cpp, line 3920
> 5207 [N] WARNING: NS_ENSURE_TRUE(domWindow) failed: file 
> embedding/browser/nsDocShellTreeOwner.cpp, line 83
> 5193 [N] WARNING: NS_ENSURE_TRUE(aInBrowser) failed: file 
> embedding/browser/nsDocShellTreeOwner.cpp, line 79
> 5073 [N] WARNING: zero axis length: file dom/svg/nsSVGLength2.cpp, line 
> 124
> 4606 [N] WARNING: No widget found in TabParent::UpdateDimensions: file 
> dom/ipc/TabParent.cpp, line 974
> 4574 [N] WARNING: Shouldn't call SchedulePaint in a detached pres 
> context: file layout/generic/nsFrame.cpp, line 5181
> 3891 [N] WARNING: Please do not use mouseenter/leave events in chrome. 
> They are slower than mouseover/out!: '!nsContentUtils::IsChromeDoc(d)', file 
> dom/events/EventListenerManager.cpp, line 367
> 3746 [N] WARNING: Graph thread slowdown?: 'std::abs(framePosition - 
> CurrentDriver()->StateComputedTime()) < MillisecondsToMediaTime(5)', file 
> dom/media/MediaStreamGraph.cpp, line 1193
> 3182 [N] WARNING: Enabling vsync compositor: file 
> gfx/layers/ipc/CompositorParent.cpp, line 674
> 3042 [N] WARNING: NS_ENSURE_TRUE(mCallback) failed: file 
> dom/base/nsFrameMessageManager.cpp, line 805
> 2859 [N] WARNING: '!mContentCache.CacheEditorRect(this, 
> &aIMENotification)', file widget/PuppetWidget.cpp, line 819
> 2859 [N] WARNING: '!editorRectEvent.mSucceeded', file 
> widget/ContentCache.cpp, line 499
> 2690 [N] WARNING: nsWindow::GetNativeData not implemented for this type: 
> file widget/PuppetWidget.cpp, line 1058
> 2527 [N] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 
> 0x: file dom/base/nsContentUtils.cpp, line 3712
> 2526 [N] WARNING: NS_ENSURE_TRUE(domDoc && target) failed: file 
> dom/base/nsContentUtils.cpp, line 3657
> 2478 [N] WARNING: Subdocument container has non-subdocument frame: file 
> layout/base/nsDocumentViewer.cpp, line 2517
> 2064 [N] WARNING: NS_ENSURE_TRUE(newRoot) failed: file 
> dom/base/nsRange.cpp, line 1132
> 2038 [N] WARNING: NS_ENSURE_TRUE(newRoot) failed: file 
> dom/base/nsRange.cpp, line 1231
> 1912 [N] WARNING: NS_ENSURE_TRUE(rootContent) failed: file 
> editor/composer/nsEditorSpellCheck.cpp, line 715
> 1627 [N] WARNING: Called close() before start()!: 'mStarted', file 
> dom/workers/MessagePort.cpp, line 215
> 1612 [N] WARNING: NS_ENSURE_TRUE(sf) failed: file 
> docshell/base/nsDocShell.cpp, line 6485
> 1488 [N] WARNING: NS_ENSURE_TRUE(isFileURI) failed: file 
> dom/base/ThirdPartyUtil.cpp, line 368
> 1417 [N] WARNING: NS_ENSURE_SUCCESS(rv, false) failed with result 
> 0x: file netwerk/protocol/http/HttpBaseChannel.cpp, line 2077
> 1417 [N] WARNING: NS_ENSURE_SUCCESS(result, result) failed with result 
> 0x: file docshell/base/nsDocShell.cpp, line 14076
> 1393 [N] WARNING: Break suggested inside cluster!: file 
> gfx/thebes/gfxTextRun.cpp, line 220
> 1288 [N] WARNING: NS_ENSURE_TRUE(mDisabledJSAndPlugins) failed: file 
> editor/composer/nsEditingSession.cpp, line 209
> 1175 [N] WARNING: NS_ENSURE_TRUE(txToRemove) failed: file 
> docshell/shistory/nsSHistory.cpp, line 1318
> 1151 [N] WARNING: NS_ENSURE_TRUE(selCon) failed: file 
> editor/libeditor/nsEditor.cpp, line 631
> 1149 [N] WARNING: RemoveObserver() called for unregistered observ

Re: changing the default platform and operating-system on bugzilla.mozilla.org to all / all

[Milan Sreckovic]

Having that field be wrong is worse than not having it, no doubt about that, 
but if we had a way of making sure that field actually contains correct 
information, it would be extremely useful to the graphics team.

I don’t have the numbers, but it certainly feels like a large majority of the 
bugs we get are in fact platform specific.  Even with the current limitation of 
“if it’s more than one, it’s all”, that’s still better than no information at 
all.

If I was going with the “what can we do that’s fairly simple and improves 
things”, I’d create a new value for that field, “Not specified” (or something 
like that) and make that the default.  That way, we differentiate between the 
values that were explicitly set, in which case, I have to hope they will be 
more correct than they are today, and values that were just left at the default 
value.
—
- Milan



On Apr 14, 2015, at 12:18 , Benjamin Smedberg  wrote:

> 
> 
> On 4/14/2015 11:40 AM, Dave Townsend wrote:
>> Are the platform fields actually useful? Most bugs apply to all platforms
>> and in the cases that don't it is normally clear from the bug conversation
>> that it is platform specific. It seems like we rarely go an update the
>> platform fields to match the actual state of the bug. And then there is the
>> problem that OS doesn't allow for multi-selections where say a bug affects
>> a few versions of Windows or Windows and OSX. I've gotten used to just
>> ignoring these fields and reading the bugs instead. I wouldn't feel any
>> loss if they were just removed from display entirely.
> 
> I've suggested this before (and still think that's the right user 
> experience). In fact this turns out to be really difficult to do within 
> bugzilla because those fields are baked into bugzilla guts and removing them 
> would require not just hiding them on the edit-bug page but also from the 
> query pages and various other locations.
> 
> I do think we should try to stop using these fields for anything important.
> 
> --BDS
> ___
> 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: Project Silk on Desktop

[Milan Sreckovic]

Sure - you’ll notice that ordering follows the introduction of OMTC on 
different desktop platforms, and there is only some randomness in that, and you 
may have seen a recent announcement of OMTC on Linux imminent landing.
—
- Milan



On Mar 12, 2015, at 16:16 , Gervase Markham  wrote:

> On 11/03/15 18:12, Mason Chang wrote:
>> Project Silk (http://www.masonchang.com/blog/2015/1/22/project-silk),
>> which aligns rendering to vsync, will be landing over the next couple
>> of weeks (bug 1071275). You should expect smoother animations and
>> scrolling while browsing the web. It'll land in 4 parts, with the
>> vsync compositor on OS X landing today. We'll start landing the vsync
>> compositor on Windows a week or two from now, then the vsync refresh
>> driver's on OSX and Windows a week or two after the vsync compositor.
>> If you have any issues, please file bugs and make them block bug
>> 1071275.
> 
> ObQuestion: what about Linux? :-)
> 
> Gerv
> ___
> 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: Off-main-thread compositing on Linux

[Milan Sreckovic]

Windows get priority, but if all works out, tiling+apz is aimed at 42.
—
- Milan



On Mar 11, 2015, at 12:37 , Nicolas Silva  wrote:

> Tiling is in a usable state (modulo some reftest failures), but I
> haven't tried to run talos with tiling enabled yet. We'll probably see
> the benefit of tiling when we enable APZ (which I don't know the state
> of on Linux). We can also enable OMTA but I haven't tried to run tests
> with it or dogfood it in a while.
> 
> Nical
> 
> 
> On Wed, Mar 11, 2015 at 5:02 PM, Jet Villegas  wrote:
> 
>> Nice! This is big news. WIth Linux getting OMTC, we can also enable
>> off-main-thread animations (OMTA) on all our supported platforms.
>> 
>> Is tiling + OMTC on Linux in a testable state? How do we score on the
>> scrolling performance test in Talos?
>> 
>> --Jet
>> 
>> 
> ___
> 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

Intent to implement: Path2D option for addHitRegion

[Milan Sreckovic]

>From the standard 
>(https://html.spec.whatwg.org/multipage/scripting.html#dom-hitregionoptions-path):

"A Path2D object that describes the pixels that form part of the region.  If 
this member is not provided, or is set to null, the current default path is 
used instead."

The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1129147

Plan to ship in (the current) release 39.

—
- Milan



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

Re: Reconciling async scrolling with onscroll handlers

[Milan Sreckovic]

Reluctantly replying to this, as a complete non-authority on the subject.

I like the idea of “in pages that drop below…” part, where we decide between 
sync and async scrolling based on performance criteria.  I don’t know what it 
would take to implement, but it seems like a reasonable heuristic to try out.  
After all, we already have heuristics where we decide whether to sync or async 
scroll.

I really don’t like the idea of exposing this kind of implementation detail to 
CSS though.  I know we’ve already crossed the line in exposing implementation 
details, and I’m not quite sure why this feels worse than things like “will 
change”, but for some reason it does.  I know I’ve lost the people that go on 
data, as I’m presenting none, but this seems to be a 
“force-synchronous-scrolling” property, regardless of how we call it (and I 
wonder what chance it’d have if that’s what we called it, instead of 
scroll-blocks-on.)

The argument for it also seems a bit handwavy, just like my complaint about it. 
 
—
- Milan



On Feb 15, 2015, at 16:47 , Robert O'Callahan  wrote:

> I talked to Chrome devs last week about the issues they have with page
> onscroll handlers being used to implement scrolling effects (e.g. sticky
> positioning) and how they interact with async scrolling --- something we're
> in the process of running into :-).
> 
> Their current idea is to add a new CSS property "scroll-blocks-on" to let a
> page opt into sync scrolling:
> https://docs.google.com/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit#
> In pages that drop below some performance threshold (e.g. 30fps), the
> browser can disable scroll-blocks-on.
> 
> A more general version of the latter is to have the browser maintain a
> per-document mode switch that's "green" while the document is hitting
> performance targets and "red" when it is not, with an event firing for mode
> changes. In red mode, features like "scroll-blocks-on" would be disabled.
> We could potentially tie in other things here like will-change disabling.
> 
> Rob
> -- 
> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
> owohooo
> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
> oioso
> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
> owohooo
> osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
> ooofo
> otohoeo ofoioroeo ooofo ohoeololo.
> ___
> 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: Screen Capture

[Milan Sreckovic]

Just in case this makes it into bugzilla, this is the bug that’s tracking the 
original proposal:

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

--
- Milan

On Oct 24, 2014, at 11:44 , Eric Rescorla  wrote:

> Here is my writeup of the security issues with this from a while ago:
> http://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html
> 
> As MT says, we already are shipping screen sharing in FF 33. It's
> currently whitelisted, but otherwise it's fairly complete.
> 
> -Ekr
> 
> 
> On Fri, Oct 24, 2014 at 1:08 AM, Jonas Sicking  wrote:
> 
>> On Thu, Oct 23, 2014 at 2:10 PM, Jet Villegas  wrote:
>>> Kicking off this thread to get a discussion on:
>>> 
>>> 1. Web-facing or not?
>> 
>> I think we have to make it web facing. If we want the web to be
>> competitive with other platforms, which I hope we do, we have to
>> expose this functionality.
>> 
>> However it definitely has a lot of
>> 
>>> 2. Security/Privacy concerns
>> 
>> so we'd have to be careful with how we do it. For example always
>> showing an on-screen indicator indicating that the screen is currently
>> shared. And reminding the user that password etc can be read by the
>> remote party.
>> 
>> And forcing the user to explicitly choose the option rather than just
>> clicking a "yes" button (aka 'whatever button') might be a good idea.
>> 
>> It would also be cool to enable sharing just a particular app, or a
>> particular browser tab. This is a problem that I see in native apps
>> often. At some video conference someone wants to share a slideshow,
>> but they end up showing their mail inbox or other open documents that
>> happen to be on screen at the same time.
>> 
>> In fact, we could display a list of running apps/tabs and then add an
>> entry for "full screen". Then force the user to actively choose one of
>> the options in the list before clicking a "share " button.
>> 
>> / Jonas
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: c++ unit test in content process

[Milan Sreckovic]

And as “bad” as it is, it’s as good as it gets, and it will only get worse - 
unless we continue the efforts to make things better.  Sometimes it’s a long 
haul, and you can’t get the approval to spend a lot of time digging out of some 
places, but often even small things help.  
--
- Milan

On Oct 6, 2014, at 11:21 , Jason Orendorff  wrote:

> 
> On 10/03/2014 08:59 AM, Benjamin Smedberg wrote:
>> On 10/3/2014 9:46 AM, Patrick Wang wrote:
>>> The test I am writing is to test an implementation of WebRTC's TCP
>>> socket in content process. These codes are build on top of TCPSocket's
>>> IPDL in C++ and don't have IDL so it cannot be called directly from JS,
>>> and the tests for chrome process version are written with gtest.
>>> Therefore I am thinking of writing a similar one with gtest but run in
>>> content process.
>> 
>> Does the unit of code you're testing include two processes communicating via 
>> IPDL? If so, I think you're going to need something more than a C++ unit 
>> test, and should probably focus your efforts on a more end-to-end 
>> integration test. Setting up IPDL connections and all of the machinery that 
>> goes with that doesn't sounds like something we should be trying in 
>> low-level unit tests.
> 
> I agree.
> 
> This was hard for me to accept when I first started working on the JS engine. 
> It seemed like there should be more C++ unit tests. And maybe if there were, 
> we'd have a better, less spaghetti-coupled design at that level.
> 
> But as it stands, both in the JS engine and in Gecko generally, the 
> dependencies are such that bootstrapping one subsystem usually amounts to 
> firing up the whole thing. Mocking "the rest of the browser" is a long hard 
> road.
> 
> The good news is, using integration test frameworks to test unit 
> functionality works astonishingly, deplorably well in Gecko. A mochitest 
> often lets you target the exact code you wish to test using a tiny amount of 
> HTML and JS. And it isolates your test from all sorts of future C++-level API 
> churn.
> 
> That said, if you see ways to improve the situation, go strong. The reason we 
> have tests and a testing culture here at all is herculean efforts from Rob 
> Sayre and others who saw what needed doing and did it.
> 
> -j
> 
> ___
> 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: Enabling NSPR logging in release builds

[Milan Sreckovic]

Any noticable impact on the binary code size?
--
- Milan

On Oct 3, 2014, at 16:12 , Eric Rahm  wrote:

> Hi all-
> 
> In bug 806819 we're planning on landing a change that allows us to turn on 
> NSPR logging in release builds [1]. To be clear, by default all logging 
> output is disabled, this will just allow you to turn on logging via the same 
> mechanisms [2] that have been available to debug builds and modules that 
> already force logging to be enabled.
> 
> Initial tests show no impact to performance, but of course it's possible 
> there will be unforeseen regressions. Testing included all Talos tests, 
> averaging of mochitest runtimes, and local ad-hoc performance measurements.
> 
> Areas to look out for:
>  * Logging being done in "hot" areas. PR_LOG is no longer a no-op so
>there is a slight amount of overhead with each logging call. If
>your output is truly debug only consider wrapping in a #ifdef DEBUG
>block.
>  * Creating a log message and then logging it. PR_LOG supports printf
>style formatting, so you can save some overhead by using that
>rather than writing to your own buffer.
> 
>For example, if you once had:
> 
>  #ifdef PR_LOGGING
>char* msg = expensiveFunction();
>PR_LOG(module, PR_LOG_DEBUG, (msg));
>  #endif
> 
>You'll want to move to:
> 
>  PR_LOG(module, PR_LOG_DEBUG, ("%s", expensiveFunction()));
> 
> If you're interested in making logging better, please take a look at our meta 
> bug [3] tracking various improvements. There's talk of making improvements to 
> NSPR logging, ditching NSPR logging all together, adding streaming 
> interfaces, switching log levels at runtime, and more. Feel free to join in 
> the conversation.
> 
> Please note: after this change you should never need to use FORCE_PR_LOG (and 
> you'll probably get build errors if you do).
> 
> A few side benefits:
>  * All usage of FORCE_PR_LOG has been removed
>  * Many more files are now eligible for unified building
> 
> -e
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=806819
> [2] 
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR/Reference/Logging
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=881389
> ___
> 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: Experiment with running debug tests less often on mozilla-inbound the week of August 25

[Milan Sreckovic]

--
- Milan

On Aug 21, 2014, at 10:12 , Chris AtLee  wrote:

> On 17:37, Wed, 20 Aug, Jonas Sicking wrote:
>> On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert  wrote:
>>> I have been asked in the past if we really need to run WebGL tests on 
>>> Android, if they have coverage on Desktop platforms.
>>> And then again later, why B2G if we have Android.
>>> 
>>> There seems to be enough belief in test-once-run-everywhere that I feel the 
>>> need to *firmly* establish that this is not acceptable, at least for the 
>>> code I work with.
>>> I'm happy I'm not alone in this.
>> 
>> I'm a firm believer that we ultimately need to run basically all
>> combinations of tests and platforms before allowing code to reach
>> mozilla-central. There's lots of platform specific code paths, and
>> it's hard to track which tests trigger them, and which don't.
> 
> I think we can agree on this. However, not running all tests on all platforms 
> per push on mozilla-inbound (or other branch) doesn't mean that they won't be 
> run on mozilla-central, or even on mozilla-inbound prior to merging.
> 
> I'm a firm believer that running all tests for all platforms for all pushes 
> is a waste of our infrastructure and human resources.
> 
> I think the gap we need to figure out how to fill is between getting per-push 
> efficiency and full test coverage prior to merging.

The cost of not catching a problem with a test and letting the code land is 
huge.  I only know this for the graphics team, but to Ehsan’s and Jonas’ point, 
I’m sure it’s not specific to graphics.  Now, one is preventative cost (tests), 
one is treatment cost (fixing issues that snuck through), so it’s sometimes 
difficult to compare, and we are not alone in first going after the 
preventative costs, but it’s a big mistake to do so.

Now, if we need to save some electricity or cash, I understand that as well, 
and it eventually translates to the cost to the company the same as people’s 
time.  If we can do something by skipping every n-th debug run, sure, let’s try 
it.  We have to make sure that a failure on a debug test run triggers us going 
back and re-running the skipped ones, so that we don’t have any gaps in the 
tests where something may have gone wrong.


> 
>> It would however be really cool if we were able to pull data on which
>> tests tend to fail in a way that affects all platforms, and which ones
>> tend to fail on one platform only. If we combine this with the ability
>> of having tbpl (or treeherder) "fill in the blanks" whenever a test
>> fails, it seems like we could run many of our tests only one one
>> platform for most checkins to mozilla-inbound.
> 
> There are dozens of really interesting approaches we could take here.
> Skipping every nth debug test run is one of the simplest, and I hope we can 
> learn a lot from the experiment.
> 
> Cheers,
> Chris
> ___
> 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: Misunderstood the "Assigned" at bugs! Sorry !!!

[Milan Sreckovic]

What’s the purpose of the “ASSIGNED" status?  If we’re saying that this status 
can be computed from Assigned To field (being set to nobody or something else), 
then why do we still have it?  If it isn’t equivalent, then we may be losing 
some information if we reset it back to New.

--
- Milan

On Jul 9, 2014, at 11:27 , Daniel Holbert  wrote:

> On 07/09/2014 08:16 AM, Gijs Kruitbosch wrote:
>> On 09/07/2014 16:00, Tobias B. Besemer wrote:
>>> My next run would be "Status = Assigned" & "Assigned To =
>>> nob...@mozilla.org" ...
>>> 
>>> Tobias.
>> 
>> Please don't mass change the target milestone flag on bugs (definitely
>> not manually). Same goes for the assignee field.
>> 
>> ~ Gijs
> 
> To be clear, I don't think he's planning on mass-changing the *assignee*
> field -- rather, it sounds like his next plan was to reset Status to
> "NEW", for bugs that are ASSIGNED but have no assignee.
> 
> That seems like a reasonable sort of change to me.  Of course, any
> mass-change in Bugzilla could have unintended consequences or step on
> toes in some obscure component with its own rules; but AFAIK, this
> particular change seems likely to just be a change to better-reflect
> reality.
> 
> (I'm not sure how much value it adds, but I don't see it doing much harm.)
> 
> ~Daniel
> ___
> 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: Rendering meeting, June 30th, 2:30pm PDT

[Milan Sreckovic]

No agenda items at this point.  No rendering meeting today.
--
- Milan

On Jun 24, 2014, at 10:49 , Milan Sreckovic  wrote:

> The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
> It takes place every second Monday, at 2:30pm PDT - if we have an agenda.
> 
> The next meeting is scheduled for Monday, June 30th at 2:30 PM US/Pacific.
> 
> Please send me any agenda items you may have.  If we have none by the end of 
> the week, we will cancel the meeting.
> --
> - Milan
> 

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

Re: Rendering meeting, June 30th, 2:30pm PDT

[Milan Sreckovic]

That would be *June* 30th, thanks to Kats for catching it...
--
- Milan

On Jun 24, 2014, at 10:49 , Milan Sreckovic  wrote:

> The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
> It takes place every second Monday, at 2:30pm PDT - if we have an agenda.
> 
> The next meeting is scheduled for Monday, June 30th at 2:30 PM US/Pacific.
> 
> Please send me any agenda items you may have.  If we have none by the end of 
> the week, we will cancel the meeting.
> --
> - Milan
> 

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

Rendering meeting, July 30th, 2:30pm PDT

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, at 2:30pm PDT - if we have an agenda.

The next meeting is scheduled for Monday, July 30th at 2:30 PM US/Pacific.

Please send me any agenda items you may have.  If we have none by the end of 
the week, we will cancel the meeting.
--
- Milan

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

Re: Proposal for adding named arguments to C++

[Milan Sreckovic]

Works for me.

For the function override in the first place though, the names of the 
parameters are ignored, right?
--
- Milan

On Jun 18, 2014, at 13:01 , Botond Ballo  wrote:

>> One quick question - is this covered in the proposal?
>> 
>> class Base {
>>  virtual int f( int ba, char bb );
>> };
>> 
>> class Derived {
>>  virtual int f( int da, char db );  // is this allowed and does it count
>>  like a base class function override?
>> };
>> 
>> Derived d;
>> Base* b = &d;
>> 
>> // What is the validity of the four cases below?
> 
> The proposal does not address this explicitly. I think the following 
> behaviour falls out naturally:
> 
>> b->f( ba=0, bb=‘c’ );   // valid
>> b->f( da=0, db=‘c’ );   // invalid (1)
>> d.f( ba=0, bb=‘c’ );// invalid (2)
>> d.f( da=0, db=‘c’ );// valid
> 
> since (1) name lookup and overload resolution is based on the static
> type (since they happen at compile time), and (2) when the static type
> is the derived type, the derived name hides the base name.
> 
> I think this behaviour is reasonable. I'm open to being convinced
> otherwise.
> 
> Cheers,
> Botond

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

Re: Proposal for adding named arguments to C++

[Milan Sreckovic]

Very cool.

One quick question - is this covered in the proposal?

class Base {
  virtual int f( int ba, char bb );
};

class Derived {
  virtual int f( int da, char db );  // is this allowed and does it count like 
a base class function override?
};

Derived d;
Base* b = &d;

// What is the validity of the four cases below?

b->f( ba=0, bb=‘c’ );
b->f( da=0, db=‘c’ );
d.f( ba=0, bb=‘c’ );
d.f( da=0, db=‘c’ );


--
- Milan

On Jun 14, 2014, at 14:07 , Botond Ballo  wrote:

> Hello everyone,
> 
> Ehsan and I would like to propose named arguments as a new feature for C++.
> 
> We have a draft proposal paper here: 
>  http://ehsan.github.io/namedargs/namedargs.html
> 
> Any feedback on it would be greatly appreciated!
> 
> (I will not be formally presenting this proposal at the upcoming C++ 
> standards committe meeting in Rapperswil, because we didn't have the 
> proposal ready in time for the pre-meeting mailing. However, I will 
> circulate it to committee members informally, and possibly talk to some
> of them about it while I'm there. Hopefully I can then formally present
> an updated proposal at the following committee meeting in November.)
> 
> Cheers,
> Botond
> ___
> 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

Rendering meeting - next Monday

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, at 2:30pm PDT. 

The next meeting will take place on Monday, June 16 at 2:30 PM US/Pacific if we 
have agenda items.

Please send me any agenda items you may have.  If we have none by the end of 
the week, we will cancel the meeting.
--
- Milan

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

Re: Intent to implement: DOMMatrix

[Milan Sreckovic]

On Jun 5, 2014, at 18:34 , Rik Cabanier  wrote:

> On Thu, Jun 5, 2014 at 3:28 PM, Robert O'Callahan 
> wrote:
> 
>> On Fri, Jun 6, 2014 at 9:07 AM, Rik Cabanier  wrote:
>> 
>>> ...
> 
> 
>> Then there's this case:
>> var m = new DOMMatrix();
>> m.translate(-1,-1);
>> m.translate(1,1);
>> m.isIdentity() == false
>> 
>> I'm OK with that. Maybe we do need a better name though. Invert the
>> meaning and call it "maybeHasTransform()"?
>> 
> 
> That sounds good to me.

That just feels very wrong.  I understand not having an isIdentity() method as 
Benoit proposes.  The argument being “is identity question is more complicated 
than you think, so we won’t let you ask it, and instead you have to do it 
manually, which means you understand what’s going on”.

I don’t understand having isIdentity() method and having it return false when 
you actually have an identity transform.  If it was “hasBeenModified()” or some 
such, I can understand having it behave that way.

I’d much rather have “isIdentityExactly()” or "isCloseToIdentity(float 
tolerance)” for a given definition of tolerance.  Or not have it at all and 
write the JS utility myself.

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

Re: Intent to implement: DOMMatrix

[Milan Sreckovic]

In general, is “this is how it worked with SVGMatrix” one of the design 
principles?

I was hoping this would be the time matrix rotate() method goes to radians, 
like the canvas rotate, and unlike SVGMatrix version that takes degrees...

--
- Milan

On Jun 3, 2014, at 18:26 , Rik Cabanier  wrote:

>> ...
>> 
> 
> That would require try/catch around all the "invert()" calls. This is ugly
> but more importantly, it will significantly slow down javascript execution.
> I'd prefer that we don't throw at all but we have to because SVGMatrix did.

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

Reminder: Rendering meeting today, 2:30pm PDT

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, at 2:30pm PDT. 

The next meeting will take place today, Monday, June 2nd at 2:30 PM US/Pacific 
Please add to the agenda: 
https://wiki.mozilla.org/Platform/GFX/2014-06-02#Agenda 

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 22:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 6:30am 
Brisbane - Tuesday, 8:30am 
Auckland - Tuesday, 11:30am 

http://arewemeetingyet.com/Toronto/2014-06-02/17:30/Rendering%20Meeting

Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366
--
- Milan

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

Rendering meeting, a week from today, Monday, June 2nd 2:30pm PDT

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, at 2:30pm PDT. 

The next meeting will take place on Monday, June 2nd at 2:30 PM US/Pacific 
Please add to the agenda: 
https://wiki.mozilla.org/Platform/GFX/2014-June-2#Agenda 

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 22:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 6:30am 
Brisbane - Tuesday, 8:30am 
Auckland - Tuesday, 11:30am 

http://arewemeetingyet.com/Toronto/2014-06-02/17:30/Rendering%20Meeting

Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Graphics meeting today - cancelled

[Milan Sreckovic]

Well, actually, postponed to the next schedule slot two weeks from today.  The 
agenda that we have so far (OMTC + E10S) should have the Canadian presence, and 
it’s a holiday in Canada today so most of the people are not in the office...
--
- Milan

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

Rendering meeting, *next* Monday 2:30pm PDT

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, at 2:30pm PDT. 

The next meeting will take place *next* Monday, May 19th at 2:30 PM US/Pacific 

Please add to the agenda: 
https://wiki.mozilla.org/Platform/GFX/2014-May-19#Agenda ; currently the plan 
is to talk about OMTC and E10S interplay.

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 22:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 6:30am 
Brisbane - Tuesday, 8:30am 
Auckland - Tuesday, 11:30am 

http://arewemeetingyet.com/Toronto/2014-02-19/17:30/Rendering%20Meeting

Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366
--
- Milan

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

Rendering meeting, today, Monday 2:30pm PDT ("the earlier time")

[Milan Sreckovic]

The Rendering meeting (https://wiki.mozilla.org/Platform/GFX#Biweekly_meetings) 
is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT. 

The next meeting will take place today, Monday, May 5 at 2:30 PM US/Pacific 
Please add to the agenda: 
https://wiki.mozilla.org/Platform/GFX/2014-May-5#Agenda 

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 21:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 5:30am 
Brisbane - Tuesday, 7:30am 
Auckland - Tuesday, 9:30am 

http://arewemeetingyet.com/Toronto/2014-05-05/17:30/Rendering%20Meeting

Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366
--
- Milan

___
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

Rendering meeting, Monday 2:30pm PDT ("the earlier time")

[Milan Sreckovic]

The Rendering meeting (https://wiki.mozilla.org/Platform/GFX#Biweekly_meetings) 
is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT. 

The next meeting will take place on Monday, May 5 at 2:30 PM US/Pacific 
Please add to the agenda: 
https://wiki.mozilla.org/Platform/GFX/2014-May-5#Agenda 

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 21:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 5:30am 
Brisbane - Tuesday, 7:30am 
Auckland - Tuesday, 9:30am 

http://arewemeetingyet.com/Toronto/2014-05-05/17:30/Rendering%20Meeting

Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366
--
- Milan

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

Rendering meeting today, Monday 5:30pm PDT ("the later time")

[Milan Sreckovic]

(Sorry for the late notice, I should have sent this out before the weekend, but 
the holiday meant I missed the reminder.)


The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place today, Monday, April 21 at 5:30 PM US/Pacific
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2014-April-21

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 1:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 8:30am
Brisbane - Tuesday, 10:30am
Auckland - Tuesday, 12:30pm

http://arewemeetingyet.com/Toronto/2014-04-21/20:30/Rendering%20Meeting

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Rendering meeting, Monday (today) 5:30pm PDT ("the later time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place today, Monday, March 24 at 5:30 PM US/Pacific
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2014-March-24

http://arewemeetingyet.com/Toronto/2014-03-24/20:30/Rendering%20Meeting

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366


--
- Milan

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

Rendering meeting, Monday 5:30pm PDT ("the later time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place today, Monday, February 24th at 5:30 PM 
US/Pacific
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2014-February-24

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 1:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 9:30am
Brisbane - Tuesday, 11:30am
Auckland - Tuesday, 12:30pm

http://arewemeetingyet.com/Toronto/2014-02-24/20:30/Rendering%20Meeting

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366


--
- Milan
> 

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

Rendering meeting, Monday 5:30pm PDT ("the later time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place on Monday, February 24th at 5:30 PM US/Pacific
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2014-February-24

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 1:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 9:30am
Brisbane - Tuesday, 11:30am
Auckland - Tuesday, 12:30pm

http://arewemeetingyet.com/Toronto/2014-02-24/20:30/Rendering%20Meeting

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366


--
- Milan

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

Re: [e10s] Changes to the browser.tabs.remote preference in desktop Firefox

[Milan Sreckovic]

Very cool.

Changing the preferences requires restart, I presume?

--
- Milan

On 2014-02-13, at 20:33 , Bill McCloskey  wrote:

> Hi everyone,
> 
> I just wanted to make a quick announcement about preference changes for 
> out-of-process tabs. Bug 960783, which landed recently, added a "New OOP 
> Window" menu option to open a new window with out-of-process tabs. Right now 
> this option is only enabled on Macs because it requires OMTC, but it will 
> move to other platforms as they get OMTC. It's also restricted to nightly.
> 
> This change required some reinterpretation of the existing 
> browser.tabs.remote preference. We use this pref in a fair number of places, 
> so I want to make sure that everyone understands how it works now. This is 
> the new setup:
> 
> If browser.tabs.remote = false, then remote (i.e., out of process) tabs are 
> completely inaccessible. This is how we'll keep this feature disabled in 
> non-nightly builds.
> 
> If browser.tabs.remote = true and browser.tabs.remote.autostart = false, then 
> browser windows will normally be in-process. However, the user will see a new 
> menu option, "New OOP Window" that will open a window with remote tabs. This 
> configuration is now the default in nightly on Macs. For non-OMTC platforms, 
> browser.tabs.remote=false will remain the default.
> 
> If browser.tabs.remote = true and browser.tabs.remote.autostart = true, then 
> browser windows will normally have remote tabs. However, the user will see a 
> new menu option, "New In-process Window" that will open a window with 
> in-process tabs. This configuration is for people who want to test e10s more 
> extensively.
> 
> We're hoping that exposing the "New OOP Window" menu item will make it easier 
> for people to test electrolysis.
> 
> -Bill
> ___
> 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

Rendering meeting, Monday 2:30pm PDT ("the earlier time")

[Milan Sreckovic]

> The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
> It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
> PDT. 
> 
> The next meeting will take place today Monday, Feb 10 at 2:30 PM US/Pacific 
> Please add to the agenda: 
> https://wiki.mozilla.org/Platform/GFX/2014-February-10#Agenda 
> 
> San Francisco - Monday, 2:30pm 
> Winnipeg - Monday, 4:30pm 
> Toronto - Monday, 5:30pm 
> GMT/UTC - Monday, 22:30 
> Paris - Monday, 11:30pm 
> Taipei - Tuesday, 6:30am 
> Brisbane - Tuesday, 8:30am 
> Auckland - Tuesday, 11:30am 
> 
> http://arewemeetingyet.com/Toronto/2014-02-10/17:30/Rendering%20Meeting
> 
> Video conferencing: 
> Vidyo room Graphics (9366) 
> https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 
> 
> Phone conferencing: 
> +1 650 903 0800 x92 Conf# 99366 
> +1 416 848 3114 x92 Conf# 99366 
> +1 800 707 2533 (pin 369) Conf# 99366
> 
> --
> - Milan

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

Rendering meeting, Monday 2:30pm PDT ("the earlier time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT. 

The next meeting will take place on Monday, Feb 10 at 2:30 PM US/Pacific 
Please add to the agenda: 
https://wiki.mozilla.org/Platform/GFX/2014-February-10#Agenda 

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 22:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 6:30am 
Brisbane - Tuesday, 8:30am 
Auckland - Tuesday, 11:30am 

http://arewemeetingyet.com/Toronto/2014-02-10/17:30/Rendering%20Meeting

Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Rendering meeting, Monday 5:30pm PDT ("the later time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place today, Monday, January 27 at 5:30 PM US/Pacific
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2014-January-27

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 1:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 9:30am
Brisbane - Tuesday, 11:30am
Auckland - Tuesday, 12:30pm

http://arewemeetingyet.com/Toronto/2014-01-27/20:30/Rendering%20Meeting

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366
--
- Milan

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

Rendering meeting, Monday 5:30pm PDT ("the later time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place on Monday, January 27 at 5:30 PM US/Pacific
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2014-January-27

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 1:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 9:30am
Brisbane - Tuesday, 11:30am
Auckland - Tuesday, 12:30pm

http://arewemeetingyet.com/Toronto/2014-01-27/20:30/Rendering%20Meeting

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Re: Style guide clarity on C++-isms

[Milan Sreckovic]

I didn't mean no inlining :), I was just talking about the format:

class A
{
public:
  inline int hello {
return 4;
  }
};

vs.

class A
{
public:
  inline int hello();
};

inline int A::hello()
{
  return 4;
}

--
- Milan

On 2014-01-09, at 16:21 , Ehsan Akhgari  wrote:

> ...
> 
>> As another example, I wish we didn't allow this kind of inlining in the 
>> first place; I find having that makes it difficult to read (it takes longer 
>> to scan the class to see what it has in it, because there are the 
>> implementation details in there.)  So, it's already hard for me to read, and 
>> the white space doesn't really make any difference at that point.
> 
> Unfortunately, C++ makes that kind of hard to avoid for performance reasons.

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

Rendering meeting, Monday 2:30pm PDT ("the earlier time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT. 

The next meeting will take place today (for most), Monday, January 13th at 2:30 
PM US/Pacific 

Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2014-January-13

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 22:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 6:30am 
Brisbane - Tuesday, 8:30am 
Auckland - Tuesday, 11:30am 

http://arewemeetingyet.com/Toronto/2014-01-13/17:30/Rendering%20Meeting

Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366 

--
- Milan

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

Re: Style guide clarity on C++-isms

[Milan Sreckovic]

if the goal of the styles is the readability, do we know that people actually 
care which one of the described approaches we use, or is it also the "look, not 
all of these things are the same" that offends us?

For example, I find the consistency of the positioning of {} for the loops and 
conditionals extremely important for readability.  On the other hand, the 
positioning of the opening { in the function definition is just about the 
consistency, but doesn't bother me if there are different usages.

As another example, I wish we didn't allow this kind of inlining in the first 
place; I find having that makes it difficult to read (it takes longer to scan 
the class to see what it has in it, because there are the implementation 
details in there.)  So, it's already hard for me to read, and the white space 
doesn't really make any difference at that point.
--
- Milan

On 2014-01-08, at 14:37 , Trevor Saunders  wrote:

> On Wed, Jan 08, 2014 at 02:24:46PM -0500, Ehsan Akhgari wrote:
>> On 1/7/2014, 7:00 PM, Cameron McCormack wrote:
>>> Ehsan Akhgari wrote:
 Exactly. If we require braces on their own lines for function bodies
 everywhere, we wouldn't need to solve this!
>>> 
>>> Are you sure? :)  There are a bunch of instances of
>>> 
>>>  class A
>>>  {
>>>A(int aMember)
>>>  : mMember(aMamber)
>>>{}
>>>  };
>>> 
>>> through the tree.  Depends how the "braces on new line" rule is written,
>>> of course.
>> 
>> I guess the "close braces for function bodies on their own line"
>> rule is implied.  But you're right, we should be explicit about
>> that!
> 
> I'd argue we should have some sort of exception here because  otherwise
> short ctors are unreasonably long and less readable because there's more
> there.  For example you go from
> 
> public:
>  Foo() mFoo(0) {}
> 
> to
>  public:
>  Foo()
>: mFoo(0)
>  {
>  }
> 
>  which takes a lot more lines for no good purpose.
> 
>  Trev
> 
> 
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Rendering meeting, Moday 2:30pm (the "earlier" time)

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT. 

The next meeting will take "today", Monday, December 16th at 2:30 PM US/Pacific 
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/ 
2013-December-16#Agenda 

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 22:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 6:30am 
Auckland - Tuesday, 11:30am 


Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366 
--
- Milan

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

Rendering meeting, Monday 2;30pm PDT ("the earlier time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT. 

The next meeting will take this coming Monday, December 16th at 2:30 PM 
US/Pacific 
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/ 
2013-December-16#Agenda 

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 22:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 6:30am 
Brisbane - Tuesday, 8:30am 
Auckland - Tuesday, 11:30am 


Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366 
--
- Milan

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

Re: On closing old bugs

[Milan Sreckovic]

Opened that long ago, and haven't been touched for a long time?  Or just opened 
that long ago?
--
- Milan

On 2013-12-04, at 14:15 , Lawrence Mandel  wrote:

> - Original Message -
>> Lawrence Mandel writes:
>> 
>>> - Original Message -
 On 27/11/13 07:36, Gabriele Svelto wrote:
> I'm always tempted to close the former as duplicates of the
> actual fix and the latter as WONTFIX so that they won't show
> up on the following searches but I'm also afraid that closing
> a bug several years old is akin to thread necromancy [1].
 
 Validly closing a bug is not thread necromancy. With Henri's
 concerns in mind, feel free to clean up Bugzilla on bug at a
 time :-)
>>> 
>>> I agree. I don't think that keeping a large backlog of bugs in
>>> limbo - where no one is looking at the bugs or has any intention
>>> to fix any of them - helps anyone. I don't mean to suggest that
>>> we should close out all old bugs but that it is appropriate to
>>> close out old bugs that we don't think warrant any attention.
>> 
>> Someone else may like to fix the bugs, so please don't close the
>> bugs if it is reasonably likely that they may still be present.
>> 
>> To try to be clear, I'm agreeing with Henri and Gerv, but I'm not
>> sure that Lawrence understands.
> 
> I'm taking a stronger stance and suggesting that we should be able to wontfix 
> bugs that likely aren't worth anyone's time or attention. As a concrete 
> example, what is the value in keeping the following bugs open?
> bug 2875 - Core::Networking:HTTP P5 enhancement opened 15 years ago
> bug 3246 - Core::Layout:Block and Inline P3 opened 14 years 9 months ago
> bug 6115 - Core::Networking P3 enhancement opened 14 years 7 months ago
> bug 6796 - Core::Editor P3 bug opened 14 years 6 months ago
> bug 39230 - Core::XUL P3 bug opened 13 years 6 months ago
> 
> In fact, there at 6925 bugs across all Bugzilla products currently in the new 
> or unconfirmed state that were opened more than 10 years ago. I would assert 
> that if a bug hasn't been fixed in 10 years it probably isn't important 
> enough to spend time on now. We can always reopen or refile if the issue 
> becomes more pressing (by anyone's judgement).
> 
> https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&chfield=[Bug%20creation]&chfieldfrom=1995-01-01&chfieldto=2003-01-01&list_id=8772268&query_format=advanced&resolution=---&resolution=DUPLICATE&order=bug_id&limit=0
> 
> Lawrence
> ___
> 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

Rendering meeting, Monday 5;30pm PDT ("the later time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place today, Monday, December 2nd at 5:30 PM 
US/Pacific
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2013-December-2

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 1:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 9:30am
Brisbane - Tuesday, 11:30am
Auckland - Tuesday, 12:30pm

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Rendering meeting, Monday 5;30pm PDT ("the later time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place this coming Monday, December 2nd at 5:30 PM 
US/Pacific
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2013-December-2

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 1:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 9:30am
Brisbane - Tuesday, 11:30am
Auckland - Tuesday, 12:30pm

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Re: HWA and OMTC on Linux

[Milan Sreckovic]

Years from now the stories will go... "I had to walk to school through 10ft 
deep snow, uphill both ways, and when I got there, we had to do OGL compositing 
on the main thread".

Now, all reading this and running Nightly on Linux, and having 
layers.acceleration.force-enabled set, please try to break this so that we can 
find any residual problems :)
--
- Milan

On 2013-11-26, at 18:44 , Nicholas Cameron  wrote:

> This has finally happened. If it sticks, then after this commit 
> (https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=aa0066b3865c) there will 
> be no more main thread OpenGL compositing on any platform. See my blog post 
> (http://featherweightmusings.blogspot.co.nz/2013/11/no-more-main-thread-opengl-in-firefox.html)
>  for details (basically what I proposed at the beginning of this thread).
> ___
> 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: Rendering meeting, Monday 2;30pm PDT ("the earlier time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT. 

The next meeting will take place today, Monday, November 18th at 2:30 PM 
US/Pacific 
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/ 
2013-November-18#Agenda 

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 22:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 6:30am
Brisbane - Tuesday, 8:30am 
Auckland - Tuesday, 11:30am 

Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366 

--
- Milan

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

Rendering meeting, Monday 2;30pm PDT ("the earlier time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media. 
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT. 

The next meeting will take place today, Monday, November 18th at 2:30 PM 
US/Pacific 
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/ 
2013-November-18#Agenda 

San Francisco - Monday, 2:30pm 
Winnipeg - Monday, 4:30pm 
Toronto - Monday, 5:30pm 
GMT/UTC - Monday, 22:30 
Paris - Monday, 11:30pm 
Taipei - Tuesday, 6:30am
Brisbane - Tuesday, 8:30am 
Auckland - Tuesday, 11:30am 

Video conferencing: 
Vidyo room Graphics (9366) 
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 

Phone conferencing: 
+1 650 903 0800 x92 Conf# 99366 
+1 416 848 3114 x92 Conf# 99366 
+1 800 707 2533 (pin 369) Conf# 99366 

--
- Milan

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

Re: Trouble building trunk as debug ASAN on OS X

[Milan Sreckovic]

Thanks - I moved to 3.4 (latest recommended by us) and it solved it as well.
--
- Milan

On 2013-11-01, at 11:53 , Andrew McCreight  wrote:

> I was having a similar problem compiling that file with regular debug builds 
> on OSX.  I solved it by upgrading to clang 3.3.
> 
> Andrew
> 
> - Original Message -
>> Started happening recently, though I'm not sure if it's my system or
>> something changed in our code.  Anyone else able to build ASAN debug on OS
>> X?  I'm using clang.
>> 
>> This is what I get:
>> 
>> 8:23.40 1.
>>  /Users/msreckovic/Repos/mozilla-asan/widget/cocoa/nsChildView.mm:6175:1:
>> current parser token 'void'
>> 8:23.40 2.
>>  
>> /Users/msreckovic/Repos/mozilla-asan/widget/cocoa/nsChildView.mm:2738:15:
>> LLVM IR generation of declaration 'globalDragPboard'
>> 8:23.81 IonFrames-x86-shared.o
>> 8:23.86 TestWebGLElementArrayCache.o
>> 8:24.37 clang: error: unable to execute command: Illegal instruction: 4
>> 8:24.37 clang: error: clang frontend command failed due to signal (use -v to
>> see invocation)
>> 8:24.37 clang version 3.2 (trunk 163716)
>> 8:24.37 Target: x86_64-apple-darwin12.4.0
>> 8:24.37 Thread model: posix
>> 8:24.37 clang: note: diagnostic msg: PLEASE submit a bug report to
>> http://llvm.org/bugs/ and include the crash backtrace, preprocessed source,
>> and associated run script.
>> 8:24.50 Element.o
>> 8:25.00 clang: note: diagnostic msg:
>> 8:25.00 
>> 8:25.01
>> 8:25.01 PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
>> 8:25.01 Preprocessed source(s) and associated run script(s) are located at:
>> 8:25.01 clang: note: diagnostic msg:
>> /var/folders/0y/9xx0_t1x54zc9qnf3rc_8z20gn/T/nsChildView-XPNcRM.mm
>> 8:25.01 clang: note: diagnostic msg:
>> /var/folders/0y/9xx0_t1x54zc9qnf3rc_8z20gn/T/nsChildView-XPNcRM.sh
>> 8:25.01 clang: note: diagnostic msg:
>> 
>> --
>> - Milan
>> 
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Rendering meeting, Monday 5;30pm PDT ("the later time")

[Milan Sreckovic]

(this meeting is scheduled in Pacific time zone; note that means a different 
time for Taipei, New Zealand, Australia, etc. now) 

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place today, Monday, November 4th at 5:30 PM 
US/Pacific
Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2013-November-4

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 1:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 9:30am
Auckland - Tuesday, 2:30pm

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Trouble building trunk as debug ASAN on OS X

[Milan Sreckovic]

Started happening recently, though I'm not sure if it's my system or something 
changed in our code.  Anyone else able to build ASAN debug on OS X?  I'm using 
clang.

This is what I get:

 8:23.40 1. 
/Users/msreckovic/Repos/mozilla-asan/widget/cocoa/nsChildView.mm:6175:1: 
current parser token 'void'
 8:23.40 2. 
/Users/msreckovic/Repos/mozilla-asan/widget/cocoa/nsChildView.mm:2738:15: LLVM 
IR generation of declaration 'globalDragPboard'
 8:23.81 IonFrames-x86-shared.o
 8:23.86 TestWebGLElementArrayCache.o
 8:24.37 clang: error: unable to execute command: Illegal instruction: 4
 8:24.37 clang: error: clang frontend command failed due to signal (use -v to 
see invocation)
 8:24.37 clang version 3.2 (trunk 163716)
 8:24.37 Target: x86_64-apple-darwin12.4.0
 8:24.37 Thread model: posix
 8:24.37 clang: note: diagnostic msg: PLEASE submit a bug report to 
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and 
associated run script.
 8:24.50 Element.o
 8:25.00 clang: note: diagnostic msg:
 8:25.00 
 8:25.01 
 8:25.01 PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
 8:25.01 Preprocessed source(s) and associated run script(s) are located at:
 8:25.01 clang: note: diagnostic msg: 
/var/folders/0y/9xx0_t1x54zc9qnf3rc_8z20gn/T/nsChildView-XPNcRM.mm
 8:25.01 clang: note: diagnostic msg: 
/var/folders/0y/9xx0_t1x54zc9qnf3rc_8z20gn/T/nsChildView-XPNcRM.sh
 8:25.01 clang: note: diagnostic msg:

--
- Milan

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

Re: unified shader for layer rendering

[Milan Sreckovic]

Vlad put in a "let's see if we can cache compiled shaders" bug in a few weeks 
ago, and perhaps that is something we should consider when discussing shaders 
in general.  I didn't know about recompiling when some uniforms change though, 
that's good intel.
--
- Milan

On 2013-10-10, at 15:13 , Jeff Gilbert  wrote:

> I'll also add a note that just because we aren't recompiling doesn't mean the 
> driver isn't.
> If we change enough (or maybe just the correct) uniforms, this can cause the 
> driver to recompile the shader, which is indeed slow. Trying to unify too 
> many shader types might just tickle this.
> 
> Some drivers will shoot us a warning via KHR_debug that we can catch, when 
> shader-recompilation happens.
> 
> -Jeff
> 
> - Original Message -
> From: "Nicolas Silva" 
> To: "Benoit Jacob" 
> Cc: "Benoit Girard" , dev-platform@lists.mozilla.org, 
> "Andreas Gal" 
> Sent: Thursday, October 10, 2013 11:23:45 AM
> Subject: Re: unified shader for layer rendering
> 
> I do appreciate the fact that it reduces complexity (in addition to less
> state changes).
> 
> I agree that the decision of dedicating resources on that rather than on
> other high priority projects that are in the pipes should be motivated by
> some numbers.
> 
> Cheers,
> 
> Nical
> 
> 
> 
> 
> On Thu, Oct 10, 2013 at 11:04 AM, Benoit Jacob 
> wrote:
> 
>> 2013/10/10 Benoit Jacob 
>> 
>>> I'll pile on what Benoit G said --- this is the kind of work that would
>>> require very careful performance measurements before we commit to it.
>>> 
>>> Also, like Benoit said, we have seen no indication that glUseProgram is
>>> hurting us. General GPU "wisdom" is that switching programs is not per se
>>> expensive as long as one is not relinking them, and besides the general
>>> performance caveat with any state change, forcing to split drawing into
>>> multiple draw-calls, which also applies to updating uniforms, so we're
>> not
>>> escaping it here.
>>> 
>>> In addition to that, not all GPUs have real branching. My Sandy Bridge
>>> Intel chipset has real branching, but older Intel integrated GPUs don't,
>>> and I'd be very surprised if all of the mobile GPUs we're currently
>>> supporting did. To put this in perspective, in the world of discrete
>>> desktop NVIDIA GPUs, this was only introduced in the Geforce 6 series.
>>> 
>> 
>> In fact, even on a Geforce 6, we only get full real CPU-like ("MIMD")
>> branching in vertex shaders, not in fragment shaders.
>> 
>> http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter34.html
>> 
>> Benoit
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: unified shader for layer rendering

[Milan Sreckovic]

I didn't see anything in this message that suggested "we should drop everything 
we're doing and start on this right now", but most of the early comments I'm 
seeing are commenting on that.  Let's make that a separate discussion.

If we didn't have all these variations, what would we do?  Would we just do 
one, then add more (and add code complexity) only if we find significant 
performance improvements?  I'd have to go with "probably yes" on that one :)

Let's see if we can focus the discussion on "what should we have", and then on 
"how do we get there", and let's not worry about when and how for now.  Gets in 
the way.

--
- Milan

On 2013-10-10, at 7:59 , Andreas Gal  wrote:

> Hi,
> 
> we currently have a zoo of shaders to render layers:
> 
>  RGBALayerProgramType,
>  BGRALayerProgramType,
>  RGBXLayerProgramType,
>  BGRXLayerProgramType,
>  RGBARectLayerProgramType,
>  RGBXRectLayerProgramType,
>  BGRARectLayerProgramType,
>  RGBAExternalLayerProgramType,
>  ColorLayerProgramType,
>  YCbCrLayerProgramType,
>  ComponentAlphaPass1ProgramType,
>  ComponentAlphaPass1RGBProgramType,
>  ComponentAlphaPass2ProgramType,
>  ComponentAlphaPass2RGBProgramType,
> 
> (I have just eliminated the Copy2D variants, so omitted here.)
> 
> Next, I would like to replace everything but the YCbCr and ComponentAlpha 
> shaders with one unified shader (attached below).
> 
> Rationale:
> 
> Most of our shader programs only differ minimally in cycle count, and we are 
> generally memory bound, not GPU cycle bound (even on mobile). In addition, 
> GPUs are actually are very efficient at branching, as long the branch is 
> uniform and doesn't change direction per pixel or vertex (the driver compiles 
> essentially variants and runs that). Last but not least, switching shaders 
> tends to be expensive.
> 
> Proposed approach:
> 
> We use a single shader to replace the current 8 layer shaders. I verified 
> with the mali shader compiler that the shortest path (color layer) is pretty 
> close to the old color shader (is now 3, due to the opacity multiplication, 
> was 1). For a lot of scenes we will be able to render without ever switching 
> shaders, so that should more than make up for the extra cycles, especially 
> since we are memory bound anyway.
> 
> More uniforms have to be set per shader invocation, but that should be pretty 
> cheap.
> 
> I completely dropped the distinction of 2D and 3D masks. 3D masks should be 
> able to handle the 2D case and the cycle savings are minimal, and as 
> mentioned before, irrelevant.
> 
> An important advantage is that with this approach we can now easily add 
> additional layer effects to the pipeline without exponentially exploding the 
> number of programs 
> (RGBXRectLayerProgramWithGrayscaleAndWithoutOpacityButMaskAndNotMask3D…).
> 
> Also, last but not least, this reduces code complexity quite a bit.
> 
> Feedback welcome.
> 
> Thanks,
> 
> Andreas
> 
> ---
> 
> // Base color (will be rendered if layer texture is not read).
> uniform vec4 uColor;
> 
> // Layer texture (disabled for color layers).
> uniform bool uTextureEnabled;
> uniform vec2 uTexCoordMultiplier;
> uniform bool uTextureBGRA; // Default is RGBA.
> uniform bool uTextureNoAlpha;
> uniform float uTextureOpacity;
> uniform sampler2D uTexture;
> uniform bool uTextureUseExternalOES;
> uniform samplerExternalOES uTextureExternalOES;
> #ifndef GL_ES
> uniform bool uTextureUseRect;
> uniform sampler2DRect uTextureRect;
> #endif
> 
> // Masking (optional)
> uniform bool uMaskEnabled;
> varying vec3 vMaskCoord;
> uniform sampler2D uMaskTexture;
> 
> void main()
> {
>  vec4 color = uColor;
>  if (uTextureEnabled) {
>vec2 texCoord = vTexCoord * uTexCoordMultiplier;
>if (uTextureUseExternalOES) {
>  color = texture2D(uTextureExternalOES, texCoord);
> #ifndef GL_ES
>} else if (uTextureUseRect) {
>  color = texture2DRect(uTexture, texCoord);
> #endif
>} else {
>  color = texture2D(uTexture, texCoord);
>}
>if (uTextureBGRA) {
>  color = color.bgra;
>}
>if (uTextureNoAlpha) {
>  color = vec4(color.rgb, 1.0);
>}
>color *= uTextureOpacity;
>  }
>  if (uMaskEnabled) {
>color *= texture2D(uMaskTexture, vMaskCoord.xy / vMaskCoord.z).r;
>  }
>  gl_FragColor = color;
> }
> 
> ___
> 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

Rendering meeting, Monday 5;30pm PDT ("the later time") - cancelled

[Milan Sreckovic]

With the summit just finished, and no agenda at this point, this meeting is 
cancelled.
--
- Milan

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

Rendering meeting, (today) Monday 2;30pm PDT ("the early time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place today Monday, September 23 at 2:30 PM 
US/Pacific
Please add to the agenda: 
https://wiki.mozilla.org/Platform/GFX/2013-September-23#Agenda

San Francisco - Monday, 2:30pm
Winnipeg - Monday, 4:30pm
Toronto - Monday, 5:30pm
GMT/UTC - Monday, 21:30
Paris - Monday, 11:30pm
Taipei - Tuesday, 5:30am
Auckland - Tuesday, 9:30am

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Rendering meeting, Monday 2;30pm PDT ("the early time")

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place this coming Monday, September 23 at 2:30 PM 
US/Pacific
Please add to the agenda: 
https://wiki.mozilla.org/Platform/GFX/2013-September-23#Agenda

San Francisco - Monday, 2:30pm
Winnipeg - Monday, 4:30pm
Toronto - Monday, 5:30pm
GMT/UTC - Monday, 21:30
Paris - Monday, 11:30pm
Taipei - Tuesday, 5:30am
Auckland - Tuesday, 9:30am

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Re: How to check if an element is visible...

[Milan Sreckovic]

On a side note, fully tracking the visibility of images is bug 847221, but that 
isn't going to tell you if the image is visible, just when it isn't.

--
- Milan

On 2013-09-13, at 10:25 , Benjamin Smedberg  wrote:

> ...
> 
> In general we don't track visibility of objects, and computing one more of 
> these kinds of visibility can be rather expensive. We do have heuristics for 
> plugins to inform them when they can stop painting, but that involves special 
> code on plugin elements to track their layer state, and wouldn't scale to 
> arbitrary elements (and it's focused on painting visibility so that even 
> windows which "cover" the plugin make it invisible).

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

Rendering meeting Monday 5:30pm PDT

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place today Monday, September 9th at 5:30 PM 
US/Pacific.  This is the time that's manageable for Taipei, not so good for 
Europe.

Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2013-September-9

Current agenda:

layout+graphics work week in Paris, October 21-25
TART results and Australis performance
vsync proposal
key layout/graphics B2G performance issue (914143)

Meeting details:

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 0:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 8:30am
Auckland - Tuesday, 12:30pm

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Rendering meeting Monday 5:30pm PDT

[Milan Sreckovic]

The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place upcoming Monday, September 9th at 5:30 PM 
US/Pacific.  This is the time that's manageable for Taipei, not so good for 
Europe.

Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2013-September-9

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 0:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 8:30am
Auckland - Tuesday, 12:30pm

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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