Re: Benefits of PGO on Windows
On Wed, Oct 17, 2012 at 06:55:57PM -0700, Dave Mandelin wrote: > Following the recent discussion about PGO, I really wanted to understand what > benefits PGO gives Firefox on Windows, if any--I was skeptical. Rafael (IIRC) > posted some Talos numbers, but I didn't know how to interpret them. So I > decided to try a few simple experiments to try to falsify the hypothesis that > "PGO has user-perceivable benefits". > > Experimental setup: Windows builds from > http://hg.mozilla.org/mozilla-central/rev/5f4a6a474455 on a Windows 7 Xeon. I > took opt and pgo builds from the tbpl links. > > Experiment 1: cold startup time > > I used a camera to measure time from pressing enter on a > a command line until the Fx window was completely shown. > > results: > opt: 3.025 seconds > pgo: 1.841 > > - A clear win for PGO. I'm told that there is a startup > time optimization that orders omni.ja that only runs > in PGO builds. So it's not necessarily from the PGO > itself, but at least it means the current PGO builds > really are better. If you copy omni.ja from the PGO build to the opt build, you'll be able to see if everything comes from that. We're planning to make that currently PGO-only optimization run on all builds. (bug 773171) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Benefits of PGO on Windows
On 10/17/2012 6:55 PM, Dave Mandelin wrote: Following the recent discussion about PGO, I really wanted to understand what benefits PGO gives Firefox on Windows, if any--I was skeptical. Rafael (IIRC) posted some Talos numbers, but I didn't know how to interpret them. So I decided to try a few simple experiments to try to falsify the hypothesis that "PGO has user-perceivable benefits". Experimental setup: Windows builds from http://hg.mozilla.org/mozilla-central/rev/5f4a6a474455 on a Windows 7 Xeon. I took opt and pgo builds from the tbpl links. Experiment 1: cold startup time I used a camera to measure time from pressing enter on a a command line until the Fx window was completely shown. results: opt: 3.025 seconds pgo: 1.841 - A clear win for PGO. I'm told that there is a startup time optimization that orders omni.ja that only runs in PGO builds. So it's not necessarily from the PGO itself, but at least it means the current PGO builds really are better. That's omni.ja funkyness with startup-cache, etc. Glad to see it still works. If the compiler was doing anything startup-smart to the binary, your fast system could probably startup in ~1s. Compilers do not care about startup(though there is interest among gcc people), so we have to do https://bugzilla.mozilla.org/show_bug.cgi?id=662397 & something similar on every platform Experiment 2: JS benchmarks I ran SunSpider and V8. I would have run Kraken too, but it takes longer to run and I already had significant results by then. I did 1-2 runs. Below I show the average, rounded off to not show noise digits. results: opt pgo SunSpider 250 200 (seconds) V88900 9400 ("score") - Another clear win for PGO. (Side note: I've recorded startup times for myself, with my normal profile, of ~30 seconds. I assumed that was just normal, so today I looked on Telemetry and saw that only 5-8% of startup times are that long. (I wish I knew what % of cold startups that is.) Today's results were with a clean profile, so it seems like my normal profile must be busting my startups (and others') badly. It would be really nice to make startup time independent of profile.) you can measure what goes wrong in your profile with work going-on in https://bugzilla.mozilla.org/show_bug.cgi?id=799638 That's really great that you have such a repeatable+slow profile. I never had the pleasure of having a fast machine that can start firefox this slowly. Taras ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Benefits of PGO on Windows
Following the recent discussion about PGO, I really wanted to understand what benefits PGO gives Firefox on Windows, if any--I was skeptical. Rafael (IIRC) posted some Talos numbers, but I didn't know how to interpret them. So I decided to try a few simple experiments to try to falsify the hypothesis that "PGO has user-perceivable benefits". Experimental setup: Windows builds from http://hg.mozilla.org/mozilla-central/rev/5f4a6a474455 on a Windows 7 Xeon. I took opt and pgo builds from the tbpl links. Experiment 1: cold startup time I used a camera to measure time from pressing enter on a a command line until the Fx window was completely shown. results: opt: 3.025 seconds pgo: 1.841 - A clear win for PGO. I'm told that there is a startup time optimization that orders omni.ja that only runs in PGO builds. So it's not necessarily from the PGO itself, but at least it means the current PGO builds really are better. Experiment 2: JS benchmarks I ran SunSpider and V8. I would have run Kraken too, but it takes longer to run and I already had significant results by then. I did 1-2 runs. Below I show the average, rounded off to not show noise digits. results: opt pgo SunSpider 250 200 (seconds) V88900 9400 ("score") - Another clear win for PGO. (Side note: I've recorded startup times for myself, with my normal profile, of ~30 seconds. I assumed that was just normal, so today I looked on Telemetry and saw that only 5-8% of startup times are that long. (I wish I knew what % of cold startups that is.) Today's results were with a clean profile, so it seems like my normal profile must be busting my startups (and others') badly. It would be really nice to make startup time independent of profile.) Dave ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
try syntax for b2g-only
While I was in the neighborhood of the relevant code, I looked into what it would take to add a b2g-only option to the try chooser syntax, and was surprised to discover that it's already possible. If you use |-p ics_armv7a_gecko| in your try syntax, it will select the B2G builds. It's combinable with the -b flag, so |-b d| and |-b -o| would select only the opt or debug versions, respectively. I'll still probably try making a patch to allow |-p b2g|, but it looks like we may be adding new B2G-relevant platforms, so I'm not sure exactly what it should do or whether it really makes sense. But |-p ics_armv7a_gecko| works right now (and has for a while, though I'm not sure anyone knew that it would.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Easiest way to start using httpd.js?
Sample standalone HTTP servers: https://hg.mozilla.org/mozilla-central/file/214853a29174/services/common/modules-testing/aitcserver.js https://hg.mozilla.org/mozilla-central/file/214853a29174/services/common/modules-testing/storageserver.js Minimal JS files to launch said servers: https://hg.mozilla.org/mozilla-central/file/214853a29174/services/common/tests/run_aitc_server.js https://hg.mozilla.org/mozilla-central/file/214853a29174/services/common/tests/run_storage_server.js Python script to invoke xpcshell process with necessary arguments to get JS to work: https://hg.mozilla.org/mozilla-central/file/214853a29174/services/common/tests/run_server.py Makefile targets to run the Python script (just for reference - this should probably be implemented as mach commands these days): https://hg.mozilla.org/mozilla-central/file/214853a29174/services/common/Makefile.in#l43 I wish it were easier. If this pattern ever becomes prevalent, we should probably move the Python + JS harness to somewhere more central. File a bug against me and I'll happily refactor the code in services/ to be more generic and shareable. Let me know if you have any questions. Gregory On 10/17/12 4:01 PM, Jim Porter wrote: I'm looking to write a fake server for the ActiveSync protocol, which I will eventually incorporate into xpcshell tests. httpd.js seems like the best tool for the job here. However, since the server is fairly complex, I wanted to be able to use XHRs in Firefox to talk to the server just to test things out. However, the documentation only seems to say how to use httpd.js in xpcshell. Surely there's a simpler way to get started. Does anyone know of such a way? Ideally, I'd be able to use this as a fake server for B2G desktop to talk to as well, since that would let manually test against the ActiveSync client implementation in Gaia. Thanks, Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Easiest way to start using httpd.js?
I'm looking to write a fake server for the ActiveSync protocol, which I will eventually incorporate into xpcshell tests. httpd.js seems like the best tool for the job here. However, since the server is fairly complex, I wanted to be able to use XHRs in Firefox to talk to the server just to test things out. However, the documentation only seems to say how to use httpd.js in xpcshell. Surely there's a simpler way to get started. Does anyone know of such a way? Ideally, I'd be able to use this as a fake server for B2G desktop to talk to as well, since that would let manually test against the ActiveSync client implementation in Gaia. Thanks, Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Freetype autohinter (was Re: Proposed W3C Charter: Web Fonts Working Group)
On 2012-10-17 2:31 PM, Jonas Sicking wrote: What would be interesting is if we could enable an autohinter in Firefox and use that in cases when we are sent a font which doesn't contain hints (is the performance overhead, if any, acceptable?) I don't have numbers, but I run my Linux desktop with Pango set to ignore in-font hints and apply only autohinter-generated vertical hinting (because I find the fonts more legible this way) and it seems acceptably fast to me. I'd also rather like to have the ability to control hinting operations from page CSS -- for instance, the aforementioned fonts for which Freetype autohinting does a bad job tend to look better if you tell it not to apply hints at all. We could then support a format("woff-autohint") which would allow pages to send a smaller unhinted font file to browsers which support autohinting and a larger file to browsers that don't. Google Web Fonts appears to do this server-side already (see discussion in bug 741963). zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Freetype autohinter (was Re: Proposed W3C Charter: Web Fonts Working Group)
On Oct 17, 2012 11:20 AM, "Zack Weinberg" wrote: > > On 2012-10-17 11:05 AM, Jonathan Kew wrote: >> >> AFAICS, the latest stable release is currently 2.4.10; do you know when >> 2.4.11 is expected? > > > Afraid not; we should probably ask Werner. It sounds to me that it's not generally true that autohinters can replace hinting. At least not yet. What would be interesting is if we could enable an autohinter in Firefox and use that in cases when we are sent a font which doesn't contain hints (is the performance overhead, if any, acceptable?) We could then support a format("woff-autohint") which would allow pages to send a smaller unhinted font file to browsers which support autohinting and a larger file to browsers that don't. That'd also put pressure on other UAs to implement autohinting if it becomes popular enough. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Freetype autohinter (was Re: Proposed W3C Charter: Web Fonts Working Group)
On 2012-10-17 11:05 AM, Jonathan Kew wrote: AFAICS, the latest stable release is currently 2.4.10; do you know when 2.4.11 is expected? Afraid not; we should probably ask Werner. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Freetype autohinter (was Re: Proposed W3C Charter: Web Fonts Working Group)
On 17/10/12 14:17, Zack Weinberg wrote: On 2012-10-17 4:07 AM, Henri Sivonen wrote: On Tue, Oct 16, 2012 at 9:16 PM, Zack Weinberg wrote: Until quite recently the FreeType autohinter did a very bad job on a surprising number of popular webfonts - rendering letters in the same word with inconsistent perceptual x-height, for instance. What kind of fonts? Bicameral or other? Display fonts or more normal fonts? I've mostly noticed it in bicameral Latin serif fonts. It's more obvious at display sizes but can show up at body-copy sizes as well. See http://savannah.nongnu.org/file/quattrocento-irregular-x-height.png?file_id=25578 for an example; according to Werner Lemberg, the autohinter could not handle fonts whose serif height exceeds an internal threshold. Unfortunately, that seems to include the bulk of the serif fonts on Google Web Fonts! http://savannah.nongnu.org/bugs/?36091 is the whole bug report. It _is_ fixed as of FreeType 2.4.11 -- but it looks like our bundled version is older than that (2.4.9 according to modules/freetype2/README.moz-patches) I believe that's correct - the most recent update we took was in bug 733512. AFAICS, the latest stable release is currently 2.4.10; do you know when 2.4.11 is expected? JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Freetype autohinter (was Re: Proposed W3C Charter: Web Fonts Working Group)
On 2012-10-17 4:07 AM, Henri Sivonen wrote: On Tue, Oct 16, 2012 at 9:16 PM, Zack Weinberg wrote: Until quite recently the FreeType autohinter did a very bad job on a surprising number of popular webfonts - rendering letters in the same word with inconsistent perceptual x-height, for instance. What kind of fonts? Bicameral or other? Display fonts or more normal fonts? I've mostly noticed it in bicameral Latin serif fonts. It's more obvious at display sizes but can show up at body-copy sizes as well. See http://savannah.nongnu.org/file/quattrocento-irregular-x-height.png?file_id=25578 for an example; according to Werner Lemberg, the autohinter could not handle fonts whose serif height exceeds an internal threshold. Unfortunately, that seems to include the bulk of the serif fonts on Google Web Fonts! http://savannah.nongnu.org/bugs/?36091 is the whole bug report. It _is_ fixed as of FreeType 2.4.11 -- but it looks like our bundled version is older than that (2.4.9 according to modules/freetype2/README.moz-patches) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: onHTTPSpyReadyStateChange not sent for aborted XHR?
On Oct 12, 2:05 pm, Jan Honza Odvarko wrote: > One of the Firebug automated tests is using following script to check > that XHR displayed in the Console panel (and the Net panel) is > properly finished if aborted: > > var request = new XMLHttpRequest(); > request.open("POST", "", true); > request.send(null); > request.abort(); > > It works in Firefox 17, where onHTTPSpyReadyStateChange (state 1 and > 4) is executed for the request and ACTIVITY_SUBTYPE_REQUEST_HEADER, > ACTIVITY_SUBTYPE_RESPONSE_COMPLETE and > ACTIVITY_SUBTYPE_TRANSACTION_CLOSE events sent by > nsIActivityDistributor - so, Firebug know that the request has > finished (and aborted). > > However it doesn't work in Firefox 19 where onHTTPSpyReadyStateChange > is not executed and no events from nsIActivityDistributor received. > > Is this a bug or an expected behavior? > > Honza I reported the problem here: https://bugzilla.mozilla.org/show_bug.cgi?id=802551 Honza ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Flash Player freezes XULRunner
Sorry for the late reply. Had a bit on lately. > You will need to get a debug build and a backtrace to answer that for > > sure, but with OOP plugins a Flash crash would (almost certainly) not > > crash XULRunner. I didn't get round to building a debug version. However after setting the XRE_CONSOLE_LOG environment variable I got the following message on the console: WARNING: RegisterWaitForSingleObject failed: 87: file: e:/builds/moz2_slave/rel-m-rel-xr-w32-bld/build/ipc/chromium/src/base/object_watcher.cc, line 62 Further the problem seems to be fixed in the most recent version of XULRunner (16.0.1). > Which settings did you add? I copied pref("dom.ipc.plugins.enabled", true); from the previously mentioned bug. The others seemed to refer to mac. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Freetype autohinter (was Re: Proposed W3C Charter: Web Fonts Working Group)
On Tue, Oct 16, 2012 at 9:16 PM, Zack Weinberg wrote: > Until quite recently the FreeType autohinter did a very bad job on a > surprising number of popular webfonts - rendering letters in the same word > with inconsistent perceptual x-height, for instance. What kind of fonts? Bicameral or other? Display fonts or more normal fonts? On Tue, Oct 16, 2012 at 10:58 PM, Karl Tomlinson wrote: > I struggle to imagine how the autohinter can compete with > human-specified hint instructions. Even > http://www.freetype.org/ttfautohint/ seems to imply that some > human interaction is expected. It’s quite good without human interaction, really. I tested ttfautohint with TeX Gyre Pagella. (I did the test for a hobby purpose earlier, but I took screenshots today for the purpose of this thread.) This font is a particularly good one for a demo. It is an OTF font that imports its outlines from URW Palladio L which is based on the same design by Herman Zapf as Linotype’s Palatino. This allows a comparison with Palatino on Mac and Palatino Linotype on Windows. Presumably, the best TrueType hinting expertise in the world was available for the development of Apple’s TrueType Palatino and for Palatino Linotype which was a collaboration between Microsoft and Linotype. I used FontForge to convert the Pagella OTF font into a TTF without requesting FontForge to do anything else. (That is, the result retained the CFF 1000 units per em convention and didn’t involve a conversion to 2048 units per em.) Then I ran ttfautohint on the converted font. First, in Firefox on Ubuntu we can see that both TTF versions appear to be of similar rendering quality as the original OTF version. Furthermore, unsurprisingly considering that this is FreeType with its autohinter, the two TTF versions look the same. hsivonen.iki.fi/screen/hinting/pagella-ubuntu.png On a Mac, the three versions of Pagella look equally good. Moreover, they look equally good as Palatino as shipped by Apple. TrueType hints don’t seem to important in Quartz. http://hsivonen.iki.fi/screen/hinting/pagella-mac.png http://hsivonen.iki.fi/screen/hinting/palatino-mac.png In Firefox on Windows 7 when running without GPU acceleration, we see that the OTF rasterization is just terrible with inconsistent x-height and inconsistent stroke weight despite declarative hints being present in the CFF data. The TTF version with FontForge hinting is more consistent but still horribly broken: there are holes where there should be horizontal strokes. The TTF version hinted with ttfautohint, however, shows up as being of similar quality as Palatino Linotype. http://hsivonen.iki.fi/screen/hinting/pagella-windows7-firefox.png http://hsivonen.iki.fi/screen/hinting/palatino-linotype-windows7-firefox.png In IE9 on Windows 7 running on the same virtual machine as the Firefox instance I tested, things look better. he OTF and the FontForge TTF versions look almost as good as Palatino Linotype, but there are glitches in individual glyphs ($ and 2 in the OTF case; bottom serif of p in the TTF case). The ttfautohint version actually looks better than Palatino Linotype. It's better anti-aliased, so there are no jaggies while Palatino Linotype shows jaggies. Of the eight different Windows font rasterization was shown here, it is the only rasterization that is competitive with the Ubuntu and Mac results. http://hsivonen.iki.fi/screen/hinting/pagella-windows7-ie9.png http://hsivonen.iki.fi/screen/hinting/palatino-linotype-windows7-ie9.png (I have filed the extraordinary difference between Firefox and IE9 in OTF/CFF rasterization as https://bugzilla.mozilla.org/show_bug.cgi?id=782226 ) The test page I used is http://hsivonen.iki.fi/test/palatino/palatino.html > I was under the impression that FreeType autohinter used > heuristics based on expectations of the shape of Latin characters. It does. The Latin heuristics are applicable to Greek and Cyrillic, too. > I'd be surprised if that had been extended to all characters/scripts. The ttfautohint page says: “Add support for all the world's writing systems – since FreeType's autohinting system supports the Arabic and CJK (Chinese, Korean, Japanese) writing systems, ttfautohint could do so too. (So far the primary goal is to make ttfautohint work well with the latin script.)” -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off main thread file I/O
On 10/16/12 9:05 PM, Gavin Sharp wrote:> This is excellent - > https://developer.mozilla.org/en-US/docs/JavaScript_OS.File/OS.File_for_the_main_thread > is exactly the kind of API I've been wanting for a long time. I know > it took a lot of work to get there - thank you for your efforts. > > A couple of questions: > - some examples use file names without paths, like: |let promise = > OS.File.read("file.txt");|. Are these file names treated as > CWD-relative, or something else? This doesn't seem to be specified > well in the documentation. Indeed, this is CWD relative. I will add a paragraph on that topic in the documentation. This is generally not very useful for platform or add-ons, but it can be quite useful for tests. > - I assume the file name arguments are all nsIFile.path-compatible > across platforms? Barring any bug, they should be. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform