Re: Implementing CSS/SVG filters
This sounds like an awful lot of work, a lot more than some glue code and code deletion. It sounds like you are proposing to make Moz2D pretty much a general purpose 2D and 3D graphics library, touch (to some effect) the whole of the graphics code, and switch to using new libraries which have not been tested for this purpose and at this scale. All for implementing a new feature which is only fairly important. Given how much time/pain the shadow layers refactoring cost and the time/pain it has taken to get SkiaGL going, this all seems like quite a risk. Surely there is a less drastic way to implement the filters? Perhaps it is worth refactoring the graphics code in this way, but that seems like a different conversation. It certainly should be hidden within the GLContext filter implementation. That probably needs to live somewhere under gfx/gl, since Moz2D will need access to it and Moz2D doesn't depend on layers. At present, and I believe this is a long term goal, Moz2D doesn't know about any of the other Mozilla graphics. So hiding API within GLContext rather than layers won't help. Are there software implementations of GLSL which we can reuse? I imagine that would seriously affect how much effort it would be to have a software implementation of custom filters. Cheers, Nick On Wednesday, May 1, 2013 6:41:38 PM UTC+12, Andreas Gal wrote: 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 backends to Moz2D, Skia/SkiaGL and D2D. Both Skia/SkiaGL and D2D support basically all the effects and filters we want. Where D2D is not available, we can fall back onto SkiaGL via ANGLE, or if all else fails Skia (CPU only, old XP). The compositor is implemented based on Moz2D and has no backend-specific code. layers/opengl layers/d3* can be deleted, mostly. gfx/gl can be deleted as well, for the most part, minus for what SkiaGL needs to bind to the platform GL code. roc points out that we would have to add a couple extensions to Moz2D, including gralloc, tiling, component alpha, and 3D transform. The upside would be that there is exactly one path for effects/filters for content and compositor. To add new filters or to maintain code or features we don't have to go and update 3 different shader representations in 3 text files for 3 platforms plus the content fallback path. Almost all of our gfx code will live above the Moz2D layer, and is platform independent. Since both D2D and Skia/SkiaGL already support (and accelerate) all the filters we want to implement, this exercise would be mostly code deletion and writing some glue code around D2D and SkiaGL. What do people think? Andreas On Apr 30, 2013, at 10:36 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, May 1, 2013 at 5:28 PM, Andreas Gal g...@mozilla.com 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 do the final composite with the given EffectChain. It certainly should be hidden within the GLContext filter implementation. That probably needs to live somewhere under gfx/gl, since Moz2D will need access to it and Moz2D doesn't depend on layers. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing CSS/SVG filters
On May 1, 2013, at 1:06 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, May 1, 2013 at 6:41 PM, Andreas Gal g...@mozilla.com wrote: Both Skia/SkiaGL and D2D support basically all the effects and filters we want. D2D does not support GLSL custom filters. We'd need ANGLE/GLContext integration there. The upside would be that there is exactly one path for effects/filters for content and compositor. To add new filters or to maintain code or features we don't have to go and update 3 different shader representations in 3 text files for 3 platforms plus the content fallback path. I don't think this would affect the amount of work required for filters all that much. I proposed having GLContext-based and a CPU-based filters implementation. If Skia(GL) does everything we need, then we can use it as the basis of those implementations; if it doesn't, that's work we have to do either way. Integrating a filter implementation into each compositor shouldn't be much work. We should probably start with the CPU-based fallback path. We can then try that with SkiaGL to see what the performance looks like (the GLContext-based implementation, essentially). Should we file a couple bugs? I might volunteer for the CPU fallback to get something started. Andreas Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing CSS/SVG filters
On Wed, May 1, 2013 at 8:20 PM, Andreas Gal g...@mozilla.com wrote: We should probably start with the CPU-based fallback path. We can then try that with SkiaGL to see what the performance looks like (the GLContext-based implementation, essentially). Should we file a couple bugs? I might volunteer for the CPU fallback to get something started. Let's give people a few days for more feedback before anyone dives in. Plus I think the API needs to be fleshed out quite a bit more ... fully supporting SVG filters has a lot of subtleties. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing CSS/SVG filters
On 5/1/2013 12:11 AM, Andreas Gal wrote: 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. I'm surprised at this statement, and suspect that it's not true. In general we don't support GPU on most integrated intel graphics hardware on Win7. We are slowly starting to support this on Win8. But we actively blocklist a pretty sizeable chunk of graphics hardware/driver versions even on pretty modern computers. In addition, our desktop strategy has us actively targeting emerging markets where WinXP is the dominant OS and is likely to remain that way for years to come. Perhaps the correct answer here is to not support some kinds of filter effects on older hardware, rather than supporting them in very slow paths. Do we have a sense for whether especially CSS filters would gracefully degrade in general? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Doxygen For Mozilla-Central Modules
I've also come across somebody running doxygen on mozilla code here: http://doxygen.db48x.net/mozilla/html/ It shows up in google searches when you search Mozilla-y class names, but I don't know who or what runs it. Andrew - Original Message - I've started to run doxygen on a fresh mozilla-central by cron once a day in the hopes of encouraging source code documentation. I run doxygen on sub modules only for users that are interested in the output. You can see the latest results here: http://people.mozilla.com/~bgirard/doxygen And here is an example of a non trivial class GLContext: http://people.mozilla.com/~bgirard/doxygen/gfx/classmozilla_1_1gl_1_1GLContext.html You can see my script and configuration files here: https://github.com/bgirard/doxygen-mozilla I'll be accepting requests to run doxygen on additional submodules. There are several problems with the configuration files that could improve the results (e.g. include path) that I do NOT plan on fixing but will gladly accept a pull request. Note that the results appear to be sufficiently useful without these fixes. -Benoit Girard ___ 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: Doxygen For Mozilla-Central Modules
On 5/1/2013 11:21 AM, Benoit Girard wrote: I'll be accepting requests to run doxygen on additional submodules. There are several problems with the configuration files that could improve the results (e.g. include path) that I do NOT plan on fixing but will gladly accept a pull request. Note that the results appear to be sufficiently useful without these fixes. Would it be possible to run doxygen just on the entire dist/idl directory? -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Doxygen For Mozilla-Central Modules
On 13-05-01 9:21 AM, Benoit Girard wrote: I've started to run doxygen on a fresh mozilla-central by cron once a day in the hopes of encouraging source code documentation. I run doxygen on sub modules only for users that are interested in the output. Hooray! You can see my script and configuration files here: https://github.com/bgirard/doxygen-mozilla FWIW, in my experience doxygen's recommended doxygen -g + edit workflow is quite brittle as the supported configuration variable change across versions. You might consider putting only the variables you've changed in your Doxyfiles, relying on the defaults for everything else. -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Doxygen For Mozilla-Central Modules
Right now doxygen runs directly on the source code so it's not trivial to run doxygen on there. I'd be happy to accept a pull that builds and indexes dist/idl. On Wed, May 1, 2013 at 12:35 PM, Joshua Cranmer pidgeo...@gmail.comwrote: On 5/1/2013 11:21 AM, Benoit Girard wrote: I'll be accepting requests to run doxygen on additional submodules. There are several problems with the configuration files that could improve the results (e.g. include path) that I do NOT plan on fixing but will gladly accept a pull request. Note that the results appear to be sufficiently useful without these fixes. Would it be possible to run doxygen just on the entire dist/idl directory? -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing CSS/SVG filters
On 2013-05-01 9:31 AM, Benjamin Smedberg wrote: On 5/1/2013 12:11 AM, Andreas Gal wrote: 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. I'm surprised at this statement, and suspect that it's not true. In general we don't support GPU on most integrated intel graphics hardware on Win7. We are slowly starting to support this on Win8. But we actively blocklist a pretty sizeable chunk of graphics hardware/driver versions even on pretty modern computers. Even when we initially have full support, we still blocklist things pretty frequently, because of driver updates causing stability problems or other even more bizzare things (see the AMD crashers that depend on the precise build of Firefox). Our first priority should be GPU acceleration, just as Andreas says, but a performant CPU implementation would be very useful. Perhaps the correct answer here is to not support some kinds of filter effects on older hardware, rather than supporting them in very slow paths. Do we have a sense for whether especially CSS filters would gracefully degrade in general? Not supporting CSS filters on older or blacklisted hardware doesn't fill me with joy, but it'd be OK. If we can implement it in software, though, it'd be nice if we did. (For example, we implemented 3D transforms in software using Pixman's support.) joe ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Doxygen For Mozilla-Central Modules
On Wed, May 1, 2013 at 12:47 PM, Ralph Giles gi...@mozilla.com wrote: You might consider putting only the variables you've changed in your Doxyfiles, relying on the defaults for everything else. Thanks for the feedback. I started with the config in config/doxygen.cfg.inbut it does seem significantly out of date. I'll take a look if I notice significant problems with the current results. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Stylesheet loaded from privileged channel does not trigger content policy for subresources
My extension is injecting markup and script into content pages from a protocol implemented by my own handler (nsIProtocolHandler). Because in some cases I need script loaded via this protocol handler to have chrome privileges, I am setting the channel owner to the system principal in newChannel(). All of this worked great, but I also need to block certain content loaded via my protocol handler. For this purpose I implemented a content policy (nsIContentPolicy). I noticed that when a stylesheet is loaded using my protocol handler, the content policy's shouldLoad() method is not triggered for subresources loaded by the stylesheet. If I remove the line that sets the owner of the stylesheet's channel to the system principal, then shouldLoad() is triggered for e.g. background images as expected. Is it normal that subresources loaded by a stylesheet from a privileged channel do not trigger the content policy? If so, is there any way around this other than to not have the stylesheet's channel have the system principal? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Doxygen For Mozilla-Central Modules
On 01/05/2013 17:31, Andrew McCreight wrote: I've also come across somebody running doxygen on mozilla code here: http://doxygen.db48x.net/mozilla/html/ It shows up in google searches when you search Mozilla-y class names, but I don't know who or what runs it. Given the domain and comment at https://bugzilla.mozilla.org/show_bug.cgi?id=433206#c7 - that would be db48x aka Daniel Brooks, who has been a Mozilla contributor in various ways for some years - http://db48x.net/resume.html Michael ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stylesheet loaded from privileged channel does not trigger content policy for subresources
On 5/1/13 6:48 PM, Matthew Gertner wrote: Is it normal that subresources loaded by a stylesheet from a privileged channel do not trigger the content policy Yes. Content policy checks are skipped when the loader has system principal. If so, is there any way around this other than to not have the stylesheet's channel have the system principal? There is not. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for an inbound2 branch
Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all of the developers who run things like
fuzzers on ours code. Not everyone's project has enough manpower to get
that level of testing on a project branch before their stuff gets merged
to central/inbound. I personally cannot imagine doing my development in
a project branch silo and deprive myself of the huge advantage that this
kind of testing brings about.
Cheers,
Ehsan
On 2013-04-30 2: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 infrastructure load
-Changing pushing strategies from the widely-accepted status quo (i.e.
multi-headed approach)
-Creating multiple integration branches that allow for simultaneous
pushing (i.e. inbound-b2g, inbound-gfx, etc)
My proposal:
-Create an inbound2 branch identically configured to mozilla-inbound.
-Under normal circumstances (i.e. m-i open), inbound2 will be CLOSED.
-In the event of a long tree closure, the last green changeset from
m-i will be merged to inbound2 and inbound2 will be opened for checkins.
---It will be a judgment call for sheriffs as to how long of a closure
will suffice for opening inbound2.
-When the bustage on m-i is resolved and it is again passing tests,
inbound2 will be closed again.
-When all pending jobs on inbound2 are completed, it will be merged to
m-i.
-Except under extraordinary circumstances, all merges to
mozilla-central will continue to come from m-i ONLY.
-If bustage lands on inbound2, then both trees will be closed until
resolved. Tough. We apparently can't always have nice things.
If you consider that every repository is essentially a clone of
mozilla-central, what we have *now* is effectively equivalent to a
single repository with multiple heads/branches/bookmarks. However, the
different heads/branches/bookmarks differ in:
* How much attention sheriffs give them.
* The automation configuration (coalescing, priority, etc).
* Policies around landing.
* How developers use it.
These are all knobs in our control.
When we say create an inbound2, we're essentially establishing a new
head/branch/bookmark that behaves much like inbound1 with a slightly
different landing policy. If that's what we want to do, sure. I think
it's better than a single, frequently closed inbound.
Anyway, no matter how much I think about this proposal, I keep coming
back to the question of why don't we use project branches more?
Instead of everyone and her brother landing on inbound, what if more
landings were performed on {fx-team, services-central, wood-named
twig, etc}? I /think/ the worst that can happen is merge conflicts and
bit rot. And, we can abate that through intelligent grouping of related
commits in the same repository, frequent merges, and maybe even better
communication (perhaps even automatically with tools that alert
developers to potential conflicts - wouldn't it be cool if you updated a
patch and Mercurial was like o hai - Ehsan recently pushed a Try push
that conflicts with your change: you two should talk.).
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 small, it's easy to figure out
where something should land and it's not too much of an extra burden on
sheriffs. We can still keep inbound, but it should only be reserved for
major, cross-repository landings with multi-module impact (e.g. build
system changes), merges from the main landing repositories (unless we
merge straight to central), and possibly as a backup in case one of the
landing repositories is closed.
We can test this today with very little effort: we figure out how to
bucket commits, re-purpose existing repositories/twigs, and see what
happens. If it works: great - we've just validated that distributed
version control works for Firefox development (as opposed to the
CVS/Subversion workflow we're currently using with inbound). If not, we
can try variations and/or the inbound2 idea.
Is there sanity to this proposal or am I still crazy?
___
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: Doxygen For Mozilla-Central Modules
On 2013-05-01 1:08 PM, Benoit Girard wrote: Right now doxygen runs directly on the source code so it's not trivial to run doxygen on there. I'd be happy to accept a pull that builds and indexes dist/idl. If we decide to do a build, why not run doxygen on dist/include and dist/dom/bindings too? Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
