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
> I'd like to write a patch to kill Moz Audio Data in F
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
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 alread
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 a
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
3.
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 cle
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?
Wel
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 mak
On Thu, Oct 17, 2013 at 3:46 AM, Axel Hecht 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.
If we can't aff
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 th
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 b
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 t
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 n
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
dev-platform@lists.mozi
- 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
On 10/17/13 3:41 PM, Brian Smith wrote:
On Thu, Oct 17, 2013 at 3:46 AM, Axel Hecht 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 da
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 performanc
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
On 2013-10-16 6:10 PM, Gregory Szorc wrote:
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 b
On Thursday, 17 October 2013 10:48:16 UTC-4, Josh Aas wrote:
> This is the discussion thread for the Mozilla Research blog post entitled
> "Studying Lossy Image Compression Efficiency", and the related study.
Would be interesting if you could post your conclusions from these tests.
_
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 lo
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 will
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 wo
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 th
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 long
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"
constan
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]
http://hg.mozilla.org/build/buildbot-configs/file/production/mozi
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 interesti
On Thu, Oct 17, 2013 at 5:58 AM, Ehsan Akhgari 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 custom PR/JS types with
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 w
I would include any major rewrites of significant portions of the back end as
well.
Marc S.
- Original Message -
From: "Lawrence Mandel"
To: "Cameron McCormack"
Cc: "Lukas Blakk" , dev-platform@lists.mozilla.org,
"dev-plann...@lists.mozilla.org ()" ,
fx-t...@mozilla.com, mobile-...@
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 captures
38 matches
Mail list logo
