On 10/17/2013 12:09 AM, Ehsan Akhgari wrote:
I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of
Web Audio. We added a deprecation warning for this API in Firefox 23 (bug
855570). I'm not sure what our usual process for this kind of thing is,
should we just take the patch
On Wed, Oct 16, 2013 at 08:09:23PM -0700, Nicholas Nethercote wrote:
> On Wed, Oct 16, 2013 at 6:43 AM, Mike Hommey wrote:
> >
> > I'm sure fellow developers building on Windows felt sad that they were
> > left out on the recent build improvements. Rejoice at last, as we are
> > now bringing those
On Wed, Oct 16, 2013 at 6:43 AM, Mike Hommey wrote:
>
> I'm sure fellow developers building on Windows felt sad that they were
> left out on the recent build improvements. Rejoice at last, as we are
> now bringing those to you.
In case you're interested how this happened... AIUI, these
improvemen
Thanks for putting this together, and thanks to everybody working on
making the build faster and thus making us all more productive. This
sped up clobber build times on Windows for me by 6 minutes, around 22%,
which is great. Some of us can't switch to a *nix based platform in
order to get fast
On 10/16/2013 1:24 PM, Karl Tomlinson wrote:
Many people use browsers for reading text, so I would like to
claim that text rendering quality is usually more important than
performance.
I apologize for not looking through the referenced bugs.
To repeat a point from my previous message: These bu
Anything you think would benefit from people in QA spending quality time doing
manual testing qualifies as a feature, for example.
There will be times when this is not clear, but if there's a chance an end-user
could see the effect, it would be great to see it flagged.
juanb
- Original
At 2013-10-16T17:09:50-0400, Ehsan Akhgari wrote:
> I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of
> Web Audio. We added a deprecation warning for this API in Firefox 23 (bug
> 855570). I'm not sure what our usual process for this kind of thing is,
> should we just tak
Lukas Blakk wrote:
This wiki page: https://wiki.mozilla.org/Features/Release_Tracking
now picks up on the keyword 'feature' in your meta/tracking bugs.
Please add this to your feature work to make sure it gets early QA,
Stability, PR, User Advocacy, and Release Management awareness in
preparatio
On 16 October 2013 23:10:39, Gregory Szorc wrote:
Possible crazy idea: do we actively track and send tree management
notices when package or binary size changes?
Not at present as far as I know, though Tim Taubert created something
temporary last year (no longer accessible, but perhaps worth f
Possible crazy idea: do we actively track and send tree management
notices when package or binary size changes? This seems like something
we'd want to cover under the "perf regressions get backed out or need
approval" policy. It may also help identify build system regressions and
compiler oddit
On 2013-10-16 2:26 PM, Anne van Kesteren wrote:
> For obscure DOM methods we do the warnings, then give it a try in
> nightlies and see if anyone screams. So yeah, you want to do that I
> think.
Sounds good to me.
-r
___
dev-platform mailing list
dev-p
The proposed quarterly goals for the build system have been posted to
dev.builds and will be discussed at a meeting in ~24 hours. If you are
interested in influencing what build work happens this quarter, now is
the opportunity to get engaged.
Please keep discussion unified on dev.builds.
htt
On Wed, Oct 16, 2013 at 10:09 PM, Ehsan Akhgari wrote:
> I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of
> Web Audio. We added a deprecation warning for this API in Firefox 23 (bug
> 855570). I'm not sure what our usual process for this kind of thing is,
> should we ju
https://bugzilla.mozilla.org/show_bug.cgi?id=893404 and
https://bugzilla.mozilla.org/show_bug.cgi?id=898825 are two of the last
parent-process crash bugs in the current e10s-crash list
(https://bugzilla.mozilla.org/show_bug.cgi?id=899758). Drew and I are planning
to let the background thumbnail
I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of
Web Audio. We added a deprecation warning for this API in Firefox 23 (bug
855570). I'm not sure what our usual process for this kind of thing is,
should we just take the patch, and evangelize on the broken websites enough
On 16/10/13 22:52 , Brian Smith wrote:
On Wed, Oct 16, 2013 at 1:39 PM, wrote:
In general, if I understand correctly, it's hard to use native subpixel AA
in layers that use hardware accelerated compositing. So in some cases we
might need to choose between speed and subpixel rendering. (I'm no
On Wed, Oct 16, 2013 at 1:39 PM, wrote:
>> In general, if I understand correctly, it's hard to use native subpixel AA
>> in layers that use hardware accelerated compositing. So in some cases we
>> might need to choose between speed and subpixel rendering. (I'm not at all
>> an expert in this are
"Matt Brubeck" wrote in message
news:525eb9f5.8050...@mozilla.com...
> On 10/15/2013 1:36 PM, al...@yahoo.com wrote:
>> Why are these ignored?
>
> I can't speak for anyone else, but I would guess it's because no one who
> has looked at them has figured out any useful information to add, or found
Matt Brubeck writes:
> On 10/15/2013 1:36 PM, al...@yahoo.com wrote:
>> Why are these ignored?
> As to whether we should pull someone off of other tasks to focus
> on these XP text-rendering bugs, that's tricky.
> So in some cases we might need to choose between speed and
> subpixel rendering.
The experiment here is quite a bit different from what the current patch is
proposing (6 shader programs, only drive swizzle and alpha/no-alpha via
uniforms). Benoit is redoing the measurements for that scenario. More data
coming shortly.
Andreas
On Oct 16, 2013, at 7:00 AM, Benoit Jacob wro
Hello all,
This wiki page: https://wiki.mozilla.org/Features/Release_Tracking now picks up
on the keyword 'feature' in your meta/tracking bugs.
Please add this to your feature work to make sure it gets early QA, Stability,
PR, User Advocacy, and Release Management awareness in preparation (and
Greetings,
We are having a UX "kick off" meeting today at Noon PDT, in Vidyo-Shumway. I'll
post notes here since I know this is really short notice. We will also likely
discuss the conclusions/next steps in tomorrow's 11AM PDT Cross-Functional for
folks who can't join today.
Erin
On Oct 9,
On 10/16/2013 9:39 AM, Gervase Markham wrote:
On 15/10/13 17:06, Benjamin Smedberg wrote:
You have given on-disk footprint values, but surely download size values
are the important ones for the issue you are raising? After all, some of
this data may be very compressible, and some may not.
Correc
On 10/16/13 6:39 AM, Gervase Markham wrote:
You have given on-disk footprint values, but surely download size values
are the important ones for the issue you are raising? After all, some of
this data may be very compressible, and some may not.
Can we repackage the ICU data so we can compress it
On Wed, Oct 9, 2013 at 7:01 PM, Gervase Markham wrote:
> A quick survey of the security-group led to the following suggestions,
> and I'm sure there are more:
* Character encoding detectors that are not enabled by default for
any locale (bugs are already on file).
* Multi-byte character encodi
On 10/15/2013 1:36 PM, al...@yahoo.com wrote:
Why are these ignored?
I can't speak for anyone else, but I would guess it's because no one who
has looked at them has figured out any useful information to add, or
found the time to investigate further.
As to whether we should pull someone off
Each Friday, we meed at 9 AM Pacific Time to discuss the state of
documentation for Web APIs and to plan the next week of work. If you
love Web APIs and develop on or with them, or are interested in
producing documentation or code samples for these APIs, please consider
attending!
For details
On 10/16/2013 02:10 PM, Axel Hecht wrote:
> I wonder how far we can get by doing something along the lines we use for
> webfonts, starting to do the best we can with the data we already have, and
> improve once the perfect data is local.
Having the Intl.Foo algorithms returning different data ov
- Original Message -
> At the summit's Innovation Fairs, Mozilla's program management team will
> be hosting "Developer Productivity" booths to gather suggestions for
> streamlining our development processes and reducing developer frustration.
>
> What speed bumps are getting you down? Har
On 10/15/2013 07:18 PM, Brian Smith wrote:
> My (naive) understanding is that the Windows has its own API that does
> what ICU does. I believe that Internet Explorer 11 is an existence
> proof of that. If we used the Windows API on Windows, maybe we could
> avoid building ICU altogether on Windows.
On 10/16/2013 12:45 AM, Karl Tomlinson wrote:
> When sync I/O is performed to read in-binary-object data, how is
> that better?
>
> Just readahead?
Readahead, it being part of the binary/libxul/whatever so already one coherent
file to load, etc. I'm not aware that you can reasonably predict adj
On 10/16/13 3:50 PM, Gervase Markham wrote:
On 16/10/13 14:47, Anne van Kesteren wrote:
The API is synchronous so that seems like a bad idea.
As in, it'll cause the tab to freeze (one time only, when a new language
is called for) while the file is downloading? OK, that's bad, but so is
having
On 16/10/13 14:47, Anne van Kesteren wrote:
> The API is synchronous so that seems like a bad idea.
As in, it'll cause the tab to freeze (one time only, when a new language
is called for) while the file is downloading? OK, that's bad, but so is
having Firefox be a lot bigger...
Perhaps, as Brian
On Wed, Oct 16, 2013 at 2:39 PM, Gervase Markham wrote:
> I wonder if we could do this as a webservice? That is, when the browser
> is asked to render a timezone string or a currency string in a
> particular language, it goes and grabs all the data for that language.
> We could therefore have full
Hi,
Episode 1 was the "You want faster builds, don't you" thread.
Episode 2 was the "Faster builds, now" thread.
Here comes episode 3.
I'm sure fellow developers building on Windows felt sad that they were
left out on the recent build improvements. Rejoice at last, as we are
now bringing those to
On 15/10/13 17:06, Benjamin Smedberg wrote:
> With the landing of bug 853301, we are now shipping ICU in desktop
> Firefox builds. This costs us about 10% in both download and on-disk
> footprint: see https://bugzilla.mozilla.org/show_bug.cgi?id=853301#c2.
> After a discussion with Waldo, I'm going
On Wednesday, October 16, 2013 1:46:48 PM UTC+5:30, Vasu Yadav wrote:
> On Friday, October 4, 2013 6:16:36 PM UTC+5:30, Bobby Holley wrote:
>
> > On Fri, Oct 4, 2013 at 2:36 PM, wrote:
>
> >
>
> >
>
> >
>
> > > Based on my understanding, I need to create a JS XPCOM component apart
>
> >
Jumping in late, so top posting.
I think being able to load language data dynamically is a good idea. I
don't see a reason why this should be tied in to a language pack,
though. The other way around is a different question. i.e.
language data doesn't include UI localization
UI localization sh
2013/10/10 Benoit Jacob
> this is the kind of work that would require very careful performance
> measurements
>
Here is a benchmark:
http://people.mozilla.org/~bjacob/webglbranchingbenchmark/webglbranchingbenchmark.html
Some results:
http://people.mozilla.org/~bjacob/webglbranchingbenchmark/web
As you've discovered, there's a lot of magic and boilerpate that's
easy to get wrong. You can find some simple test XPCOM components in
js/xpconnect/components. Try grabbing one of those, making sure that
it works, and then iterating on it to turn it into what you need.
bholley
On Wed, Oct 16, 20
On Friday, October 4, 2013 6:16:36 PM UTC+5:30, Bobby Holley wrote:
> On Fri, Oct 4, 2013 at 2:36 PM, wrote:
>
>
>
> > Based on my understanding, I need to create a JS XPCOM component apart
>
> > from the existing C++ XPCOM component I already have. All the JavaScript
>
> > function calls nee
41 matches
Mail list logo
