On Friday, October 4, 2013 6:16:36 PM UTC+5:30, Bobby Holley wrote:
On Fri, Oct 4, 2013 at 2:36 PM, vasuyadavkri...@gmail.com 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
2013/10/10 Benoit Jacob jacob.benoi...@gmail.com
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:
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
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, vasuyadavkri...@gmail.com wrote:
Based on my understanding, I need to create a JS XPCOM component apart
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 to
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 Wed, Oct 16, 2013 at 2:39 PM, Gervase Markham g...@mozilla.org 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
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 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 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
- 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? Hardware,
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
On Wed, Oct 9, 2013 at 7:01 PM, Gervase Markham g...@mozilla.org 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
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
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.
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,
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
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.
Many
Matt Brubeck mbrub...@mozilla.com 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
On Wed, Oct 16, 2013 at 1:39 PM, al...@yahoo.com 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
On 16/10/13 22:52 , Brian Smith wrote:
On Wed, Oct 16, 2013 at 1:39 PM, al...@yahoo.com 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
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
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
On Wed, Oct 16, 2013 at 10:09 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
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.
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
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
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
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
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 take
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
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
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
On Wed, Oct 16, 2013 at 6:43 AM, Mike Hommey m...@glandium.org 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,
On Wed, Oct 16, 2013 at 08:09:23PM -0700, Nicholas Nethercote wrote:
On Wed, Oct 16, 2013 at 6:43 AM, Mike Hommey m...@glandium.org 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
35 matches
Mail list logo
