Sorry about the RSS blip earlier; that was me hitting the wrong button. After a little more delay than I had previously planned, 10.0 beta is available, the first of our "stable" releases (based on the putative Firefox ESR).
Firefox 10 is actually a really strong release. In addition to the usual gratuitous UI change(s) (this time around it's the disappearing/reappearing forward button if you are using large icons in the toolbar), there are some remarkably solid additions in this release and my personal favourite is the Inspect Element feature. You can right-click on anything and select Inspect Element, and the HTML element appears in context with its children and parents, highlighted for your visual convenience. Even cooler is that you can dynamically alter the style, turn inherited and specified properties on and off, and find it within the page source. This is much like the old and much-beloved DOM Inspector (from Firefox 2.x and previous; still in Classilla and SeaMonkey) except that it is fully integrated within the main browser and not a separate XUL component. Great work, Mozilla!
Fx10 also includes 3D CSS transforms and properties. We render these in software (son of no-OpenGL-2-in-10.4), so performance is not great, but they work and they work surprisingly well, considering. Here is a static example from MDN: notice that all the 3D objects on the page are not images, but have selectable text, because they are in fact just transformed text. The proof of the pudding is in course in the animation, though, so why not a rotating HTML5 logo? Performs pretty well, even in software rendering on the 1GHz iMac G4.
Mozilla is also including a full-screen API where, if you permit it, a web page can dynamically open itself up to full screen. Now, if you're like me, you realize that the possibilities for phishing just jumped about twelve or thirteen times, and using it for full-screen video on pretty much any Power Mac is hopeless (my quad G5 even at full tilt can't push 1920x1080 WebM video in software). But it would be nice for presentations and other kinds of remotely-hosted demonstrations, and an excellent way to fool your boss that you're working (just switch to the tab with a static screenshot of Outlook taking up the whole screen :).
Finally, Mozilla has enough confidence in AMO to make extensions default to compatible. Now your addons don't get nuked every time you upgrade, unless, of course, the server says they are incompatible or they use binary or other unstable APIs. Those of you using the QTE will notice that it didn't get disabled like every other beta did. In fact, I didn't need to update any of my addons when I started using 10.0b1 personally. Nice!
Not all was wine and roses with the port. Besides breaking my keyboard over the weekend (and I really liked that keyboard, because it works well with all of my USB Macs even in OS 9), Mozilla upgraded the WebM libvpx to 0.9.7, wrecking our custom AltiVec work. This is not all bad because 0.9.7 is multithreaded and we support that on multiprocessor Macs, so this should help performance on marginal G4s with dual CPUs, and I was able to reconstruct most of our code in the end. Report irregularities.
Continuing in the bad news-good news department, tracejit is still in 10 but we can't ship it as default: SunSpider limps to a similar speed, but Dromaeo is 15-20% slower. I can't find a specific cause for this, and frankly if I try undoing things I'm likely to break JM+TI and JM+TI is the future. So the future is now. I am sufficiently confident in the performance and stability of JM+TI for it to now be the default. If you are using JM+TM, consider disabling tracejit entirely and turning on type inference before upgrading to 10 beta. I will leave tracejit in this release and the rest of the 10.0.x stable branch releases for those people who are absolutely convinced that methodjit is wrecking their machine somehow (it's not), but you need to be aware of the performance differential relative to 9, and it will not be in 11. We landed some microoptimizations and fixes in 10, but they are relatively minor and there is not much change in the numbers. However, Ben has some ideas on how to rework branches to more effectively make use of branch prediction and not make the backend insanely overcomplicated. We also have a new contributor who is working on a fast software square root for G3 and G4. This work will land on both stable and unstable, so there will be a beta for that particular stable release when it's ready.
Finally, something Mozilla did broke the way double and triple clicks select text. I think I have a workaround for it, but it might behave ever so slightly different from usual. Report non-trivial irregularities in issue 122.
Back in the good news column, Tobias' VMX text converters are patched up and back in with hardened algorithms, plus a new one for XPCOM text conversion, which should significantly restore page processing speed on G4 and G5. This completes most of the targets that support SIMD in Mozilla Core except for an obscure one that only deals with plugins, though we are always looking for others. None of these regress the infamous issue 84 and so I think we can call this a win. I also put in a minor fix to the backing JavaScript so that about:memory isn't a mess of unresolvable Unicode line drawing symbols.
It still isn't clear how Mozilla will handle the ESR rollout. My bet is that there will be a mozilla-esr repo or some such, from which we will pull for the stable releases. I am exploring low-cost ways of getting us an online helpdesk and support area for users so that we can eliminate our dependency on SUMO. Chris has volunteered to help with support. Other volunteers are requested. The beer offer stands.
For 11, we, and by "we" I mean "me," really need a break and this is the best one (closest to 10, so likely to have no major issues) to sit out on. I will still do a changeset for debug builds, but it's going to literally be just a placeholder, and there will be no binaries. If others want to take this one for the gap, go for it. Part of what I need the time for is to migrate www.floodgap.com off the 14-year-old Apple Network Server 500 that it still runs on to the big IBM POWER6 dual-core server sitting around idle except for being the gopher server and handling Veronica-2. There should be no service downtime like our unpleasant two months "network free" this summer because I'm simply going to transparently move the IP address to the new machine. I also really need to do finishing work on Classilla 9.3.0 and TTYtter 2.0 while I still have a chance. The next scheduled unstable branch release per se will be 12. I'm still planning to do it based on mozilla-beta if for no other reason than avoiding the small amount of perpetual churn on -aurora.
In the meantime, release notes and architecture builds:
This comment has been removed by the author.
ReplyDeleteConsidering that I personally use TenFourFox on my own iMac G4 and iBook G4, I'm not sure what to say to your statement (a 33% performance hit is not at all in line with my testing), but if someone wants to continue maintenance on 8 the changesets are certainly available.
ReplyDeleteI can't confirm a 33% performance hit in 9 or 10 compared to TFF 8. Not in Peacekeeper, and not in real life. It's more the other way around: The slow image drawing/scaling bug in 8 was an enormous performance hit for me as someone who has to view and research large, print resolution images in the browser. Especially the G3s, TFF 8 was pretty much unusable for my work.
ReplyDeleteJust had a thought for GREATLY improving performance on some-sites in the G3 and 7400 G4 builds of TFF.
ReplyDeleteWouldn't it be good to add an option to the 'Add Bookmark' dialog that provides the option to mimic a mobile user-agent for desired sites? I have noted that it was planned as a global option for Classilla, but at this point, my sister (who will not part with her classic iMac G3 400DV) has gotten into the habit of saving http://m. in front of any sites that give her grief in TFF and has even got me testing it with my Dual 533 G4 test machine, and with a large number of sites (like Facebook and Yahoo Mail), it is a lifesaver. So why not automate it for SELECTED sites through the bookmarks feature? Happy to lend a hand if you all like the idea and want a grunt to do some of the set-up on it.
For right now this sounds more like something that should be implemented as an add-on rather than core. There may already be such an add-on, in fact.
ReplyDeleteHowever, once we've dropped to feature parity, I think it's a reasonable feature to consider. FTR, in Classilla it will be a global default in 9.3.0. I have considered a site-switcher along these lines, but whatever code I write for Classilla will not necessarily translate to the much later code in TenFourFox.
Just checked and there is not anything in the addons area for it. I totally hear you though. You all have been working LIKE CRAZY and it is understandable that this would not be a priority.
ReplyDeleteThe only problem with having mobile agent as a global setting is that it is really only something that one wants when it is absolutely necessary. Setting it as a global would be like super-gluing on a welding visor or hasmat suit.
For Classilla, it really is. There's no reasonable way of upgrading the layout core in any reasonable timeframe that gets anywhere near Acid2 compliance, let alone anything else. Mobile is just a better fit, but people can still turn it off from the integrated user agent pref panel.
ReplyDeleteBut TenFourFox is still a very current core -- even the stable version is -- and the most important thing to drag the technology to the next ESR after this one if at all possible. After that mitigation strategies like the one you've suggested become viable options.
BTW: Have found a bug in TFF 10.0b1.
ReplyDelete'Save and Quit' works great, but the browser does not restore tabs after a crash. Just reinstalled the last version of 9 and it restores fine, so is not a prefs issue.
Tested on DP-533 G4.
I'll see if I can replicate that, but I'm more interested in the crash. If you have reliable steps for that, please post an issue in Google Code.
ReplyDeleteDear CSC: very sorry for the failing to mention, I did a force-quit to simulate the crash. I do this with each beta as part of the test routine. Have noticed another version (7 I think) that had problems with this and have tested for it every since.
ReplyDeleteTwitter's followers page has slowed to unusable w/ 10.0b1 on a 1.0ghz ppc7447, w/ MethodJIT + TI active. So much so that I can cold start safari, load the page, and view 'followers' faster than TFF can draw the page and run its JS.
ReplyDeleteTFF 9 w/ TraceJit + MethodJit was fluid and usable (and much faster). TFF 10.0b1 w/ TraceJIT alone is slow, but faster than MethodJIT+TI... haven't yet tried TraceJIT + MethodJIT.
Is there anything fundamentally incompatible between the Type Inferencing logic in a method-based JIT and a Tracing JIT?
Thanks!
FYI, it's likely a bug in JM+TI (it just shouldn't be so slow).
ReplyDeleteAlso, in 10 JM+TM no longer works, it's equivalent to plain JM.
>Is there anything fundamentally incompatible between the Type Inferencing logic in a method-based JIT and a Tracing JIT?
TI is useless for TM, what could be done at most is proper TM integration with JM+TI, but it's a lot of work, and it conflicts with current development direction.
@9988..., I just tried it (I have about 2300 Twitter followers) and the page comes up completely with everything loaded (pictures, followers list and all) in 20 seconds on my 1.33GHz iBook G4. So I can't verify what you're seeing.
ReplyDeleteYou can't use type inference with tracing because by the time the tracer is invoked, the JavaScript interpreter has already settled on a set of types in play by empiric observation (i.e., the code has run a few times and the interpreter is confident that it knows what types are actually being used). Type inference is only useful when you must compile the code from scratch.
That said, on all of my testing systems JM+TI is as fast or faster than TM. I suspect there is something wrong with your setup if you're seeing performance like that. However, if you are still convinced that JM is the problem, TM will not be removed from the 10 series stable branch.
@artphotodude, ah, okay. I will try that myself when I am on the development machine (I'm on my traveling iBook right now, which does not have debugging capabilities).
ReplyDeleteI just killed the process a few times and the tabs all come back. Maybe a profile glitch?
ReplyDeleteThank you for Tenfourfox:)I am useing TenfourFox 9.0 on My 800MHz Quicksilver (My main computer) and my iMac G4 1 GHz And My Green 400MHz iMac G3 DV. and it Works very good and is super fast! Please keep makeing TenFourFox For g4 it works Great and alot of us still have G4's:)
ReplyDelete>Please keep makeing TenFourFox For g4 it works Great and alot of us still have G4's:)
ReplyDeleteThere isn't any such plans, just a claim of one commenter that "TenFourFox 8 is fastest" (no other commenter here see that, it's not known whether his testing is valid - was it done with a clean profile, etc) and his allegation that "TenFourFox became G5Fox" (this is pure speculation on his part - does he even own a G5?)
Well, we do know for certain atypical workloads that tracejit is faster. On Kraken gaussian-blur, for example, TM is about 2x faster than JM+TI, though recent improvements in TI and Ben's suggested refactoring should narrow that gap. But if there were some other component of the browser that affected his experience, I can't reproduce it, and as zubr says we take pains to get our optimizations working on as many of the supported architectures as possible. The nice thing about open source is that if others see what he sees, the source and the changesets are available. De gustibus non disputandum.
ReplyDeleteOverall, am SOOOO impressed by how TFF has come along. v 6.0 almost seems unusable now (and it totally rocked regular Firefox at the time). If I win the lottery, will be sending you guys a big, fat donation.
ReplyDeleteThank you for your great work on this! It's wonderful to see older PowerMacs still supported.
ReplyDeleteI wonder if anyone has tried to build newer nightly builds of WebKit? The last nightly build for PowerPC processors is by far the fastest browser on a G4 1.25GHz SP running MacOS X 10.5:
http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r89812.dmg
And its the only browser on my G4 that plays Angry birds smoothly :) (although just the SD version):
http://chrome.angrybirds.com/
I started a google code project that aims to provide current builds of WebKit for 10.5 PowerPC:
Deletehttp://code.google.com/p/leopard-webkit/
This currently scores 357 in http://html5test.com .
I have many philosophical objections to WebKit which I won't air presently, but OmniWeb still generates WebKit builds for 10.4. They are, however, indicating that this will not be for much longer. I know Tobias has also done some experimentation with it.
ReplyDeleteAs far as speed goes, it's no secret that Gecko is slower than WebKit on graphics and display, and WebKit has significantly better hardware acceleration (we basically have none). However, we've got the edge on script performance and DOM. That said, I personally don't endorse WebKit for non-technical reasons.
I would love to use TenFourFox as the only browser, but unfortunately some sites are only usable on WebKit (like that darned Angry Birds). I hadn't really tried OmniWeb before, but for some reason OmniWeb seems to have the same html5 bugs as Safari 5.0.6 on MacOS X 10.5 (maybe the last nightly PPC WebKit build is newer than the one bundled with OmniWeb..).
ReplyDeleteI managed to found a later WebKit build (r91642 for 10.5) which seems to erase some html5 bugs, but if anyone has a newer build, that would be appreciated:
http://www.mediafire.com/?6bmd234gufc474b
I know this is getting fairly off-topic (sorry about that), but there aren't many sites with this many knowledgeable PowerPC users.
I like WebKit when used with iCab as I found its memory footprint to be the smallest. I'm currently using the latest nightly build.
ReplyDeleteI did start some work to make WebKit2 work on 10.5 but there are missing some basic non-opensourced functions.
Also I did start a backport of the TFF macro assembler but this needs the glue functions to be implemented (PPC assembly).
Until now the latest nightly is good enough for me.
Looking forward to beta 2, performance is back up to snuff with TJ in b1 (270), but a new showstopper bug has appeared where the browser autonomously goes into offline mode, frequently enough to send me back to 8 (285) for the time being.
ReplyDelete@commenter, I'm sorry about all the trouble you're having, but the nature of what you've been reporting makes me wonder if something else is going on with your system. I've had the same browser instance up since January 10th, and only then because I killed it on purpose to investigate @artphotodude's question. Do you have a bad profile, or perhaps an addon that's acting wrong?
ReplyDeleteI'm suspicious about SunSpider results not changing no matter what you do, and being so slow (G5 being twice slower than rather old Intel, after adjusting for clock frequency, is hard to believe for me). Have you checked that the time on SunSpider is spent mostly running compiled code and not somewhere else? Do some sub-benchmarks of SunSpider run disproportionately slow WRT Intel?
ReplyDeleteThis comment has been removed by the author.
ReplyDelete@commenter: Restart your Mac to make sure TFF isn't running. In the Finder, navigate to Macintosh HD>Users>[your user name]>Library>Application Support>Firefox and drag the Firefox folder to the Desktop. Now start TFF. A new Firefox folder with a default profile will be created. Now test TFF 10.0b1 with Peacekeeper and casual browsing and see if the problems persist.
ReplyDeleteI use the same PB 1.33 GHz model with 2 GB RAM and have been getting mostly consistent results of about 940-1000 points in Peacekeeper (old version) since TFF 4.0b9 (with default jit settings in about:config), while Sunspider and other JS-only test kits have generally yielded better results with each TFF version.
That said, using TFF 10.b1 with no restart for several days, and having one or more Facebook tabs open at all times, will push memory usage up steadily. Once it's over 500 MB, the browser does get noticeably slower, with lots of mini-stalls (RAM seeking?). Peacekeeper (new version) in this state goes down from 281 (Methodjit+type inference) to 232 points (I tested repeatedly to make sure it's not a coincidence). So, memory management still leaves a bit to be desired.
ReplyDelete>RAM seeking?
ReplyDeleteGarbage / cycle collection.
> memory management still leaves a bit to be desired.
Do you have evidence that it's browser's fault and not Facebook's? If the latter, then the browser can't do anything about it.
chtrusch, do you have evidence that it's browser's fault and not Facebook's?
ReplyDeleteI can make a page which will make any browser's memory usage go up like crazy, then cherry-pick one browser and claim "It's leaking memory!!!1"
ReplyDeleteOf course it's Facebook's fault. Safari acts similarly in RAM usage on Facebook, but it's better at freeing memory after it's done with complicated stuff.
ReplyDeleteAll I wanted to say is that "commenter" is not the only one observing degraded performance under some circumstances. I'm trying to make the circumstances reproducible and to find reasons. E.g., switching the JIT and then restarting the browser will of course free up memory and thus may give the impression of better results with Tracejit.
Fresh profile results: 266 b1, 277 b1 TJ
ReplyDeleteI get anything in the range of 267-281 (TJ or MJ+ti, doesn't matter) if I test long enough. This is the usual fluctuation in Peacekeeper results. The best method, I think, is to test at least three times each and average, or to only use the best result of each series, because that's what the browser is actually capable of, minus network slowdowns or whatever that causes these differences.
ReplyDeleteLooking at the project's download metrics one could infer that a "TenFiveFox" ought to be built, targeting G4e mobile users and 64-bit G5 systems on Leopard.
ReplyDeletePerhaps it could be released blog only?
I know the changesets are available, but no one is as qualified or eminently capable, I daresay, of churning out two such experimental builds on short order and there couldn't be a better time than the ESR.