Re: Moving Away from Makefile's
On Thu, Aug 23, 2012 at 8:40 AM, Ben Hearsum bhear...@mozilla.com wrote: On 08/22/12 04:38 PM, Gregory Szorc wrote: Let's think of what can be done to secure/limit Python. Disabling import has already been mentioned. That's a start. I think it's worth noting that even if you *do* limit what you can do through some technical means, you still have the option to change that later, disable it some places, etc. It's really easy to get into that game when you're fixing blockers or working on chemspills, too. If someone is that desperate, what would you have them do instead of hack the configuration file? Aren't they likely to respond by doing some even worse hack that gets the job done? I think it makes a ton of sense to use automation to stop developers accidentally doing something they shouldn't. But if someone's desperate enough to disable the automation, and can get a review for it, then I don't think it makes sense to try to stop them. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changing reftest required resolution
On Wed, Aug 29, 2012 at 6:17 AM, L. David Baron dba...@dbaron.org wrote: We don't want to be running our reftests at a size smaller than the accepted max size for reftests at W3C. What is the current required size for W3C reftests? I can't find any documentation of that. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Known Risky Platform Changes Landing in FF18
On Tue, Aug 28, 2012 at 8:20 AM, Alex Keybl ake...@mozilla.com wrote: Quick ping to platform devs - do you all know of any particularly risky changes going in over the next 6 weeks that carry the possibility of regression, especially to B2G? Thanks in advance! Display-list-based-invalidation: https://bugzilla.mozilla.org/show_bug.cgi?id=dlbi Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The current state of Talos benchmarks
On Thu, Aug 30, 2012 at 1:00 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: I agree with that if we talk about performance in general. But this thread is about specific regressions in performance as a result of changeset going into our tree. I don't think the same argument applies here, unless we decide that we don't care about some of the things that we measure on Talos (in which case we should stop running those tests if we're not going to act on their results.) Yeah. Troubled as Talos is, we have had a lot of cases where Talos reported a regression that we tracked down to a real bug in some checkin, and backing out the checkin and fixing it was absolutely the right thing to do. Talos is useful. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Pixel precision
On Tue, Oct 9, 2012 at 10:16 AM, Anthony Jones ajo...@mozilla.com wrote: This formats the float to 6 significant figures, however a float has 7.2 significant figures[1]. A float can contain any integer up to 2^24. Anything more than 999,999 pixels shows in exponent format as 1e+6 and so on. Currently co-ordinates are limited to nscoord_MAX = 2^30. This works out at 2^24 * 64 / 60 which is slightly more than a float can hold. Changing AppendFloat to 7 digits of precision breaks tests that assume 6 digits of precision. Which tests? We should certainly output with all available precision. nsROCSSPrimitiveValue::GetCssText should work with doubles since that seems to be necessary. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Pixel precision
I guess 7 digits of precision beyond the decimal point is overkill. How about we output values rounded to the nearest 1e-6. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Why we avoid making private modifications to NSPR and NSS (was Re: Imported code)
On Sat, Oct 13, 2012 at 3:25 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: In some cases in the past (such as bug 563082), we've needed to change the semantics of some of the NSPR functions to make them work better for some things, such as more precise time measurements, but we've had to implement our own APIs (e.g., http://mxr.mozilla.org/mozilla-central/source/xpcom/ds/TimeStamp_windows.cpp) which we've since heavily optimized (for example, in bug 784859). Would such improvements be interesting to NSPR? I guess in a lot of cases we just don't know whether NSPR would accept a patch if we make one, so we end up implementing our own APIs. One thing is that most of our new library APIs tend to be C++ and NSPR is a C library. I don't think we would want to restrict new APIs to C just so they could be folded into NSPR. (TimeStamp and Mutex, for example, really benefit from being C++ APIs.) Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style change proposal: #pragma once
On Tue, Oct 30, 2012 at 1:13 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: #pragma once does have one drawback (other than being non-standard) and that is if you have the same file in different locations (we have this because our build system copies files around) then the compiler will think these are different files Is that a problem for Mozilla code? It could be. On Windows files get copied from the source directory to dist/include. So it seems to me that if . is on the include path before dist/include, it would be easy for some files to be included twice. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PGO: another test + PGO topcrashes
On Fri, Nov 2, 2012 at 2:19 PM, Dave Mandelin dmande...@gmail.com wrote: (b) Failing that, how about not fixing PGO bugs unless they are reproducible, on a trial basis? If my lifecycle theory is correct, then the total crash rate would stay roughly constant. And I assume that if the crash rate doesn't actually go up, that's OK. If it does, and especially if that can be shown to be due to an increasing number due to outstanding PGO bugs, that would show that we do benefit from fixing them. Seems to me a good start would be to make a number of builds from regularly spaced points in the past, backing out all PGO fixes in all those builds, and examining the code to see if each PGO bug was present. Perhaps you could improve the results by weighting each bug according to its measured topcrash rate while it was present. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for reorganizing test directories
On Fri, Nov 2, 2012 at 2:53 PM, Dave Mandelin dmande...@gmail.com wrote: Sure, it's not some grand thing. I just like things to be nicely organized. And I really did find mochitest paths a hassle and a (small) tax on development effort. You could keep tests near the code and still have a predictable algorithm for mapping test paths. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On Fri, Nov 9, 2012 at 10:14 PM, Zack Weinberg za...@panix.com wrote: The style guide should forbid `using namespace` altogether. Use only what you need. I really don't think it should. I do not want to see source files full of difficult-to-maintain and unnecessary using boilerplate a la Java import. At least with Java imports, there are really good tools for managing the mess; we don't have those tools for C++. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg za...@panix.com wrote: The scenario I'm concerned with is when a .cpp file does 'using namespace A;' and then goes on to define a bunch of its *own* symbols; later someone adds a symbol to namespace A, and gets an unexpected break possibly miles from their own code. I see *avoiding* this phenomenon as the primary *benefit* of namespaces, and it's totally lost if you do 'using namespace' even in .cpp files. I see. Thanks for explaining that. I've never ever seen that happen, though. So I'm reluctant to pay an up-front cost to mitigate a problem whose size is unknown but could be smaller than any other problem we have. (And if it does occur in the future, the problem can still be quite easily fixed then.) Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On Mon, Nov 12, 2012 at 8:37 PM, Jeff Walden jwalden+...@mit.edu wrote: We ended up removing the nested |using| above and making all SpiderMonkey headers qualify everything with mozilla::. We use few enough things from mozilla:: so far that we switched to |using mozilla::RangedPtr| and so on in .cpp files and didn't think twice. The patch itself was pretty big and annoying, but at least we won't have these issues in the future. Why is using mozilla::RangedPtr required; is RangedPtr ambiguous? Concerning the DOM nsDocument case, one possible solution might be to refer to those symbols with a still-qualified but not fully-qualified name. Type inference code uses types:: without much pain; Ion code uses ion:: (inside the js namespace) without much pain, either. These seem like fine solutions. For another data point, WebKit's WTF headers include |using WTF::Vector| and such at the bottom of them, and I have seen grumbling and/or regrets about this decision, as it's caused issues with name conflicts with some of Google's gtest framework. I think everyone agrees that all kinds of using declarations in headers are disallowed. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using anonymous namespace vs 'static'
On Wed, Nov 21, 2012 at 3:19 PM, net...@gmail.com wrote: Maybe there's a specific case where you can reproduce this, but in general I've always been able to set breakpoints in unnamed namespaces. I've tested just now with a simple app in VS2008, VS2010 and VS2012. And on those debuggers it works fine. http://msdn.microsoft.com/en-us/library/0888kc6a%28v=vs.100%29.aspx Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using anonymous namespace vs 'static'
On Wed, Nov 21, 2012 at 4:07 PM, net...@gmail.com wrote:
In VS2010 you can have symbols in your watch window that are in an
anonymous namespace and you can put breakpoints on them. For example:
namespace {
int g = 42;
}
In your Watch window, add g, and you can see 42.
If you have an anonymous namespace inside of another namespace, then they
are not easy to see in your watch window.
Actually that seems quite easy. For example in FrameLayerBuilder.cpp I can
add gMaskLayerImageCache to the watch window with no problems, even though
it's in mozilla::{anonymous namespace}. Maybe it being static as well helps?
But you can still put breakpoints on them.
I don't know how. For example, I don't know how to set a breakpoint by name
on GetMaskLayerImageCache, or ContainerState::ProcessDisplayItems. I have
to open up the source file and click on a line. I also don't know how to
cast to a ContainerState* in the expression evaluator.
That case is not very common though.
Yes, non-toplevel anonymous namespaces do seem to be rare. Unfortunately
that doesn't seem to help me, e.g. I don't know how to set breakpoints by
name on methods of CSSParserImpl, which is in a toplevel anonymous
namespace. Nor can I cast to a CSSParserImpl* in the expression evaluator.
Rob
--
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave — just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.” [Matthew 20:25-28]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Mac Flash crash: need to find a Mac with Intel GMA 950/X3100
Bug 804606 is a pretty bad Flash crash that we're chasing for beta. If you have an old-ish Mac (5 years old?) and about:support shows Intel GMA X3100 or Intel GMA 950 under WebGL Renderer then please try loading Yahoo mail with Flash enabled and Flash hardware acceleration enabled. (You may need to create a Yahoo mail account for this.) If you see Flash crashing when we visit the Yahoo mail page, please reply here or in the bug. Thanks, Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
How hard would it be to incrementally download data for the locales we need? It seems that most users won't ever need the collation tables for Chinese, for example. If we could figure out a way to make them available just-in-time, that could be a win. I assume the relevant APIs are synchronous, so this might not be trivial. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
On Fri, Dec 7, 2012 at 4:25 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Fri, Dec 7, 2012 at 4:08 PM, Norbert Lindenberg mozillali...@lindenbergsoftware.com wrote: This sounds like non-trivial surgery on ICU. Yes, the APIs are synchronous. And we don't know whether the time when a user stumbles onto a Chinese web page that requests Chinese collation is really the best time to download the data - at that time the user may be roaming in China with a U.S. data plan... It may not be easy, but I think it's worth jumping through some hoops to avoid the download size hit. (Not to mention the B2G and Android footprint hit.) One way this could work (straw-man proposal) is that when a locale is requested that we support but haven't yet downloaded data for, we simply start the download and pretend not to support that locale until the download has happened. When the download completes, show an infobar explaining what happened and suggesting the user reload the page. The data-plan issue you mention is real but automated Firefox updates have the same issue ... we could adopt whatever strategy we already have for that. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mac Flash crash: need to find a Mac with Intel GMA 950/X3100
On Fri, Dec 7, 2012 at 1:45 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Bug 804606 is a pretty bad Flash crash that we're chasing for beta. If you have an old-ish Mac (5 years old?) and about:support shows Intel GMA X3100 or Intel GMA 950 under WebGL Renderer then please try loading Yahoo mail with Flash enabled and Flash hardware acceleration enabled. (You may need to create a Yahoo mail account for this.) If you see Flash crashing when we visit the Yahoo mail page, please reply here or in the bug. This has been taken care of by Juan Becerra. Thanks! Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
On Thu, Dec 13, 2012 at 6:10 AM, Jean-Marc Desperrier jmd...@gmail.comwrote: Knowing that in most cases you will be reimplementing in parallel the support the user has added to the OS so that native application can get it. And doing it in parallel means never doing it perfectly the same way. This argument doesn't always work. Often, the OS support for a particular language is really terrible and we can and should do better even if it means being inconsistent with the OS. This is certainly true for the case of font shaping, for example. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++11 atomics in Mozilla
On Fri, Dec 14, 2012 at 12:33 PM, Joshua Cranmer pidgeo...@verizon.netwrote: 3. Similar to #2, the ideal version of a reference counter would be mozilla::Atomicnsrefcnt, mozilla::Unordered (which would make threadsafe refcounting cheaper on our ARM platforms if we compiled with gcc 4.6 or clang 3.1 or newer). However, I'm not sure that no one has written code that relies on atomic operations having memory ordering properties, and I don't want to go through and audit every thread-safe XPCOM class. Is code like this safe in the C++1 Unordered model? Thread 1: int x = obj-v; obj-Release(); Thread 2: obj-Release(); where obj's destructor trashes obj-v. The potential hazard is if thread 1's obj-Release() atomic decrement is reordered to run before the obj-v load has completed, then Thread 2's obj-Release() runs and trashes obj-v, and thread 1 reads the trashed value. For what it's worth, I think asking programmers to even think about such question is insane, so I'd go for full memory barriers and sequential consistency until we have benchmark numbers showing big wins from other choices. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
reproducing bug 808466
Bug 808466 is about changes in selection sometimes not being rendered in a timely manner. Basically you select something and the selection doesn't show up immediately. It will usually show up after some delay. I *think* this is a rendering bug due to DLBI or something related, but I'm not 100% sure (jank can sometimes produce the same effect). Unfortunately no-one knows reliable steps to reproduce the bug. If you've seen the bug, and especially if you know how to reproduce it, please comment in bug 808466. I'd really like to not ship this regression, because it's annoying. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reproducing bug 808466
On Wed, Dec 19, 2012 at 12:23 AM, Dirkjan Ochtman dirk...@ochtman.nlwrote: This sounds similar to https://bugzilla.mozilla.org/show_bug.cgi?id=801555 . I can reproduce something via the steps in https://bugzilla.mozilla.org/show_bug.cgi?id=801555#c16. Thanks!!! Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reproducing bug 808466
On Wed, Dec 19, 2012 at 2:57 AM, Kevin Gadd kevin.g...@gmail.com wrote: Would it be possible to add some instrumentation that would let us dive into this issue once we reproduce it - like a hotkey or toolbar button that would start logging painting and invalidation? When I hit this bug it is usually fairly persistent - i.e. all drag-selection operations on a webpage show the same extremely long delay - so if there was instrumentation like that, I'd be able to use it to record info on the bug the next time I see it. You might be able to debug this using SPS. So install the SPS addon from https://github.com/bgirard/Gecko-Profiler-Addon/raw/master/geckoprofiler.xpiand enable profiling, and maybe we'll get lucky. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing writable [Replaceable] properties
Seems like a reasonable change to me, for the inner*, outer* and screen* properties. I don't know about the others. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On Mon, Dec 31, 2012 at 11:23 AM, Andreas Gal g...@mozilla.com wrote: I think it would be extremely surprising to chrome JS authors if instanceof works differently in content and chrome, resulting in very hard to diagnose bugs. What if we made it work that way in content as well? Yes, ultra-dirty and all that, but in terms of least-surprise, stuff like iframe.contentDocument.documentElement instanceof Node being false is pretty surprising to most authors too. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On Tue, Jan 1, 2013 at 2:08 PM, Bobby Holley bobbyhol...@gmail.com wrote: It also sounds from your initial post that other vendors weren't very receptive to the idea. If so, that's a shame. Maybe we could try again? I interpreted Boris to mean other vendors were apathetic rather than opposed. If it was just apathy, then I think we should go for it and make instanceof magic for WebIDL interface objects in both content and chrome, and try to get specs and other engines to follow suit. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Emacs and vim modelines
I agree with what David said. Also does anyone know if there's any research on how line lengths affect code reading speed? For reading regular text there's definitely an optimal line length: when text lines are too long, then when your eye moves from the end of one line to the start of the next line it can get confused about which line you're on. I don't know if this applies to code, though. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Difficulty with font-face cross-domain restrictions
One reason behind this is: what if you were using a font that wasn't free, but had a license that required you to prevent deep-linking of the font from other sites to where it's hosted on your site? Firefox and IE give you a way to do that. Chrome doesn't. In this case, it's a free font so it doesn't matter, but of course the browser doesn't know that ... unless you tell us via Access-Control-Allow-Origin:*. BTW it's not clear to me why after adding Access-Control-Allow-Origin:*, you still had problems. I assume it's an arcane detail of Web development I'm blissfully ignorant of :-). Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
region of zeroes in Gecko address space
I need a big read-only buffer full of zeroes. On Linux I could mmap /dev/zero read-only, and something similar on Windows/Mac I'm sure, but do we already have code for that, or better yet something like that already mapped into memory? Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
Exactly what control do we have over what gets PGOed? In particular: 1) Are we able to exclude particular object files or libraries from PGO when we link libxul, reducing PGO memory usage for the final link? I think you said yes on IRC. 2) Are we able to collect a set of object files, link them with PGO into a static library, and then link the result into libxul, reducing PGO memory usage for the final link? Given the answer to #1 is yes, I think it's worth going through the contents of libxul and disabling PGO on stuff that we deem unimportant. If the answer to #2 is yes, we can independently-PGO those bits to limit the perf hit. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
On Wed, Jan 23, 2013 at 4:31 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: But note that unless a given code path is examined throughout the profiling phase of a PGO build, PGO will probably have negligible effect on it, if any. The PGO compiler looks for hot code paths and tries to optimize those, so for example if the awesomebar doesn't get examined during the profiling (which it isn't), it is extremely unlikely that turning off PGO on the code responsible for it would have any noticeable change on performance. I don't think this is a safe assumption. Our PGO builds not only do PGO but also Link Time Code Generation which enables cross-module optimizations. I have seen code being heavily optimized under PGO that I would not have expected to be significant in our PGO profile. It wouldn't be that hard to do an experiment to test the impact of PGO/LTCG on code that's not in the profile. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
What about leaving PGO/LTCG enabled for a subset of our modules? Is that not a possible solution? Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Thu, Jan 31, 2013 at 5:34 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-01-30 11:11 PM, Robert O'Callahan wrote: What about leaving PGO/LTCG enabled for a subset of our modules? Is that not a possible solution? I did in fact measure that by disabling PGO/LTCG on all directories except content, dom, layout and xpcom. I can't seem to find the try push right now (and bug 836626 doesn't help), but IIRC that bought us 600MB-700MB. To put that number in context, we have increased the linker memory usage by about 1GB over the past 10 months. Therefore, this will fall under option #2. Can we do it at finer granularity than that? There's a lot under content and dom that aren't critical. Also, reducing the number of directories that are PGO/LTCG should mean that the rate of growth decreases proportionally. Even more than proportionally, if we flip our default for entirely new modules to be non-PGO/LTCG, as I assume we would. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Cycle collection for workers
We're going to want to add worker bindings for canvas (both 2D and WebGL). Over time I expect we'll want worker versions of almost every popular DOM API that doesn't actually require content/layout. We need to be able to share code between worker and main-thread implementations as much as possible. Right now a major blocker for that is that main-thread DOM APIs require cycle collection and workers can't use cycle collection. So, what are the prospects for supporting cycle collection in workers? (I'm talking about independent cycle collectors for each thread, not any kind of cross-thread CC.) Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
On Wed, Feb 13, 2013 at 6:17 AM, Jet Villegas j...@mozilla.com wrote: I assume we would send the same diff we use for DLBI over to the painting thread to minimize the cost. No, the plan is to ship the entire unoptimized display list over to the painting thread and do optimization and DLBI processing there. This should be similar in overall cost to what we do today (but more parallel). How would this new design interact with the current refresh driver scheduling? Not much. The refresh driver would still run on the main thread and work like it does today. The painting thread would be an extra stage whose execution would probably be triggered by the completion of the display list in the refresh driver, i.e. implicitly scheduled by the refresh driver. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
On Wed, Feb 13, 2013 at 9:43 AM, Robert O'Callahan rob...@ocallahan.orgwrote: A large chunk of the work of off-main-thread painting is refactoring display lists to be independent of frames, which definitely can and should be done incrementally and could be done in parallel with the layers refactoring. I still think it should wait till after the layers refactoring so all possible resources are on deck for layers. Also there are a couple of simplifications to the display list stuff I'd like to make before we do this: -- Stop using explict nsDisplayClip items and simply attach clipping data to each display item (making display list construction do what FrameLayerBuilder already does internally). Large numbers of nsDisplayClips slow down display list processing, especially on B2G. -- Make BuildDisplayList infallible. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
On Wed, Feb 13, 2013 at 12:28 PM, Matt Woodrow mwood...@mozilla.com wrote: This is the second half of the plan. Third paragraph of 'Proposed Solution' The basic idea is that the display list owned by the painting thread already contains all the information required to render the page at any scroll position. As dbaron said, we can't do this for literally *any* scroll position. We can't for example create a display list for the entire HTML5 spec. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
Can we compress these screenshots to JPEG or something? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Running mousemove events from the refresh driver
Context: bug 837985. At times we can be flooded by OS-level mousemove events. I think it would make sense to process mousemoves at most once per refresh driver tick. This matters for a couple of reasons: mousemove processing can cause arbitrary JS handlers to run which can do slow things, and also for performance reasons we currently don't flush layout before all mousemoves, but we really should (and we've been burned by bugs where we didn't). If we dispatch mousemoves in the refresh driver that should reduce the impact of having to flush, since the refresh driver flushes layout anyway. I think I'd do this by usurping the synthetic-mouse-move code to dispatch real mousemoves as well, so platform-level mousemove events do nothing but notify the presshell that a mousemove is needed and schedule a refresh driver tick. Can anyone see any problems with this? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Wed, Feb 13, 2013 at 4:45 PM, Rob Arnold tell...@gmail.com wrote: Would you want to predict the mouse location based on past events when you dispatch the synthetic event? I guess it depends on how frequently you get the events but this is done for touches on mobile where the input frequency is close (with 2x) the display frequency. If not, what would the timestamp on the event be? I hadn't thought about that. Is it really necessary? I think without prediction, we'd get the same visual results as we do today. With prediction we might make drags seem to track the mouse a bit better, although it sounds a bit scary to have the user mouse over something they actually didn't. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Wed, Feb 13, 2013 at 5:14 PM, Rob Arnold tell...@gmail.com wrote: I agree; it should be no worse than today. I do have some concerns with dispatching a mouse move event that contains coordinates the mouse may not have been at but the visual results for scrolling ought to be nice. Only other concern is if there are applications that make use of the higher frequency mouse events to do extra processing (ex: a finger painting app would want more samples for curve reconstruction). Otherwise I think it makes sense. I did some tests with various browsers on Windows and we normally only get 60-ish mouse-moves per second max. So if we're keep our frame rate up, we should be OK. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg benja...@smedbergs.uswrote: On what OSes? Windows by default coalesces mouse move events. They are like WM_PAINT events in that they are only delivered when the event queue is empty. See http://blogs.msdn.com/b/oldnewthing/archive/2011/12/19/10249000.aspx This should basically mean that we process mousemove events on windows up to 100% CPU, but we should never be flooded by them. Although I do wonder if WM_MOUSEMOVE has priority over WM_PAINT so that if the mouse is moving a lot, that could affect the latency of WM_PAINT. We are definitely getting flooded. Here's what I think is happening on the page I'm looking at, it's pretty simple: 1) nsAppShell::ProcessNextNativeEvent checks for input events, finds a WM_MOUSE_MOVE, and dispatches it, which takes a little while because this page's mousemove handler modifies and flushes layout on every mouse move. 2) While that's happening, the mouse keeps moving. 3) After processing that WM_MOUSE_MOVE, ProcessNextNativeEvent calls PeekMessage again and finds another WM_MOUSE_MOVE is ready. Go to step 1. 4) Meanwhile the refresh driver timer has fired and queued an event, but we don't get around to running it until NATIVE_EVENT_STARVATION_LIMIT has expired (one second). I suppose we could try ignoring WM_MOUSE_MOVEs when there's a Gecko event pending, but that sounds kinda scary. I think deferring DOM mousemove events to the next refresh driver tick would be safer than that. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Fri, Feb 15, 2013 at 10:14 AM, Benjamin Smedberg benja...@smedbergs.uswrote: I think we should try to process mousemoves as quickly as we can: it's important for certain kinds of drawing apps especially to have as much mouse input as possible, and I doubt that only receiving mouse input at 60fps would be adequate in general. Can we build a very basic layer on top of the OS mousemove events that coalesces them and dispatches them as soon as there are no pending events (native or gecko)? This should solve the problem of starving gecko events (especially refresh driver events). That could starve mousemove events, though. I created http://people.mozilla.com/~roc/mousemove-freq.html. We get up to 120-ish mousemoves per second on my machine in Firefox, and a bit more in IE9, but it caps out at 60fps in Chrome which suggests to me they're doing something like what I suggested already. In that testcase you can artificially limit mousemove frequency to 60 per second. It doesn't make much difference to my drawing, athough I'm poorly coordinately. But wouldn't it make sense for a drawing app to intelligently interpolate between mousemove points anyway, using splines or something? I sort of doubt the difference between 60 points per second and 120 points per second is critical. And I *really* doubt we should design for that constraint. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Fri, Feb 15, 2013 at 4:44 PM, John Volikas fero...@gmail.com wrote: I tried the test on Nightly runnig Windows 7 64bit. I get up to 1000(!) mousemoves per second but I have a Logitech G400 gaming mouse that defaults to a 1000Hz polling rate without Logitech's software. I guess it depends on the peripheral and the OS. The lines are very smooth even with rapid mouse movements. [1] Selecting the checkbox to cap the rate and rapidly moving the mouse around results in a very ugly result though. [2] [1] http://ompldr.org/vaGd2bg/moverate.png [2] http://ompldr.org/vaGd2bw/moveratecapped.png Thanks. That is useful information. Unfortunately it doesn't help me figure out what to do :-). Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Sat, Feb 16, 2013 at 6:16 AM, Steve Fink sf...@mozilla.com wrote: It suggests a solution where a quick handler sees all mouse move events and batches them up, delivering the batches at a lower rate (60fps isn't completely unreasonable). Which is of course completely not spec-compliant. I think it is spec-compliant, actually, if we deliver the batched events as a series of individually dispatched mousemove DOM events. It might even be a reasonable solution. In bug 837985 it wouldn't be quite as good as coalescing --- we'd deliver multiple mouse-move events on each refresh driver tick, and all but the last one would do significant unnecessary work --- but it would stop the refresh driver from being starved so it would make that bug a lot better. The drawing application case would work perfectly. It could mess with the timing of sites that use Date.now() in a mousemove event handler to estimate mouse velocity. On the other hand that is already probably super-inaccurate over very short intervals. We could make event.timeStamp return the right thing anyway, if it's OK for DOM event dispatch order to not match the timeStamp order. I'm still not sure that this approach would be worth implementing. The extra precision for drawing applications doesn't seem like a big win given the mouse isn't a very good drawing tool anyway. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
How about this idea: after processing a WM_MOUSEMOVE event, go into an anti-flood state where WM_MOUSEMOVE is ignored. After we service the Gecko event queue, exit the anti-flood state. This is very simple and I think it would work well for all cases. When DOM mousemove handlers are cheap and there isn't much else going on, we'll be able to fire mousemove at very high rates. But when mousemove handlers are expensive (bug 837985) we'd never delay processing the Gecko event queue (and running the refresh driver) by more than the duration of one mousemove handler. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Tue, Feb 19, 2013 at 11:47 AM, Karl Tomlinson mozn...@karlt.net wrote: Robert O'Callahan writes: How about this idea: after processing a WM_MOUSEMOVE event, go into an anti-flood state where WM_MOUSEMOVE is ignored. After we service the Gecko event queue, exit the anti-flood state. The general approach sounds good. I expect ignored will have to be ignored at least until there is another user input event so that the document will know where the mouse is when a key is pressed. Why? We currently don't do anything to ensure mousemoves are flushed before key events. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Tue, Feb 19, 2013 at 12:44 PM, Karl Tomlinson mozn...@karlt.net wrote: I don't know exactly what happens with WM_MOUSEMOVE, it would seem unfortunate if a WM_MOUSEMOVE with an updated mouse position is not received before key events. Changing the order of events changes the meaning considerably. On Windows key events are already prioritized over mousemoves, by Windows itself. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Tue, Feb 19, 2013 at 1:40 PM, Brian Birtles bbirt...@mozilla.com wrote: I'm not sure if this is a relevant data point but we had an issue[1] with touch event coalescing on fennec that produced poor results for the following drawing application on some devices such as the Dell Streak: http://parapara-editor.**mozlabs.jp/testhttp://parapara-editor.mozlabs.jp/test This application uses splines to interpolate between the points but still the lack of events produced poor results. It was fixed by turning off touch event coalescing. See bug 757680. Thanks, that's helpful. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Tue, Feb 19, 2013 at 8:42 PM, Justin Dolske dol...@mozilla.com wrote: On 2/18/13 10:24 PM, Jonas Sicking wrote: One possible solution is to allow pages to opt in to high-precision mousemove events. Then a drawing program could do that on the mousedown event end opt out again on mouseup. Hmm, we could even do a bit of this today without an opt-in -- throttle events unless you're in a mousedown state. (Or throttle less when in a mousedown state.) That would, roughly, make existing drawing apps work well while also making the common case (not moving while holding a button) faster. Unfortunately bug 837985, the motivator here, happens when the button is down. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Tue, Feb 19, 2013 at 7:24 PM, Jonas Sicking jo...@sicking.cc wrote: But I would expect that in the majority of other cases, each mousemove event will not leave persisted data and dispatching more mouse moves will simply mean that the page will redo the same calculations over and over only. The result is that at best 60 results per second being used to affect what's drawn on screen. One possible solution is to allow pages to opt in to high-precision mousemove events. Then a drawing program could do that on the mousedown event end opt out again on mouseup. Or if it's really lazy opt in for the lifetime of the page. Something like this would have to be coordinated with other vendors of course. Given that it looks like Chrome is throtteling to 60 mousemove events per second, I would expect them to be interested in working on such an API. I think my idea for an anti-flood state makes this unnecessary. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Wed, Feb 20, 2013 at 9:41 AM, Anthony Jones ajo...@mozilla.com wrote: We really have to choices: A. Provide an API that allows applications to specify whether they are type 1 or type 2. It could be implicitly done by including a mouse event history array. B. Automatically prevent flooding (as per roc's suggestion) C. Both of the above. Option A fixes most cases but adds more complexity to the API (although not much). Poorly written applications or slow systems may still end up flooding. Option B will mostly fix the problem but will waste CPU cycles if your application is type 1. We pretty much have to do something automatic, so I think we do B, and then if and when it's worthwhile, A. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Sun, Feb 24, 2013 at 1:41 PM, Neil n...@parkwaycc.co.uk wrote: Robert O'Callahan wrote: I suppose we could try ignoring WM_MOUSE_MOVEs when there's a Gecko event pending, but that sounds kinda scary. I think deferring DOM mousemove events to the next refresh driver tick would be safer than that. Currently we peek for WM_MOUSEFIRST to WM_MOUSELAST, where conveniently WM_MOUSEFIRST == WM_MOUSEMOVE, so couldn't we exclude WM_MOUSEMOVE from the native events that we check for? Then they would get picked up when the system wasn't so busy. WM_MOUSEMOVE events, like other native events, would still take priority over all Gecko events and potentially starve the refresh driver. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: proposal: replace talos with inline tests
Writing a lot of performance tests creates the problem that those tests will take a long time to run. The nature of performance tests is that each test must run for a relatively long time to get meaningful results. Therefore I doubt writing lots of different performance tests can scale. (Maybe we can find ways to eliminate noise in very short tests, but that might be research.) One other thing to keep in mind if we're going to start doing performance tests differently is https://bugzilla.mozilla.org/show_bug.cgi?id=846166. Basically Chris suggests using eideticker for performance tests a lot more. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Wed, Mar 6, 2013 at 8:54 AM, Gavin Sharp ga...@gavinsharp.com wrote:
This line of reasoning can be dangerous, given the presence of
browser-specific code (e.g. if (firefox) { /* use Ci! */ }). But we're
in estimates of likelihood of bustage based on intuition territory,
which can make it difficult to have a productive debate. I imagine
we'll get better data about the potential for bustage impact once this
gets onto Aurora and/or Beta, but prior experience with this kind of
thing has shown that those channels often aren't sufficient for
detecting high-impact web compat changes, so we need to be careful...
Bustage detection rate isn't just a function of the user populations on
each channel; it's also a function of time. Six months of testing on beta
is better than six weeks. I don't know how much better but I'd like to!
Letting changes like this progress to beta and then stay there for several
releases might be a good idea, and if we get some experience with it we
might be able to estimate the value of different lengths of time.
Rob
--
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On Thu, Mar 28, 2013 at 9:42 AM, Bas Schouten bschou...@mozilla.com wrote: - Improve Moz2D development workflow by having faster turnaround time on builds and tests (both local and Try) - Lower the barrier for external contributors, some people have already expressed the desire to work on potential backends we do not wish to invest in ourselves, but have been deterred by the complexity of the checkout/building process. - Improve sharing between Servo/Gecko. - Reduce load on our infrastructure by building and testing only Moz2D stand-alone when a change affects only Moz2D, both on regular builds and try. Seems to me that of those goals, only lower the barrier for external contributors actually *requires* Moz2D to be in a separate repository. Is that right? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On Thu, Mar 28, 2013 at 11:45 AM, Bas Schouten bschou...@mozilla.comwrote: I don't think it works that way. At least it doesn't for me, these time issues don't work that way. There's a context switch involved, those are expensive and there's the feeling of pulling in 2.5 gigs+ onto your hard drive to do something small, for someone else really, not because you get paid for it. Especially when you're for example on a conference with a poor network connection. As another example, currently pushing to try is a very conscious decision for me. Is this test result worth it if it's going to take me 4 hours to get the results on all platforms? I'll have to look at it again tomorrow, maybe I should look a little more if I've done everything to make sure it works. Because I know that by pushing that try run I'm going to put a lot of burden on our infrastructure to see if a small change compiles on all platforms. But pushing to try is something you do a lot. Cloning Moz2D is something you probably only do once. And you probably won't do it at a conference. Additionally all -other- operations on a larger repository are a lot slower, things like top-level diffs, updates, etc. They take seconds or less on small repository, every step of your workflow is more efficient in a more isolated environment. Bisecting is only a small example of this, bisecting inside a small repository with a fast build/test is a process that's done very quickly and is very easy to justify timewise. Bisecting mozilla-central is a hard task that takes a lot of time. Mainly because you have to build all of mozilla-central. Standalone builds and tests of Moz2D would be great and we can do that without putting it in its own repository. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Preparing for the next windows PGO build memory exhaustion
On Sun, Apr 14, 2013 at 3:40 AM, Asa Dotzler a...@mozilla.com wrote: I have a really basic question. Is PGO's performance gains something users are actually going to notice or are we mostly talking about synthetic benchmark pissing contests here? It seems to me that benchmark results affect the beliefs of at least some users. 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
Forcing alphabetical order in moz.build files
I have a request ... can we require lists in moz.build files to be in alphabetical order, and actually enforce with some build-system check? I'm always annoyed by Makefiles where lists are sometimes unordered and it's hard to find items and know where to add items. 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: Forcing alphabetical order in moz.build files
On Thu, Apr 18, 2013 at 3:40 AM, Ms2ger ms2...@gmail.com wrote: On 04/17/2013 07:15 AM, Robert O'Callahan wrote: I have a request ... can we require lists in moz.build files to be in alphabetical order, and actually enforce with some build-system check? I'm always annoyed by Makefiles where lists are sometimes unordered and it's hard to find items and know where to add items. Fully agree, with the exception that I'm not sure this is a safe transformation for *DIRS. Good point. That's fine though, we can just not care about that. Likewise we can not care about conditional blocks. I would simply say that if we have a literal array being appended to one of a known set of order-independent variables (including EXPORTS, CPPSRCS, etc), its elements should be in sorted order. 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: Using a pre-processing flag to auto-disable features in later Beta versions
On Sat, Apr 20, 2013 at 10:34 AM, Asa Dotzler a...@mozilla.com wrote: That would be great -- if we had a significantly larger Aurora population. Right now, the only way to get anything close to decent did we break the web testing is on our Beta channel. I think Daniel was concerned about user-visible features (and I agree with that concern). If we're only going to use this flag for does this break the Web tests, where we expect/hope users will not notice, that sounds fine to me, as long as we stick to that rule. 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: Using a pre-processing flag to auto-disable features in later Beta versions
On Sat, Apr 20, 2013 at 11:27 AM, Asa Dotzler a...@mozilla.com wrote: I don't think it's that black and white. PDF.js and our new Cookie policy are both user facing features and web compat concerns that need a crap ton of compat testing. Hmm, PDF.js yes, maybe click to play too. But for cookie policy, Shumway, and mixed content blocking, the goal is to minimize user impact. 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
Accelerating exact rooting work
On Tue, Apr 23, 2013 at 5:36 AM, Terrence Cole tc...@mozilla.com wrote: Our exact rooting work is at a spot right now where we could easily use more hands to accelerate the process. The main problem is that the work is easy and tedious: a hard sell for pretty much any hacker at mozilla. It sounds worthwhile to encourage developers who aren't currently working on critical-path projects to pile onto the exact rooting project. Getting GGC over the line reaps some pretty large benefits and it's an all-or-nothing project, unlike say pursuing the long tail of WebIDL conversions. If that sounds right, put out a call for volunteers (by which I include paid staff) to help push on exact rooting, with detailed instructions. I know some people who could probably help. 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: Some data on mozilla-inbound
On Wed, Apr 24, 2013 at 11:21 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: - The 'inbound was closed for 15.3068% of the total time due to bustage' number is an underestimate, in one sense. When inbound is closed at 10am California time, it's a lot more inconvenient to developers than when it's busted at midnight California time. More than 3x, according to http://oduinn.com/images/2013/blog_2013_02_pushes_per_hour.png. Although I've been known to bust inbound, I also tend to check in around 2-3am PDT. I think it's important to remember that the optimal bustage rate for inbound is some value greater than zero and varies depending on the time of day. If inbound is never busted then we're wasting try resources testing patches that have a 0.99 probability of landing safely. OTOH, whenever the bustage rate is high enough it's difficult to get things landed, or the sheriffs' ability to detect regressions is impacted, it's too high. That currently seems to be the case so it seems like a good idea to use a highscore list or something like it to exert pressure to use try more until the situation is resolved. 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: Fallibility of NS_DispatchTo[Current|Main]Thread
On Tue, Apr 30, 2013 at 5:32 AM, Kyle Huey m...@kylehuey.com wrote: Is it feasible to make these functions infallible? What work would need to be done? Off the top of my head, I think it probably is feasible. IIRC XPCOM event dispatch can fail for two reasons: OOM, and when the thread has been shut down. We can die on OOM. DispatchToCurrentThread obviously shouldn't happen when that thread has shut down. DispatchToMainThread shouldn't happen after the main thread has shut down either ... I suppose it could due to a bug, but we could just die. 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
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 apart, or better still, constructively add to it :-). Thanks, 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 4:11 PM, Andreas Gal g...@mozilla.com 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 cheaply via Skia or somewhere else, maybe it's worth having. I didn't mean to imply CPU SIMD should be a priority. As for the filters on GLContext, I wonder whether thats really the best approach. Don't most filter applications want to be injected into the shader pipeline instead? We would have to be able to compose filters for that and generate a composite GLSL program from that. So for example we want a BGRXTextureLayer, with Mask3D, with ColorMatrix, and we want GLSL source generated from that. So isn't really what we want a GLSL shader program generator (and cache) that we give an EffectChain and that gives us back a compiled shader? (with added effects including ColorMatrix, etc). 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 filters require multiple passes with intermediate buffers and can't be compiled to a single program. I think to keep basic compositing simple we want an EffectChain to always compile to a single program. So I suspect the best approach might be to pass the EffectChain as an additional parameter to the GLContext filter implementation. However, I'm no expert on GL or GPU programming so I hope the usual suspects will chime in here. (I was deliberately vague about GL objects for the same reason.) 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 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 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: Mac OSX 10.7+ lion style scroll bars landed on m-i
Hooray! Thanks for all the hard work, Stephen. 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: PSA: make -C toolkit/library does not currently work on trunk; use make libs -C toolkit/library instead
On Sat, May 4, 2013 at 9:54 AM, Justin Lebar justin.le...@gmail.com wrote: See https://bugzilla.mozilla.org/show_bug.cgi?id=809430#c39 for details. As roc points out, this has broken |mach build dir|. Stay tuned in the bug if you're interested in whether we resolve this by backing out the change or fixing mach. We have a simple fix toolkit/library/Makefile.in to make the problem go away. 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: We should drop MathML
Let me go on a bit of a rampage about TeX for a bit. TeX is not a markup format. It is an executable code format. It is a programming language by design! (It's a very poor programming language, but let's ignore that for the moment.) You run a TeX program to generate the rendered output. This has some major implications: -- It's very hard to write a universal WYSIWYG editor. While I was still in research I tried various WYSIWYG TeX editors. They all sucked because it's an intractable problem. That's not a problem for programmers, mathematicians and scientists who are used to writing everything in plaintext with emacs. It is for everyone else. -- You have an edit/compile/debug cycle and your Tex can fail with compilation/runtime errors. Catastrophic fail document content models (like XML) really suck for Web content. (Yes, MathML is XML, but people can and should use the HTML embedding which avoids this problem.) (Because I like WYSIWYG and I don't like edit/compile/debug cycles and TeX is atrocious as a language, I tried to avoid it in my research. I published a POPL paper full of type theory written in Mircrosoft Word (which is totally unheard of), and wrote my thesis which also include a lot of semantics and type theory in FrameMaker, which was actually pretty good but is very dead. (I had an officemate who wrote his thesis in Scribe, which was very dead even in the mid-90s!)) You could try to fix TeX's problems in a new math language, but computer scientists have been talking about that for decades and nobody has. Of course, computer scientists and mathematicians would probably continue to prefer a Turing-complete language, which is fine for them but again, not suitable for normal users for the above reasons. And of course, to the extent you change TeX, you break compatibility with TeX, which is much of its appeal in the first place. 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: We should drop MathML
On Mon, May 6, 2013 at 6:14 PM, Robert O'Callahan rob...@ocallahan.orgwrote: wrote my thesis which also include a lot of semantics and type theory in FrameMaker, which was actually pretty good but is very dead. Correction: it's alive! Amazing. 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: We should drop MathML
On Tue, May 7, 2013 at 7:12 AM, Benoit Jacob jacob.benoi...@gmail.comwrote: How many specific domains will want to have their own domain-specific markup language next? Chemistry? Biology? Electronics? Music? Flow charts? Calligraphy? This is a good question to ask, but I think it would help if there are specific vocabularies we can use as examples. I think we can safely say that mathematics is a more compelling domain for Web content than all those other domain. For years we've had a MathML WG in the W3C and as far as I know, none of those other domains have ever wanted a WG at the W3C --- at least, they haven't had one. Likewise we've had and still have a lot of people pushing for browser support for math, and I haven't ever noticed anyone pushing for browser support for those other domains. I think you can also look at Wikipedia and see a lot of use of math, but relatively little use of content in those other domains. Probably because math is a much more general tool than those other domains. Another thing to consider is how amenable to automatic layout/presentation a particular XML vocabulary is. I know good automatic music layout is very difficult. For flow-charts, and I suspect chemistry, it is too. For biology I don't even know what the browser would do. If there's no known good automatic layout algorithm then obviously browser rendering of content doesn't make much sense. One domain you didn't list where I *have* seen pressure for built-in browser support is maps. Some people want to extend SVG with features to support maps, so a browser can just render a map without specialized Web app support. I don't think that is a good idea because good map layout algorithms are really difficult (e.g. placing labels). Also, mapping applications invariably have a lot of functionality that wouldn't make sense to add to the browser --- direction finding, for example --- so it's hard to imagine users wanting to use maps outside of the context of some Web application. There's almost no benefit to anyone supporting maps outside the context of a mapping Web application. 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: We should drop MathML
Hopefully Web Components will provide a good solution to let authors extend the browser with support for vocabularies that can be rendered via a straightforward decomposition to HTML or MathML or SVG. I think the layout requirements of MathML are too onerous for MathML to be reduced to HTML or SVG that way. While diagrams such as chemical formulae, flowcharts or electronics schematics can be compiled to SVG, the layout step is very much nontrivial and I don't think Web Components is enough for that. Web Components plus some JS to do the layout is probably satisfactory. 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: Extending the text-overflow/overflow property to support fading out
I'm pretty sure an unconditional mask with a linear gradient on the right-hand-end of the text could be achieved using 'mask-box-image' and slicing appropriately: http://www.w3.org/TR/css-masking/#the-mask-box-image. That's not currently implemented in Gecko, but it's worth implementing. A pure-CSS solution that makes the mask conditional on the text overflowing can't be implemented using any existing spec. I agree an extension to text-overflow would make the most sense. 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: Code Review Session
On Fri, May 24, 2013 at 10:50 PM, Justin Lebar justin.le...@gmail.comwrote: If we do, we risk ending up with yet another crappy non-solution to a real problem (see bugzilla interdiff, splinter integration, and so on). I think that's quite unfair to the people who integrated Splinter. It's not everything I want, but I like it a lot better than what we had before. 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: Heads up: difference in reference counting between Mozilla and WebKit worlds
I believe that in Webkit you're not supposed to call new directly. Instead you call a static create method that returns the equivalent of already_AddRefed. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
I think APIs which only Mozilla is interested in at that time needs clarification that this refers to APIs that solve use cases that only Mozilla is interested in. If other vendors are interested in those use-cases, but don't like our API proposal, we can't just brush that off. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
On Tue, Jun 25, 2013 at 3:08 PM, Brian Smith bsm...@mozilla.com wrote: At the same time, I doubt such a policy is necessary or helpful for the modules that I am owner/peer of (PSM/Necko), at least at this time. In fact, though I haven't thought about it deeply, most of the recent evidence I've observed indicates that such a policy would be very harmful if applied to network and cryptographic protocol design and deployment, at least. I think you should elaborate, because I think we should have consistent policy across products and modules. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
On Wed, Jun 26, 2013 at 4:15 AM, Mounir Lamouri mou...@lamouri.fr wrote: 3. APIs solving use cases which no browser vendor shipping an engine other Gecko is interested in at that time. In cases such as this, Mozilla will solicit feedback from as many relevant parties as possible, begin the standardization process with a relevant standards body, and create a test suite as part of the standards process. An example of this is the Push Notifications API. I am not a big fan of that exception. Given how fast paced the Web is nowadays, we could easily put a lot of APIs in that category. I don't see this. Can you give some examples? Actually, if we ask other vendors what they think about most Firefox OS APIs, we will very likely get no answer. Does that mean that those APIs are good to go? If no answer means we don't care about your use cases, then we can't let that block our progress, because there are always going to be use-cases we need to solve that no other vendor is currently interested in. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
On Thu, Jun 27, 2013 at 3:59 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-06-26 9:09 AM, Robert O'Callahan wrote: If we think these use cases are (or ever will be) relevant, we need to give feedback even if we don't plan to implement them soon. We should at least try to make sure these APIs are something we wouldn't feel bad about implementing, and complain if they are. I don't think that in practice we can expect other vendors to give us feedback on all proposed APIs, or that we give them feedback on their proposed APIs. I agree, which is why the default for the no-feedback situation has to be forward progress, not deadlock. For whatever it's worth, Blink has made the decision to implement Web MIDI without receiving any feedback from us (and to the best of my knowledge from other vendors), and has also made the decision to ship requestAutocomplete hoping that Hixie will add it to the spec before it hits the Chrome release channel. In the case of Web MIDI at least they have asked us to give feedback on a few occasions, but we've been unable to do so because of not having enough resources. But it looks like they're also interested in making progress on the features that are only interesting to them while making an effort to solicit feedback from other engine vendors. I think they've done the right thing here for Web MIDI. They've produced a spec, invited feedback, and confirmed that at least we don't have objections. So, are you proposing that we should give feedback on all APIs even if they're not interesting to us? I think we should try. So, we should try to have someone carve out some time to review Web MIDI, at least to the point where we feel confident it would make sense to implement. I'd be fine with that, but I don't think we can assume that it will be reciprocated. That doesn't matter. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On Wed, Jul 10, 2013 at 3:26 PM, Justin Lebar justin.le...@gmail.comwrote: If I can propose something that's perhaps different: 1) Write software to figure out who's slow with reviews. 2) We talk to those people. We've done this before too. But we should just do it again --- the definition of insanity aphorism is nonsense. Repetition helps people learn. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
We can't have a rigid rule about 24 hours. Someone requesting a review from me on Thursday PDT probably won't get a response until Monday if neither of us work during the weekend. But I think it's reasonable to expect developers to process outstanding review requests (and needinfos) at least once every regular work day. Processing includes leaving a comment with an ETA. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On Wed, Jul 10, 2013 at 2:48 PM, Jeff Walden jwalden+...@mit.edu wrote: Reviewer-side: I've lately tried to minimize my review turnaround time such that I get things done, roughly FIFO, before I get a review-nag mail. I can approximately do that, while keeping up with most of my coding. Establishing one-day turnaround time on reviews, or on requests, would require a lot more polling on my review queue. And I don't think that's a good thing, context-switching from coding tasks being pretty expensive for any developer. I think a reasonable expectation is that paid staff process outstanding review requests at least once every regular work day. If you do it at the beginning of the day, before diving into your other work, it won't interrupt that other work. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
While I think your observations are useful, I think (hope!) you are a massive outlier and I don't think we should design a policy based on the assumption that your review commitments are in any way normal. I would be totally OK with a policy that explicitly applies to everyone except you. Or, we could parameterize it with a dynamic list of exceptions who are known to be overloaded with reviews. In fact, making that list explicit and publishing it would let people know not to request reviews from people on that list except as a last resort (which is, in fact, how I treat you and dbaron). Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On Thu, Jul 11, 2013 at 6:23 AM, Justin Lebar justin.le...@gmail.comwrote: Someone who usually has a long review queue has told me that he hates reviewing code. I realized that we don't really have a place at Mozilla for experienced hackers who don't want to do reviews. Should we? I think someone can hate doing reviews and also want to do reviews because they're important. I don't know anyone who loves doing reviews. As another data point, someone told me recently that he's trying not to become a peer of the modules he's working on, because he doesn't want to review code. If someone who can do reviews is avoiding them, they're pushing workload onto their peers who probably don't enjoy it much more. That's antisocial and unacceptable IMHO. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
The way I work is that review and needinfo requests go to my inbox and I process them with high priority. I can and do ignore them there temporarily if I need to. Given I use my inbox as a to-do list, that approach seems perfect for me. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote: r-value references 4.3@10.0! Yes This is very useful. I believe the JS engine already rolls their own tricks to implement this semantics. With this we can get rid of already_AddRefed and just pass nsRefPtr/nsCOMPtr/RefPtr around, right? Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Mon, Jul 22, 2013 at 3:58 PM, L. David Baron dba...@dbaron.org wrote: Is the idea here that nsRefPtr/nsCOMPtr/etc. would have move constructors, and we'd just return them, and the move constructors plus return value optimizations would take care of avoiding excess reference counting? That, plus forget() returns a nsRefPtr. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Mon, Jul 22, 2013 at 5:39 PM, Justin Lebar justin.le...@gmail.comwrote: But if we return nsRefPtr, then if I have nsRefPtrFoo GetFoo(); Foo* = GetFoo(); that compiles fine (I think?) because nsRefPtrT has an implicit conversion to T*. It doesn't leak, though. OTOH you probably get a use-after-free, which is worse. So I dunno, maybe this is a bad idea. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
On indirect feedback
On Sat, Aug 3, 2013 at 9:13 AM, Gregory Szorc g...@mozilla.com wrote: Many of the complaints I've heard have been from overhearing hallway conversations, noticing non-directed complaints on IRC, having 3rd parties report anecdotes, etc. *Please, please, please voice your complaints directly at me and the build peers.* Indirectly complaining isn't a very effective way to get attention or to spur action. Yes! Indirect feedback is antisocial and destructive. http://robert.ocallahan.org/2013/05/over-time-ive-become-increasingly.htmlFWIW. Even if you're just the recipient of indirect feedback, you can help, by refusing to hear it until direct feedback has been given. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On indirect feedback
On Sat, Aug 3, 2013 at 12:43 PM, Brian Smith br...@briansmith.org wrote: I think some people may interpret what you say in that last paragraph the opposite of how you intend. I am pretty sure you mean something like If somebody starts to complain to you about somebody else, then stop them and ask them to first talk to the person they were trying to complain about. Yes, that's exactly what I mean. Thanks. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Flash and e10s
I was talking to people about plans for Flash on e10s. Full support for windowed Flash on e10s is possible but would be a ton of work. Flash is on a downward trajectory and it would be a shame to do a ton of work to support something that may not be relevant for much longer. One idea I had is this: suppose, independently of e10s, we make Flash click-to-play. (I understand this is already a goal, or at least a wish.) Then suppose we allowed click-to-play to reload the page. We would then be able to ensure that any page where Flash is enabled is loaded directly in the master process and everything would just work. That's not ideal, but it's a fine stop-gap approach IMHO. As Shumway matures we could whitelist common sites where Shumway is known to work, so those sites wouldn't need to be hoisted to the master process. One problem with these ideas is H.264 video sites on Windows XP. We're stuck with using Flash there for now. We might need to impose a different policy on Windows XP, backing off e10s more there perhaps. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Flash and e10s
On Wed, Aug 7, 2013 at 4:31 PM, Justin Lebar justin.le...@gmail.com wrote: On Tue, Aug 6, 2013 at 5:46 PM, Robert O'Callahan rob...@ocallahan.org wrote: I was talking to people about plans for Flash on e10s. Full support for windowed Flash on e10s is possible but would be a ton of work. Flash is on a downward trajectory and it would be a shame to do a ton of work to support something that may not be relevant for much longer. Just to be clear about our assumptions here: You think it would be a lot of work to do anything with Flash and content processes, including running Flash within the content process itself? Yes. Running windowed Flash within the content process itself would mean giving that content process access to the main window's HWND. That's not really an option for sandboxing, AIUI. Also, running windowed Flash within the content process would not work with multiple content processes, AIUI. Also, running Flash in the same process as content sucks more than running it in its own process. The best option for proper support of Flash would probably be a Flash process hanging off the master process, with content processes granted channels to the Flash process via IPDL trickery, plus some extra work to have the content process tell the master process how to position and clip each Flash window. It's going to be complex. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Flash and e10s
On Wed, Aug 7, 2013 at 6:05 PM, Markus Stange msta...@themasta.com wrote: On 07.08.13 06:39, Robert O'Callahan wrote: Running windowed Flash within the content process itself would mean giving that content process access to the main window's HWND. What would be the disadvantages of forcing wmode=transparent for content process flash? That might help. The other issues are still serious. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Flash and e10s
On Thu, Aug 8, 2013 at 2:14 AM, Benjamin Smedberg benja...@smedbergs.uswrote: The primary reason I know for windowed Flash to be a huge PITA is because of the deadlock issues caused by attached input queues. I'd love to force Flash to be windowless and use our fullscreen support instead of their own windows, because this would fix many of the deadlock issues. That would be nice. What other issues are you concerned about specifically? Managing window geometry from the master process is going to be a bit of a pain, since we'll have to combine information from the content process(es) with information about the geometry and visibility of the browsing context. It's doable though. One idea I had is this: suppose, independently of e10s, we make Flash click-to-play. (I understand this is already a goal, or at least a wish.) It is neither a goal nor feasible. We did user research into this at the beginning of the year, and there is enough hidden Flash out on the web that click to play is just too confusing for the average user. OK, that's very good to know. That scotches my idea. Thanks! Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exposing the CSS/SVG Filters as Canvas API's
Markus is moving with great speed and we should have the necessary Moz2D support landed soonish. I think the biggest outstanding issue is how to spec the canvas API for this. The most obvious approach to me is to add a filter attribute to CanvasRenderingContext2D that takes a CSS filter value and applies it during the compositing step of each drawing operation. Unfortunately CSS3 filters doesn't have a value representing a general color matrix. You could use context.filter = url(#mysvgColorMatrixFilter) and set up the corresponding filter element subtree in the document, but that's a bit naff for JS users (and wouldn't work in Workers). The data: URL version of that is even more naff and might also not work in Workers. So, we could choose between a) Add CanvasRenderingContext2D.filter and a color-matrix(N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N) CSS filter value. b) Add CanvasRenderingContext2D.colorMatrix which allows direct setting of a color matrix on the canvas, more like what Tobias suggested. This would allow later adding CanvasRenderingContext2D.filter as a separate feature. (If both were specified, both would be applied in some specified order.) Any thoughts? Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exposing the CSS/SVG Filters as Canvas API's
On Fri, Aug 9, 2013 at 9:29 AM, K. Gadd k...@luminance.org wrote: Consider this my +1 in favor of a dedicated .colorMatrix attribute, Good, then I'll expect you to back me up in WHATWG with usecases :-). preferably in the form of a Uint8Array or Float32Array instead of another *!@$ string. Using an array for an attribute is problematic due to liveness issues. heycam, what's the WebIDL-friendliest way to have an array-valued attribute-like thing? Just getter and setter methods? SVG color matrices provide a superset of some very important rendering operations that show up a lot in game rendering. Right now to emulate them in canvas I have to use the CPU to split a source image into four 'channel' images and blend them iteratively to the canvas in additive mode in order to approximate the most common one (GL_MULTIPLY, effectively) Doesn't GL_MULTIPLY multiply color values in the source by color values in the destination? The colormatrix feature we're talking about can't do that. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
