Sunday, January 13, 2013

TenFourFox 19 beta: Judgment Day

COMING TO A POWER MAC NEAR YOU
RATED PG-19 FOR A PRETTY GOOD PORT OF 19 BETA

Yes, it's Judgment Day, and we've been judged absolutely righteous. Mozillanet has exterminated all 10.4 and 10.5 computers from the earth web, but the resistance has sent their computers forward in time with the use of advanced compiler technology to save 21st-century humanity from Intel-based hunter killers and Tim Cook drones. Excuse me, there's a police officer at the front door who bears a strange resemblance to Robert Patrick. I'll be back.

And I'm out of desperate Terminator jokes, so here's TenFourFox 19. Our personal "judgment day" was the end of 10.5 support in Firefox, officially in 16 (but 10.5 code was kept by arrangement in 17 so we could reenable it in the ESR), and the need to upgrade our compiler toolchain to a later gcc/bintools due to unacceptable hacks needed to get gcc 4.0.1 to work. Our compiler adventures were already excessively documented in this august publication, and the rest of the work was upgrading our build system to handle the new compiler and build independent binaries, and lastly finding and restoring the code Mozilla deleted or changed for the new 10.6 baseline. So now you have it in front of you to try.

This port was the opportunity to pay off much of our accumulated technical debt. The compiler upgrade alone allows us access to better PowerPC code generation and optimizations, and it also allowed me to jettison many of the gcc 4.0.1 compiler hacks that hampered portability. Because of improvements in the standard libraries also available in gcc 4.6.3, we now carry our own copies of libgcc and libstdc++ instead of using the system ones and the internal js, firefox, XUL and dylibs are all linked against it to make a self-contained package. Tobias already worked out most of this for AuroraFox, which uses a later gcc as well, although it required some tweaking for current MacPorts and 10.4. However, binaries are not significantly larger since the new linker we are using is also more efficient. My original fears about memory bloat do not appear to have been realized, either, so we are probably still okay with a 512MB RAM supported minimum. (Users at this minimum should test and report in.) Builders should note that our HowToBuildNow document now has a new section for our 19+ releases.

The new hotness has been pretty thoroughly tested on both G4 arches and G5 on 10.4, but I don't have any G3 systems running 10.4 currently, and I don't run 10.5. Leopard users and G3 users, I am particularly interested in feedback.

The biggest change between 17 and 19 is the introduction of what Mozilla refers to as "display-list based invalidation," or DLBI. Introduced first in 18, it is a deceptively simple optimization that forces the layout engine to be more exacting about what it needs to have redrawn in an effort to reduce pushing unnecessary pixels around. DLBI does not make things faster, per se (and there are some edge cases where it will make performance worse), but it does make things smoother. As an example, compare my favourite even-handed American politics site, RealClear Politics, in 17.0.2 and 19b1. After you've vomited reading articles opposed to your personal views, at the top right is a marquee with arrows to go right and left. Try scrolling through them. It's not necessarily faster, but it looks a lot nicer. Another site that shows better animation is one that had me chagrined in 17, local radio station KFI AM 640. On some sites, this almost completely erases the performance loss from the layers change introduced way back between Fx3.6 and Fx4. Because we are nearly entirely rendered in software, anything that involves pushing less pixels means better performance and better animation. DLBI is that.

A large change like DLBI also means massive regression risk. In 18, Mozilla fixed quite a few of these and I expect many more. If you find a rendering difference between 19 and 17.0.2 on a site, it is imperative you do a test on a Tier 1 official Firefox build (with hardware acceleration off) to see if it occurs there too. If it does, report it to Mozilla; it's not our bug. I am sure we will have lots of regressions unrelated to this, so I really want people to not clog up the worklist with upstream problems. Remember, please do not file issues on unstable builds on Tenderapp to avoid confusing regular end users on the stable branch. And before you ask, it is not possible to backport DLBI to 17. Sorry.

19's most ballyhooed change, however, is disabled in our build: the JavaScript PDF viewer. PDF.js actually has been part of Firefox for some time, but this is the first time it is being user-exposed by default. However, it's a poorer renderer than Preview.app or (natch) Adobe Acrobat, it's a much slower renderer (its speed is at best tolerable on this quad G5), and there's some argument from security guyz on whether it's even a safer renderer. PDF rendering is going to be the next frontier for Power Mac porting, and I'm looking at updating Vindaloo to see if this can be a future means to safely handle PDF files on PowerPC, but that's another story (and it won't be integrated with the browser in any case). You can go into about:config and turn the JavaScript PDF viewer back on, and some of you already have, but I have no plans to ship that as default until the speed improves.

18 and 19 also offer rudimentary WebRTC. I need to explore this more to see if it's feasible to use on Power Macs, but given that our AltiVec WebM is really only an option for high-end G4s and G5s and we don't have any AltiVec code of any sort in WebRTC, I don't have a lot of confidence that it's going to be worth porting. Right now, it is turned off at the compiler level.

Locally, we also have some improvements of our own specific to PowerPC OS X. In addition to the same faster font enumeration code added to 17.0.2, our version of 19 also offers AltiVec-accelerated blurring and shadowing thanks to Tobias' work in issue 189. This further improves display and scrolling performance especially on pages that blur or box-shadow the entire background, requiring the CPU to do a lot more compositing work. Don't worry, G3 owners; you may not have AltiVec, but you do have a better C-language version handling the blurring/shadows for you too.

For QTE users, the QTE didn't seem to work right with 19 aurora, but seems to be okay with 19 beta (though with some errors in the console). I'm tracking this closely for now.

The biggest announcement of all, however, is that Firefox 19 is now being offered to Android handset owners with ARMv6 CPUs as "slow" as 600MHz with as "little" as 512MB of RAM. Read that carefully. Does that remind you of any particular systems on some other RISC-based platform abandoned by its manufacturer? The fact that Mozilla is now concentrating on lower-spec devices (not just for Boot2Gecko but for flagship Firefox Android) means that they will be continuing to audit for and seek performance wins in Gecko, and a lot of this will be in cross-platform code that will in turn improve performance in desktop Firefox and in TenFourFox. And that, as they say, is a Good Sign.

The T-1000 has turned itself into my cat and is busily reprogramming my security system, so you'd better get the build from the Downloads tab (and read the Release Notes) while you still can. Hasta la vista, baby.

16 comments:

  1. Tested WebRTC getUserMedia on an iMac G5 2.1 (using Aurora 20) and while it does work well performance is barely tolerable.

    ReplyDelete
  2. I judge that 19 is way better. I don't know if it's my computer or the placebo effect or something, but T4F 19 definitely loads webpages faster. I wish I could click on your ads, but Adblock Plus blocks them. However, as Arnold once said, "Money doesn't make you happy. I now have $50 million but I was just as happy when I had $48 million."

    ReplyDelete
  3. And if anyone would know, it would be Ahnold.

    ReplyDelete
  4. I can't import Safari bookmarks from an html file. This was fixed in 17.0.2 but it seems it's broken again.

    Also, sorry for the off-topic, but there is something I just noticed on YouTube that may be a problem for TFF users. It's not a bug, but it's more probable to see this in TenFourFox than in other browsers, that's why I'm pointing out this here. Visiting a YouTube page with plugins disabled will cause the "Install Flash" black frame to come up. It seems YT has added a background animation to this. It is similar to static on an old TV screen. It's barely visible but it causes the CPU load to skyrocket (I'm seeing a 100% load on my old eMac). Using the Feather beta interface solves this.

    ReplyDelete
  5. Oops, I thought that patch got in 19, but it looks like it wasn't landed until 20. It's easy enough to throw in to final.

    ReplyDelete
  6. Looks good on 10.5 as well as G3. Memory usage on my 640 MB RAM challenged iBook G3 is a littler higher than in 17, but no problem if you browse in a civilized manner (as before).

    Pdf.js is noticeably faster (about twice as fast as in 17), so that's good news. Issues with unembedded fonts still the same, though, but basically usable.

    Mozilla bug 828206 is very annoying. It changes the font smoothing in some portions of websites like YouTube and Facebook to something intolerable as soon as you start scrolling the page for the first time. This should be fixed in 20 or 21 at the latest, but until then I can't use this as my everyday browser, sadly.

    Mclcmm, the YouTube "snow" animation is for videos that require Flash because YouTube still hasn't figured out how to place ads in html5 videos. Embarrassing. I use the StopTube extension (version 0.2.0) which acts like Click To Play, but for html5 YouTube videos. Also, you can still download these videos to watch them outside the browser e.g. with the very reliable Easy YouTube Video Downloader.

    ReplyDelete
  7. I hadn't noticed M828206, but then I avoid Facebook like the plague. The apparent fix is M806099 and it looks like it will be uplifted to 19 since this affects a large number of systems.

    Good to hear 10.5 and G3 work well, so that means our build system is in good shape. Were you able to give the WiFi location code a spin? It's the old code, so I don't see why it wouldn't work, but ... well, you know.

    ReplyDelete
  8. QTE on this site plays 1 frame....I think.

    http://www.dailymail.co.uk/news/article-2261750/Howard-Stern-Lena-Dunham-little-fat-girl-looks-like-Jonah-Hill-Girls-sex-scenes-rape.html

    ReplyDelete
    Replies
    1. You always find the most interesting URLs ...

      Anyway, I don't see an HTML5 video or YouTube video on that page, just a Flash one.

      Delete
    2. The David Letterman video..the context menu gives me "Open Media in Quicktime" & it does. Isn't that QTE doing its thing?

      Delete
    3. ...& what's with the fonts on the bottom of this page?...Not TFF problem but what's going on?

      http://montgomerynews.com/glenside_news_globe_times_chronicle/

      Delete
  9. > Isn't that QTE doing its thing?

    It's just an image. It's not actually the video. If you try to click on it to get a video element, it becomes Flash.

    As for the other URL, I don't know if something changed, but I don't see anything wrong with the fonts at the bottom of the page. The Facebook box is scrambled, but it seems like that's because the newspaper crammed too much text into it.

    ReplyDelete
  10. I've noticed a strange thing recently (since about TFF 17) - occasionally, with browser open and page already fully loaded, CPU usage goes very high and mouse movement becomes slow and jerky. Typing text becomes slow and jerky (holding down key would do a few characters at a time) - whether typed in the browser or any other program. Activity monitor shows that TFF is causing the high CPU usage. When the browser is closed, the jerky mouse movement and text goes back to normal. If the browser is reopened and the previous page loaded, it has no problem.

    It's too vague and irregular to do a bug report - but I'm just wondering if anybody else experienced this kind of thing recently.

    ReplyDelete
  11. A jerky mouse pointer looks like something very deep in the system is struggling. The only times I've seen this on Mac OS X was when recording audio via line-in with the buffer running low, or pre"viewing" audio filters in real time, because audio seems to have priority over everything on the Mac (which is actually good). I've never seen this with web browsers or any other applications.

    ReplyDelete
  12. SuperTuxKart 0.8 is available for Tiger and Leopard PPC: http://sourceforge.net/projects/supertuxkart/files/SuperTuxKart/0.8/SuperTuxKart-0.8-MacOSX-TigerPPC.dmg/download

    Screenshots: http://www.supertuxkart.de/stk08osxtiger.jpg

    http://www.supertuxkart.de/stk08-osx-ppc.jpg

    ReplyDelete

Due to an increased frequency of spam, comments are now subject to moderation.