Re: Changing the representation of rectangles in platform code

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

Re: Doxygen output?

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

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

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 fixe

Re: Quantum Flow Engineering Newsletter #5

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

Re: Quantum Flow Engineering Newsletter #5

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

Re: Switching to per-channel profiles

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

Re: Phabricator Update, July 2017

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 system

Re: Phabricator Update, July 2017

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 an

Re: Phabricator Update, July 2017

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, pass

Re: Keyboard APZ has landed on Inbound

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. Passi

Creating a content process during shutdown...

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 creat

Re: Visual Studio 2017 coming soon

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 bui

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

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...@mozill

Re: Does SSE2 usage still need to be conditional?

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

Re: Does SSE2 usage still need to be conditional?

> 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 pe

Re: Does SSE2 usage still need to be conditional?

% 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: >>>

Re: Does SSE2 usage still need to be conditional?

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 We

Re: Triage Plan for Firefox Components

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

Re: Triage Plan for Firefox Components

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

Re: Triage Plan for Firefox Components

> 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”

Re: Triage Plan for Firefox Components

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 a

Re: Coding style for C++ enums

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

Re: Moving XP to ESR?

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

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, whi

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

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 pr

Re: Reverting to VS2013 on central and aurora

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 no

Re: Reverting to VS2013 on central and aurora

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

Re: Reverting to VS2013 on central and aurora

t 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

Re: All about crashes

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, 2

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

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 m

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

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 on

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

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...@mozil

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

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 th

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

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)

Re: Intent to deprecate: MacOS 10.6-10.8 support

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 P

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

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 ca

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

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 histo

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

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

Disabling non-Skia builds

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 Sk

Re: Disabling non-Skia builds

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 Srecko

Re: OpenVG Azure backend

Sounds like getting the hardware information from the vendors should help. There are some indications that we missed the train, but if there is another train about to be boarded, it'd be good to be on it if it makes sense :-) Milan On 2013-02-25, at 3:18 PM, Jet Villegas wrote: > I see what

Re: OpenVG Azure backend

"Large amount of work" - sure, but it is sort of independent, in that you wouldn't expect to touch a lot of code elsewhere, so it should be easy from the merging point of view. Milan On 2013-02-25, at 2:40 PM, Nicholas Cameron wrote: > On Tuesday, February 26, 2013 8:34:39 AM UTC+13, Jet Vill

Re: OpenVG Azure backend

Makes sense. Milan On 2013-02-27, at 4:54 PM, Anthony Jones wrote: > On 27/02/13 03:07, Milan Sreckovic wrote: >> "Large amount of work" - sure, but it is sort of independent, in that you >> wouldn't expect to touch a lot of code elsewhere, so it should be easy

Re: Moz2D Repository Creation

We also want the ability to make some returns and run the tests without them ever showing up in m-c. So to speak. Especially when it comes to having to back things out. That could perhaps be accomplished with a branch, but you start getting into the situation where others could be updating t

Re: Moz2D Repository Creation

Anyone considering git submodules should definitely take a look at git subtrees and see if that solution is more appropriate for the situation in question. In our case, it may be that we want one approach for something like Moz2D, and another one for something like skis, cairo, etc. Milan On 2

Re: Some data on mozilla-inbound

With extremely limited experience of using try, I know that I would have at times set a flag "stop as soon as you hit a first red on a platform". So, I really like Chris' idea below, as a manual workaround, and a more powerful solution for that. Easier said than done, I imagine... Milan On

Re: Increasing the platform meeting's relevance for engineers

Every good meeting needs a conflict - a meeting about whether we should have the platform meeting would be a great meeting. If we are too large to actually have a meeting where something could be argued or decided, we probably don't need that meeting. Status meetings are useful, but as was p

Re: Increasing the platform meeting's relevance for engineers

e. I think therefore that discussions / debates are > better-suited for our newsgroups or for smaller meetings. > > -Justin Milan On 2013-04-25, at 1:03 PM, Milan Sreckovic wrote: > > Every good meeting needs a conflict - a meeting about whether we should have > the platfo

Re: Increasing the platform meeting's relevance for engineers

On 2013-04-25, at 2:07 PM, Justin Lebar wrote: >> Justin pointed out his earlier post and the apparent disagreement I had with >> it with the >> "pick a long thread topic" example - and he has a point. I meant it as an >> example, and >> didn't say as much, and I meant more to focus on decis

Need for unit testing changing the code?

I'm thinking C++, I imagine JS may have different answers or suggestions. Do we have a precedent or a preferred approach when unit testing requires changes or additions to the code? For example, a public method (which we want to test in the unit test) has a number of side effects, but we don't

Re: Need for unit testing changing the code?

That's an option I should have added to the list, you're right. It does mean we are not exercising the code that we're shipping, but it's probably better than nothing. Milan On 2013-05-30, at 3:46 PM, Joe Drew wrote: > On 2013-05-30 3:14 PM, Milan Sreckovic wrote:

Rendering meeting, Monday June 3, 2:30 PM PST

The next Rendering meeting will take this Monday, June 3rd at 2:30 PM US/Pacific: The Rendering meeting is about all things Gfx, Image, Layout, and Media. It is expected to take place roughly every second Monday. Please first add your agenda items there: https://wiki.mozilla.org/Platform/GFX/

Rendering meeting, today

The next Rendering meeting will take place today, Monday, June 3rd at 2:30 PM US/Pacific: The Rendering meeting is about all things Gfx, Image, Layout, and Media. It is expected to take place roughly every second Monday. Please add your agenda items there: https://wiki.mozilla.org/Platform/GF

Rendering meeting - time change

The next Rendering meeting is in 10 days - Monday June 17th. I'm sending this out early because the time of the meeting has changed. We will start alternating between 5:30pm PDT (next meeting, June 17th) and 2:30pm PDT (the original) time (the meeting after that, July 1st, even with it being h

Rendering meeting, Monday, June 17, 5:30 PM US/Pacific

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, June 17th at 5:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/

Re: Rendering meeting, Monday, June 17, 5:30 PM US/Pacific

n 2013-06-14, at 9:53 , Milan Sreckovic wrote: > > 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, June 17th at 5:

Rendering meeting, "today", Monday, June 17, 5:30 PM US/Pacific

The Rendering meeting is about all things Gfx, Image, Layout, and Media. The next meeting will take place today, Monday, June 17th at 5:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2013-June-17 San Francisco - Monday, 5:30pm Winnipeg - Monday, 7:30pm Toronto -

Re: Bugzilla Keyword Standardization Proposal

Hi Marc, I think this is good, and leads to more clarity than what we have today. I had to squint a bit to get all the information out of the page below, so it may be useful to be a bit more explicit as to what the things will look like in the document itself. A few examples would help as wel

Rendering meeting, Monday July 1, 2:30pm PDT

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, July 1st at 2:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/

Rendering meeting today

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, July 1st at 2:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/

Re: review stop-energy (was 24hour review)

That last thing was another item I found useful in the previous life. When requesting a review from somebody, people could see "this person currently has X items in their review queue". You can ignore that information, but it's there and it may help. It's still probably simpler for the revie

Rendering meeting next Monday 5:30pm PDT (Tuesday in some locations)

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, July 15 at 5:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/20

Re: review stop-energy (was 24hour review)

On 2013-07-12, at 11:46 , Mounir Lamouri wrote: > On 11/07/13 16:43, Neil wrote: >> Milan Sreckovic wrote: >> >>> That last thing was another item I found useful in the previous life. >>> When requesting a review from somebody, people could see "this per

Rendering meeting today, Monday 5:30pm PDT (Tuesday in some locations)

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, July 15 at 5:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/GFX

Rendering meeting, Monday 2:30pm PDT - special topic

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, July 29 at 2:30 PM US/Pacific The agenda is here: https://wiki.mozilla.org/Platform/GFX/2013

Rendering meeting, Monday 2:30pm PDT - special topic

> > 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, July 29 at 2:30 PM US/Pacific > The agenda is here: https://wiki.mozilla.org/Pl

Re: On indirect feedback

I don't see a contradiction here. If the person giving feedback is skilled at doing it, the person receiving it doesn't need to be as skilled in receiving it. if the person receiving feedback is skilled at receiving, the person giving it doesn't need to be as skilled at giving it. If both ar

Rendering meeting on Monday/Tuesday (at time good for Taipei, bad for Europe)

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, August 12th at 5:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platfo

Upcoming rendering meeting on Monday 2:30pm PST

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, August 26th at 2:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platf

Rendering meeting Monday 5:30pm PDT

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 s

Rendering meeting Monday 5:30pm PDT

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

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

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

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

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/

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

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/Plat

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

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

Re: unified shader for layer rendering

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

Re: unified shader for layer rendering

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

Trouble building trunk as debug ASAN on OS X

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 toke

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

(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 m

Re: Trouble building trunk as debug ASAN on OS X

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 > > - Origi

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

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/P

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

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/

Re: HWA and OMTC on Linux

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 br

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

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/

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

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/Platfo

Re: On closing old bugs

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

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

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/Pl

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

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/Platfor

Re: Style guide clarity on C++-isms

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 conditi

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

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.mo

Re: Style guide clarity on C++-isms

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 anothe

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

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

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

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/

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

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

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

> 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

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

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 >

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

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/

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

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/Pla

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

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/G

  1   2   >