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
The other day, while testing some B2G v1.2 stuff, I noticed the Moz Audio
Data deprecation warning flying in adb logcat. So you probably need to
check with B2G/Gaia people about the timing to kill this API.
Benoit
2013/10/16 Ehsan Akhgari ehsan.akhg...@gmail.com
I'd like to write a patch to
On 10/17/13 12:02 PM, Gervase Markham wrote:
On 16/10/13 16:02, Axel Hecht wrote:
We'll need to go down a path that works for Firefox OS.
With Firefox OS, we don't have the download-size issue, do we? So we can
ship all the data.
Gerv
We have issues with disk space, currently. We're
On 10/16/13 5:39 PM, Jeff Walden wrote:
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
On 12.10.2013 08:51, al...@yahoo.com wrote:
This applies to xp without acceleration:
1. Fx 15: grayscale aa in the urlbar
https://bugzilla.mozilla.org/show_bug.cgi?id=828073
2. Fx 18: bad cleartype (gamma?) on selected menu items
https://bugzilla.mozilla.org/show_bug.cgi?id=828192
On Thursday, October 17, 2013 1:54:48 PM UTC+2, Dao wrote:
On 12.10.2013 08:51, al...@yahoo.com wrote:
This applies to xp without acceleration:
1. Fx 15: grayscale aa in the urlbar
https://bugzilla.mozilla.org/show_bug.cgi?id=828073
2. Fx 18: bad cleartype (gamma?) on
On 16.10.2013 17:02, Axel Hecht wrote:
We'll need to go down a path that works for Firefox OS.
[...]
But, yes, I think we'll need a hosted service to provide that data on
demand in the end.
This sounds like a non-starter for mobile devices, doesn't it?
I landed bug 895047 last night which makes the following changes:
1. It makes the char16_t type globally available across the tree.
2. It defines PRUnichar and jschar to be char16_t.
These changes do not affect NSPR and NSS, but the char16_t type is ABI
compatible with the PRUnichar type used in
On 10/17/13 2:41 PM, Dao wrote:
On 16.10.2013 17:02, Axel Hecht wrote:
We'll need to go down a path that works for Firefox OS.
[...]
But, yes, I think we'll need a hosted service to provide that data on
demand in the end.
This sounds like a non-starter for mobile devices, doesn't it?
Looks like the comms app has some residual use of the old audio API:
apps/communications/dialer/js/keypad.js:this._audio.mozSetup(1,
this._sampleRate);
apps/system/emergency-call/js/keypad.js: this._audio.mozSetup(2,
this._sampleRate);
Should be easy to replace. I will file a bug and
On Thu, Oct 17, 2013 at 3:46 AM, Axel Hecht l...@mozilla.com wrote:
We have issues with disk space, currently. We're already in the situation
where all our keyboard data doesn't fit on quite a few of the devices out
there.
Where can one read more about this? This ICU data is not *that* huge.
On 10/17/2013 2:28 AM, smaug wrote:
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
On 2013-10-17 9:29 AM, Andreas Gal wrote:
Looks like the comms app has some residual use of the old audio API:
apps/communications/dialer/js/keypad.js:this._audio.mozSetup(1,
this._sampleRate);
apps/system/emergency-call/js/keypad.js: this._audio.mozSetup(2,
this._sampleRate);
Should
On 2013-10-16 6:56 PM, Matthew Gregan wrote:
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
On Oct 17, 2013, at 8:07 AM, bram.speecka...@gmail.com wrote:
I've already narrowed down the second issue back in February by compiling
revisions myself (as much as I could, many of the revisions in between won't
build) and reported my findings in bug 812871.
Aside that I was going to mail
On 2013-10-17 10:06 AM, Benjamin Smedberg wrote:
On 10/17/2013 2:28 AM, smaug wrote:
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
This is the discussion thread for the Mozilla Research blog post entitled
Studying Lossy Image Compression Efficiency, and the related study.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Blog post is here:
https://blog.mozilla.org/research/2013/10/17/studying-lossy-image-compression-efficiency/
Study is here:
http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/
___
dev-platform mailing list
- Original Message -
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
On 10/17/13 3:41 PM, Brian Smith wrote:
On Thu, Oct 17, 2013 at 3:46 AM, Axel Hecht l...@mozilla.com wrote:
We have issues with disk space, currently. We're already in the situation
where all our keyboard data doesn't fit on quite a few of the devices out
there.
Where can one read more about
Yes, I pinged him an hour ago, and he plans to replace all uses of Audio
Data API by Web Audio.
I think he posted in the bug.
Paul.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
tl:dr: We recently installed system monitoring software on our buildbot
masters, build-not-test slaves, and various other RelEng machines. IT
want to continue this rollout, deploying monitoring software onto RelEng
production test machines, which raises a concern about possible impact
to
We have enough tooling in place to see if these affect performance or
not. What we will need is a clear demarcation of when the change is made
to each OS. Ideally the change would go out across all OS's at the same
(or nearly the same) time. If we can at least get the change rolled out
across
Thank you for publishing this study, here are my first questions:
- Why didn't you include JPEG 2000?
- Correct me if I'm wrong but JPEG-XR native color space is not Y'CbCr this
means that this format had to perform an extra (possibly lossy) color space
conversion.
- I suppose that the final
On 10/17/13 7:27 AM, Johnathan Nightingale wrote:
If you (or others reading this) are helping to hunt down regression ranges in
the future, consider this my regularly scheduled pitch for mozregression.
http://harthur.github.io/mozregression/
It takes a minute to learn how it works, but it
On Wednesday, October 16, 2013 1:53:24 PM UTC+5:30, Bobby Holley wrote:
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,
On 10/17/2013 9:48 AM, Josh Aas wrote:
This is the discussion thread for the Mozilla Research blog post entitled Studying
Lossy Image Compression Efficiency, and the related study.
HEVC-MSP did really well. Its unfortunate that Mozilla could not use it
in any capacity since its tied to the
Here are three different proposals to cut over to the new Windows 64-bit
rev2 (win64-rev2) machines (see
https://groups.google.com/forum/#!topic/mozilla.dev.platform/zACrUe_JwKw
for context), along with some of the pros and cons of each approach.
I would prefer option #3 (gradual phase-in) so
On 10/17/2013 10:24 AM, Ehsan Akhgari wrote:
We used to have codesighs measurements (and perhaps still do) but
historically many people just ignored them.
We stopped collecting codesighs measurements in November 2012 (bug
803736). As Ehsan says, it was widely ignored. It regressed
Option #3 sounds logical.
What way would sheriffs/devs have to determine which machines are rev2
and which ones are rev1?
Should they use the info in production_config.py?
- rev2 machines: [1]
- rev2 (try): currently empty [2]
[1]
On 13-10-17 3:22 PM, Armen Zambrano Gasparnian wrote:
Option #3 sounds logical.
Based on feedback I received from joduinn, one small adjustment to
option #3: phase-in to try first and wait for confirmation before
phasing-in inbound/central to further reduce risk exposure to those
branches.
On Thursday, October 17, 2013 12:50:12 PM UTC-5, cry...@free.fr wrote:
Thank you for publishing this study, here are my first questions:
- Why didn't you include JPEG 2000?
We couldn't test everything, we picked a small set of the formats that we hear
the most about and that seem
On Thu, Oct 17, 2013 at 5:58 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
I landed bug 895047 last night which makes the following changes:
1. It makes the char16_t type globally available across the tree.
2. It defines PRUnichar and jschar to be char16_t.
Nice! Replacing crusty old
HDR-VDP-2 is relatively recent metric that produces predictions for difference
visibility and quality degradation.
http://sourceforge.net/apps/mediawiki/hdrvdp/index.php?title=Main_Page
It could been interesting to add this metric in future studies.
Rafał Mantiuk (the guy behind HDR-VDP-2) also
I would include any major rewrites of significant portions of the back end as
well.
Marc S.
- Original Message -
From: Lawrence Mandel lman...@mozilla.com
To: Cameron McCormack c...@mcc.id.au
Cc: Lukas Blakk lsbl...@mozilla.com, dev-platform@lists.mozilla.org,
Hi,
I am working on GUI automation component of a performance monitoring product.
One of the common approaches to monitoring application is periodically capture
text from the control where changes are expected (content area of the browser
for Web applications). Text capturing ideally
36 matches
Mail list logo
