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
Re: Freetype autohinter (was Re: Proposed W3C Charter: Web Fonts Working Group)
On Tue, Oct 16, 2012 at 9:16 PM, Zack Weinberg za...@panix.com 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 mozn...@karlt.net 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: 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 2012-10-17 4:07 AM, Henri Sivonen wrote: On Tue, Oct 16, 2012 at 9:16 PM, Zack Weinberg za...@panix.com 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: 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 za...@panix.com 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 Oct 17, 2012 11:20 AM, Zack Weinberg za...@panix.com 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
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
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
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
