Re: Implementing CSS/SVG filters

roc and I took the discussion offline and there is another option that might be possible: Instead of creating a separate content effect path and compositor effect path, we could add support for effects to Moz2D, and then implement our compositor via Moz2D. In this world, there would only be 2

Re: Implementing CSS/SVG filters

On Wed, May 1, 2013 at 5:55 PM, Andreas Gal wrote: > On Apr 30, 2013, at 10:36 PM, "Robert O'Callahan" > wrote: > > On Wed, May 1, 2013 at 5:28 PM, Andreas Gal wrote: > >> Should we hide the temporary surface generation (when needed) within the >> API? >> >> GLContext::Composite(Target, Source,

Re: Implementing CSS/SVG filters

On Apr 30, 2013, at 10:36 PM, "Robert O'Callahan" wrote: > On Wed, May 1, 2013 at 5:28 PM, Andreas Gal wrote: > Should we hide the temporary surface generation (when needed) within the API? > > GLContext::Composite(Target, Source, EffectChain, Filters) > > And if multiple shaders or passes ar

Re: Implementing CSS/SVG filters

On Wed, May 1, 2013 at 5:28 PM, Andreas Gal wrote: > Should we hide the temporary surface generation (when needed) within the > API? > > GLContext::Composite(Target, Source, EffectChain, Filters) > > And if multiple shaders or passes are needed, we create a temporary > surface on the fly and then

Re: Implementing CSS/SVG filters

On Apr 30, 2013, at 10:28 PM, Andreas Gal wrote: > > On Apr 30, 2013, at 9:56 PM, "Robert O'Callahan" wrote: > >> On Wed, May 1, 2013 at 4:11 PM, Andreas Gal wrote: >> I wonder whether we should focus on one fast GPU path via GLSL, and have one >> precise, working, I-don't-care-how-slow CPU

Re: Implementing CSS/SVG filters

On Apr 30, 2013, at 9:56 PM, "Robert O'Callahan" wrote: > On Wed, May 1, 2013 at 4:11 PM, Andreas Gal wrote: > I wonder whether we should focus on one fast GPU path via GLSL, and have one > precise, working, I-don't-care-how-slow CPU fallback. > > I agree that should be our top priority, and

Re: Implementing CSS/SVG filters

On Wed, May 1, 2013 at 4:56 PM, Robert O'Callahan wrote: > That's a good point: for optimal performance with simple filters we need > to be able to combine the EffectChain with the filter. However I think > adding filters to the EffectChain is probably not the right way to do that, > because some

Re: Implementing CSS/SVG filters

On Wed, May 1, 2013 at 4:11 PM, Andreas Gal wrote: > I wonder whether we should focus on one fast GPU path via GLSL, and have > one precise, working, I-don't-care-how-slow CPU fallback. I agree that should be our top priority, and it may not be worth doing CPU SIMD at all. But if we can get it

Re: Implementing CSS/SVG filters

OpenCL could definitely do this and it interoperates pretty well with GL, however, its basically not available anywhere. Andreas On Apr 30, 2013, at 9:26 PM, Kevin Gadd wrote: > Could you implement all the filters once in OpenCL to get adequate > performance on-CPU (with simd and threading)

Re: Implementing CSS/SVG filters

Could you implement all the filters once in OpenCL to get adequate performance on-CPU (with simd and threading) and adequate performance on-GPU? It is my understanding that OpenCL can manipulate textures, but I don't know what the constraints are (or whether ordinary users actually have a working O

Re: Implementing CSS/SVG filters

You propose SIMD optimization for the software fallback path. I wonder whether we should focus on one fast GPU path via GLSL, and have one precise, working, I-don't-care-how-slow CPU fallback. All hardware made the last few years will have a GPU we support. Really old XP hardware might not, but

Implementing CSS/SVG filters

This is a fairly important feature that people want to get working on soon, but there are quite a few design issues to settle on before we go too far. I've tried to summarize the requirements, and my ideas about the design, here: https://wiki.mozilla.org/Gecko:AcceleratedFilters Please tear this a

Re: Storage in Gecko

On 26/04/2013 22:18, Andrew Sutherland wrote: Specifically, it does not look like IndexedDB's model; it still does a lot of fsync's in order to maintain the requisite SQL ACID semantics. Right, we can't expect miracles just by moving from SQLite3 to SQLite4, though it still uses an enhanced WA

Re: Storage in Gecko

On 4/30/2013 8:37 AM, Joshua Cranmer 🐧 wrote: On 4/30/2013 12:33 AM, Ehsan Akhgari wrote: On 2013-04-29 1:51 PM, Taras Glek wrote: Writes of data <= ~64K should just be implemented as atomic whole-file read/write operations. Those are almost always single blocks on disk. Writing a whole file a

Re: Storage in Gecko

Ehsan Akhgari Monday, April 29, 2013 22:33 On 2013-04-29 1:51 PM, Taras Glek wrote: * How to robustly write/update small datasets? #3 above is it for small datasets. The correct way to do this is to write blobs of JSON to disk. End of discussion. For an API

Introducing mozilla::Abs to mfbt, replacing std::abs

Mozilla used to use NS_ABS to compute absolute values, but half a year ago we switched to std::abs. Unfortunately, practical experience with std::abs has pointed out various issues with it: the various overloads are confusingly split across multiple headers, std::abs(int64_t) doesn't always wor

Re: Storage in Gecko

On 4/30/2013 12:33 AM, Ehsan Akhgari wrote: On 2013-04-29 1:51 PM, Taras Glek wrote: * How to robustly write/update small datasets? #3 above is it for small datasets. The correct way to do this is to write blobs of JSON to disk. End of discussion. For an API that is meant to be used by add-on

Re: Proposal for an inbound2 branch

On 4/30/2013 11:19 AM, Chris AtLee wrote: It seems like a tree used by a smaller, more focused group of people could cope better with leaving some orange on the tree for short periods of time. Instead of backing out suspect revisions, and closing the tree to wait for the results of the backout to

Re: Proposal for an inbound2 branch

On 02:54, Tue, 30 Apr, Justin Lebar wrote: Is there sanity to this proposal or am I still crazy? If we had a lot more project branches, wouldn't that increase the load on infra dramatically, because we'd have less coalescing? Yes, it would decrease coalescing. I wonder how many tree closures

Re: Fallibility of NS_DispatchTo[Current|Main]Thread

On 4/29/2013 1:32 PM, Kyle Huey wrote: Is it feasible to make these functions infallible? What work would need to be done? The relevant data and discussion of this is in https://bugzilla.mozilla.org/show_bug.cgi?id=803174 --BDS ___ dev-platform mai

Re: Proposal for an inbound2 branch

On 4/30/2013 2:46 AM, Gregory Szorc wrote: > As a counter-proposal, I propose that we start shifting landings to > project branches/twigs. We should aim for a small and well-defined set > of repositories (say 3 to 5) sharing similar automation configuration > and sheriff love. By keeping the number

Re: Proposal for an inbound2 branch

On 4/30/13 8:46 AM, Gregory Szorc wrote: On 4/26/2013 12:17 PM, Ryan VanderMeulen wrote: Specific goals: -Offer an alternative branch for developers to push to during extended inbound closures -Avoid patch pile-up after inbound re-opens from a long closure Specific non-goals: -Reducing infrastr