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?
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
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 ha
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 a
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(
On 5/1/2013 2:15 PM, L. David Baron wrote:
On Saturday 2013-04-27 08:26 +1000, Nicholas Nethercote wrote:
On Sat, Apr 27, 2013 at 5:17 AM, Ryan VanderMeulen wrote:
-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
On Saturday 2013-04-27 08:26 +1000, Nicholas Nethercote wrote:
> On Sat, Apr 27, 2013 at 5:17 AM, Ryan VanderMeulen wrote:
> >
> > -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.
>
> If I have a patch
On Wed, May 1, 2013 at 12:47 PM, Ralph Giles 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 d
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
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 🐧 wrote:
> On 5/1/2013 11:21 AM, Benoit Girard wrote:
>
>> I'll be accepting requests to
Yes I had found that one but it was last updated in 2011. I want something
that is updated daily.
On Wed, May 1, 2013 at 12:31 PM, 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 se
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 conf
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 t
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 m
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
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 supp
2013/5/1 Robert O'Callahan
> On Thu, May 2, 2013 at 12:37 AM, Benoit Jacob wrote:
>
>> I am not very familiar with the spec. Could you please give an example of
>> such a filter that would absolutely require multiple passes?
>>
>
> Two GLSL custom filters in a chain, where each filter has its own
On Thu, May 2, 2013 at 1:07 AM, Robert O'Callahan wrote:
> On Thu, May 2, 2013 at 12:37 AM, Benoit Jacob wrote:
>
>> I am not very familiar with the spec. Could you please give an example of
>> such a filter that would absolutely require multiple passes?
>>
>
Looks like Bas's D3D blur code require
On Thu, May 2, 2013 at 12:37 AM, Benoit Jacob wrote:
> I am not very familiar with the spec. Could you please give an example of
> such a filter that would absolutely require multiple passes?
>
Two GLSL custom filters in a chain, where each filter has its own vertex
shader. If I'm not mistaken, d
2013/5/1 Robert O'Callahan
> 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 doin
2013/5/1 Andreas Gal
>
> Should we hide the temporary surface generation (when needed) within the
> API?
>
> GLContext::Composite(Target, Source, EffectChain, Filters)
>
Note: we are trying to re-focus GLContext on being solely that, a class
abstracting an OpenGL context, with only few extra fea
On Wed, May 1, 2013 at 8:20 PM, Andreas Gal 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
On May 1, 2013, at 1:06 AM, "Robert O'Callahan" wrote:
> On Wed, May 1, 2013 at 6:41 PM, Andreas Gal 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.
>
> T
On Wed, May 1, 2013 at 6:41 PM, Andreas Gal 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/filte
On Wednesday, May 1, 2013 7:22:47 PM UTC+12, Andreas Gal wrote:
> On May 1, 2013, at 12:14 AM, Nicholas Cameron
> wrote:
>
>
>
> > 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
> > gen
On May 1, 2013, at 12:14 AM, Nicholas Cameron wrote:
> 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,
Minus support for 3D transforms which bo
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 no
27 matches
Mail list logo
