Re: Intent to implement: -webkit-background-clip:text

On 03/22/2016 04:53 PM, Jet Villegas wrote: > I'm thinking we need two prefs so we cover the prefixed and unprefixed > API as per: > https://lists.w3.org/Archives/Public/www-style/2016Mar/0283.html > > It's a bit odd to have the -webkit parser pref also control the > rendering pref in this case.

Re: Intent to implement: -webkit-background-clip:text

On 03/22/2016 02:16 PM, Mike Taylor wrote: > +1. It has been nice to have a single pref to flip to test for potential > regressions (and for instructing people to do the same thing). That's probably not a big concern here -- even if we ship this with its own dedicated feature-pref, we could still

Re: Skia Content on OS X

On Wed, Mar 23, 2016 at 3:03 AM, Mason Chang wrote: > Hi David, > > The main benefit is architectural with a huge simplification of our > graphics code, with a nice side benefit of performance. As it stands today, > we have multiple different rendering paths for each platform (Linux, OS X, > Wind

Re: Skia Content on OS X

I would like to add to what Mason already said about GPU painting. If one thing is clear, it's that the GPU (as in the many combinations of hardware and drivers out there) is not a reliable platform, especially with gecko's current architecture. We get driver bugs for the simplest things we do and

Re: Intent to implement: -webkit-background-clip:text

I'm thinking we need two prefs so we cover the prefixed and unprefixed API as per: https://lists.w3.org/Archives/Public/www-style/2016Mar/0283.html It's a bit odd to have the -webkit parser pref also control the rendering pref in this case. --Jet On Wed, Mar 23, 2016 at 5:11 AM, Daniel Holber

Re: Linux distro readiness for Rust in Gecko

Henri Sivonen wrote: The comments on https://bugzilla.mozilla.org/show_bug.cgi?id=1175546 suggest that Mozilla deferred relying on GCC bug fixes until after 45 ESR in order for Debian not to have to backport a compiler for oldstable. Is that the case? That is, is Debian's policy already hindering

Re: Linux distro readiness for Rust in Gecko

On Tuesday, March 22, 2016 at 4:06:18 PM UTC-7, Petr Cerny wrote: > i.stake...@gmail.com wrote: > > On Thursday, March 17, 2016 at 4:31:46 PM UTC-4, Henri Sivonen > >> If distro policy bans ongoing cross-compliation, I guess the > >> distro would need to replicate the Rust project's compiler > >> c

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

On Tue, Mar 22, 2016, at 06:51 PM, Brian Smith wrote: > On Tue, Mar 22, 2016 at 3:03 AM, Henri Sivonen > wrote: > > > It seems that the Rust MP4 parser is run a new Rust-created thread in > > order to catch panics. > > > > Is the Rust MP4 parser using panics for flow control (like is common in >

Re: Linux distro readiness for Rust in Gecko

i.stakenvic...@gmail.com wrote: On Thursday, March 17, 2016 at 4:31:46 PM UTC-4, Henri Sivonen If distro policy bans ongoing cross-compliation, I guess the distro would need to replicate the Rust project's compiler compilation version lineage on each architecture after bootstrapping with cross-c

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

On Tue, Mar 22, 2016 at 3:03 AM, Henri Sivonen wrote: > It seems that the Rust MP4 parser is run a new Rust-created thread in > order to catch panics. > Is the Rust MP4 parser using panics for flow control (like is common in JS and Java with exceptions), or only for "should be impossible" situat

Re: Skia Content on OS X

Hi Ben, No, we haven’t done any measurements on battery usage. I would suspect since it’s faster and both CG/Skia used the CPU, it should either use less or be roughly equivalent. If you see any major difference, please file a bug. Thanks, Mason > On Mar 22, 2016, at 9:44 AM, Ben Kelly wrote

Fwd: [TCW] Scheduled Tree Closing Maintenance Window 2016-03-26 06:00a PDT 10 hours

As usual, we have a Tree Closing Window (TCW) this Saturday from 1300 UTC to 2300 UTC. This will be a "soft close" window: we expect some minor delays and recoverable outages. We recommend enjoying the first full weekend of spring/fall. If you do start jobs, you will need to monitor them yourself,

Re: Intent to implement: -webkit-background-clip:text

On 3/22/16 3:11 PM, Daniel Holbert wrote: - Therefore, I'm not sure we get any real-world benefit from guarding this feature with an additional dedicated pref. And there'd be a complexity cost from making sure we test all combinations of pref enabled/disabled states, & do the right thing when

Re: Are we in favour of implementing the client hints header?

On Tue, Mar 8, 2016 at 5:05 AM, Xidorn Quan wrote: > So it seems there were some websites tried to use this, which made its > usage up to 0.06%, but then they abandoned. All of the features above is > used only in ~0.0002% of pages surveyed now, which may indicate its > unpopularity. Not sure why

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

> Ok, so that should be released in about 2 months, right? I believe so, yes! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Skia Content on OS X

Hi Patrick, I don’t have any comprehensive data to back this up. It’s unfortunately more anecdotal with the major observations being that (1) Chrome uses CPU rendering and it mostly seems “fast enough” for normal web content (not discussing webgl/vr/canvas here) and (2) we get lots of stability

Re: Intent to implement: -webkit-background-clip:text

On 03/21/2016 10:38 PM, Jet Villegas wrote: > I'd like to see this guarded by its own pref && layout.css.prefixes.webkit Pushing back on this slightly: - At this point, I don't think it's conceivable that we'd want to ship our webkit compatibility work until we're ready to also ship support for "

Re: Skia Content on OS X

On Tue, Mar 22, 2016 at 12:21 PM, Chris Peterson wrote: > On 3/22/16 9:03 AM, Mason Chang wrote: > >> It’s also quite nice that micro-level optimizations at the backend level >> can mostly be done for us as Skia is optimizing performance with Chrome as >> one of their use cases. >> > > On which p

Re: Skia Content on OS X

On 3/22/16 9:03 AM, Mason Chang wrote: It’s also quite nice that micro-level optimizations at the backend level can mostly be done for us as Skia is optimizing performance with Chrome as one of their use cases. On which platforms does Chrome use Skia? _

Re: Skia Content on OS X

Thanks for the info! This is very interesting to us in Servo. Do you have any performance measurements that support the statement "While it would be nice to use the GPU, we’re not totally confident that using the GPU to render content is quite worth it."? We have evidence on our side to support th

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

On Tue, Mar 22, 2016 at 11:02 AM, wrote: > > My code doesn't currently use panic::recover. What > > happens when somebody doesn't use it and an exception hits the FFI > > boundary? Undefined behavior? > > Technically, yes, undefined behavior. It's specifically undefined to > unwind past an FFI bo

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

> My code doesn't currently use panic::recover. What > happens when somebody doesn't use it and an exception hits the FFI > boundary? Undefined behavior? Technically, yes, undefined behavior. It's specifically undefined to unwind past an FFI boundary. Practically on Linux this will abort the pro

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

On Tue, Mar 22, 2016 at 10:13 AM, wrote: > Ah, no, if using `panic::recover` then it wouldn't translate to a crash (I > believe) as it's just normal execution. I'm confused by this. My code doesn't currently use panic::recover. What happens when somebody doesn't use it and an exception hits th

Re: Skia Content on OS X

Hi David, The main benefit is architectural with a huge simplification of our graphics code, with a nice side benefit of performance. As it stands today, we have multiple different rendering paths for each platform (Linux, OS X, Windows). That means every time we hit a graphics bug, we have to

Re: Intent to implement: -webkit-background-clip:text

Just wanted to say thanks for working on this -- it was a pleasant surprise to come back from PTO and see this nearly done! On 3/21/16 11:59 PM, Ku(顧思捷)CJ wrote: Summary: -webkit-background-clip:text has been available for years in webkit based browsers and has seen widespread usage on the web.

Re: Linux distro readiness for Rust in Gecko

On Tue, Mar 22, 2016 at 9:31 AM, wrote: > Given that I know very little about rust, and putting aside the activities of > Rust upstream's releases in general, what do we expect is going to be needed > here in terms of a rust package to build an ESR vs a regular firefox release? > I assume /

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

Ah, no, if using `panic::recover` then it wouldn't translate to a crash (I believe) as it's just normal execution. If you want a panic in Rust to translate to an abort of the entire process, however, then you've got two options. On one hand you could use the custom panic hook support I mentioned

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

Does this mean that the default behavior in the main-thread FFI case is to abort the process in a way that invokes the crash reporter? Because I think that (along with zero-overhead) what Henri (and I) want. On Tue, Mar 22, 2016 at 9:45 AM, wrote: > Hello! I do agree it is indeed bad to spawn a

Re: Skia Content on OS X

On Tue, Mar 22, 2016 at 11:44 AM, William Lachance wrote: > On 2016-03-22 11:21 AM, Mike de Boer wrote: > >> I was also quite curious, so I started clicking up the hierarchy of that >> bug and ended up at: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1154825#c1 < >> https://bugzilla.mozilla

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

Hello! I do agree it is indeed bad to spawn a new thread for all calls into Rust :). You likely don't want a custom panic handler [1], however, as those are actually more appropriately called "hooks" (just renamed [2]). Instead, the `std::panic::recover` function [3] is what you'll want for the

Re: Linux distro readiness for Rust in Gecko

On Friday, March 18, 2016 at 3:05:25 PM UTC-4, band...@mozilla.com wrote: > > This seems like a workable solution, as horrible as it is. One could > similarly make distro packages of rustc specifically for building firefox > (called 'rustc-fx' for example), and put them on the same ESR upgrade

Re: Linux distro readiness for Rust in Gecko

On Thursday, March 17, 2016 at 4:31:46 PM UTC-4, Henri Sivonen wrote: > On Thu, Mar 17, 2016 at 3:01 PM, Martin Stransky wrote: > > Well, what about other arches? ppc(64), s390, ai64...? > > All architectures currently supported by Fedora, Debian and Ubuntu > (but not Gentoo!) already have LLVM ba

Re: Skia Content on OS X

On 2016-03-22 11:21 AM, Mike de Boer wrote: I was also quite curious, so I started clicking up the hierarchy of that bug and ended up at: https://bugzilla.mozilla.org/show_bug.cgi?id=1154825#c1 (comment 2 is also useful info) Ultimate

Re: Skia Content on OS X

I was also quite curious, so I started clicking up the hierarchy of that bug and ended up at: https://bugzilla.mozilla.org/show_bug.cgi?id=1154825#c1 (comment 2 is also useful info) Ultimate goal: no more checkerboarding in APZ. But Mas

Re: Skia Content on OS X

Out of curiosity, what's the benefit? On 22/03/16 15:44, Mason Chang wrote: > Hi all, > > We're changing the default graphics backend on OS X from CoreGraphics to > Skia. In the best case, you should notice no difference. > > If you see any graphics artifacts on mac, please file a bug and make i

Skia Content on OS X

Hi all, We're changing the default graphics backend on OS X from CoreGraphics to Skia. In the best case, you should notice no difference. If you see any graphics artifacts on mac, please file a bug and make it block bug 1207332 . You can verif

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

On 2016-03-22 9:03 AM, Henri Sivonen wrote: It seems that the Rust MP4 parser is run a new Rust-created thread in order to catch panics. Once we introduce Rust code that intermingles with C++ more, it won't be practical to put all potentially panicing Rust code into dedicated threads. Can we ins

Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

It seems that the Rust MP4 parser is run a new Rust-created thread in order to catch panics. Once we introduce Rust code that intermingles with C++ more, it won't be practical to put all potentially panicing Rust code into dedicated threads. Can we install a custom panic function that detects whet