So while we didn't have anything on Firefox 4's numbers, we had more downloads in 30 hours than we did in a month on any of the individual betas. Not bad!
The change that I landed last-minute due to the crash that cropped up does have a performance impact, but some users are seeing a hit significantly worse than my measurements. I'll talk about that in a minute. If you are one of those users, and you weren't crashing in b12, you could revert to that temporarily pending followup. Note that you will get pestered to update unless you turn that off too.
I should also use this spot to state, since it was a big concern to people in the previous entry, that plugins will have glitches. The code holding it together is kludgy at best and will eventually not work, because these plugins are no longer updated for PPC, and I don't know what the changes occurring in "Firefox 5" will do either. Right now most of the glitches are limited to scrolling artifacts. I have always suggested installing an add-on such as Flashblock, which is what I do myself, and then you can enable only the Flash applets you actually need to see. Remember, plugins will be pref'ed off by default in the next major release due to imminent security and compatibility issues.
Which brings us to the next minor release. While Mozilla is hemming and hawing about how they will set up their new rapid release schedule, and I will of course have commentary on that when they're done, we're going to continue our development on this branch. The first and most important thing will be to find a faster fix for the crashed-out JavaScript issue 37 that does not hit performance as badly (preferably at all), but the second will be to get AltiVec acceleration into WebM playback. WebM actually, believe it or not, already has this code, but Mozilla is not using it. What we'll be doing is transplanting some more of the WebM accelerated source into the tree, then modifying the Mozilla build system to properly integrate the VMX accelerator code. Note that this will not require AltiVec: G3 users can still play WebM video, just with the non-AltiVec generic C decoder that is already in use. However, G4 and G5 owners should see a boost in performance; how much I don't exactly know yet, and we might need to translate some more of it manually. We'll start with that however.
Because both of these changes are a little risky, there will be a single minor beta (I think there's a Jonathan Coulton song by that title :P ) incorporating both new updates. I hope to have that out to play with in a couple of weeks. You will not be automatically updated to it -- watch this space for more.
The good news is that other than the known issues and the JavaScript performance question, there have been no major problems with the rollout. So job well done. More work ahead.
Wow, you're fast. I appreciate how quickly you respond to issues and make a real effort to deliver the best possible FF4 support on PPC machines. Thank you.
ReplyDeleteAltivec acceleration for WebM would be just perfect. I already noticed that WebM encoded YouTube videos (360p) stutter on my PowerBook G4 1.3 GHz, whereas H.264 ones (Safari…) play smoothly.
Right now I'm playing with the new Safari 5.0.4 (Safari or Tenfourfox will become my main production browser in the future). I will take more time to thoroughly speed test different Tenfourfox builds on different machines on the weekend. I will create a virgin user account for that purpose, no extensions, average several test runs, play with restarting the browser in-between tests, emptying caches, etc. etc. to get more reliable results. Maybe we can find a pattern here as to why results vary so wildly even on the same machine.
Why, flattery will get you everywhere! :) But, also, I'm not maintaining this as a hobby: this is MY browser, I use it! So when there's problems people are detecting, modulo outlying datapoints, it behooves me to be proactive because one day it might affect me too.
ReplyDeleteBy the way, I think I have a more refined fix for that crash. With this more careful workaround installed, my iBook G4/1.33 drops to 3400ms in SunSpider (down from 4200), which is actually a hair faster than it was in b12 (3600). Again, that number wasn't as dire as yours, but I definitely acknowledge the hit, and in the "minor beta" this fix will be part of it.
H.264 is probably not a good point of comparison because QuickTime can hardware accelerate it with certain profiles and Safari is almost certainly leveraging that. VP8 has no such advantage, and obviously in the Power Mac world, will never have such an advantage. It may be possible to get QuickTime to play some H.264 content as a host within the browser but I am doubtful because the Mozilla gfx stack isn't really set up for that (and it certainly won't be as a plugin).
What I'm hoping to do is, if we can't leverage the GPU, to wring more out of the CPU. The AltiVec acceleration enabler will get more power out of the G4/G5 that we're not using already, but I suspect H.264 playback in Safari will always eat our lunch simply because it has specialized hardware to throw at the problem.
I'm not sure whether H.264 html5 in Safari is GPU accelerated (PowerBook G4, ATI Mobility Radeon 9700): If I throttle down the processor to half speed in Energy Saver Preferences (=667 MHz), 360p H.264 starts stuttering a little. H.264 performance is a bit better than Flash, though (1333 MHz with Flash 360p: borderline case, but watchable; 667 MHz: forget it). WebM is completely unusable right now even at full processor speed.
ReplyDeleteHi,
ReplyDeletethank you for the really great work.
I've got a question - how can I change language in browser? it's English by default, but I want Russian (because i'm Russian :) ). I've tried to download .xpi lang pack from mozilla ftp, and to change locale in about:config. But after that there was some strange things with tabs and menus, so I have to use english lang... maybe there's a way to use other language in TenFourFox?
chtrusch, actually, that doesn't mean it's *not* GPU accelerated; it only means it's partially CPU bound and that is expected. Even the profiles in which it is GPU accelerated still require the CPU to do final compositing and container decoding, even if some aspects of frame decoding are handed off.
ReplyDeleteSee 4.0s in the blog entry I just posted: you're gonna get that JavaScript patch early.
Limbo, thanks for the kind word. You can't get 10.4Fx in Russian (n)yet :) -- localization packs for Fx4 don't yet work right in 10.4Fx because we use some different strings. See issue 42. I want to support this in the future and I look forward to people who are willing to submit the missing strings.
Oh, I didnt' know that.
ReplyDeleteI'll try the 4.0s build as soon as possible (the SSL thing is bad…). Thanks!
It's up now.
ReplyDeleteI did an extended speed test over the weekend. Here are the results:
ReplyDeletehttp://tinyurl.com/62l9l5s
I don't know how realistic these tests are. It's odd that Peacekeeper results have Ten4Fox and Safari (sort of) on par, while Dromaeo and Sunspider shows Ten4Fox about twice as fast. In real life, both browsers (on the websites I surf daily) feel about the same speed-wise. Safari gets dizzy, though, when more than a dozen tabs are open trying to load stuff at the same time; Ten4Fox remains rock solid with 30 tabs or more. Safari also gets slower over time with Ajax and must be restarted every once in a while to get fast again. On the other hand, Safari has more raw power with a single tab loading one very complex page. Both browsers are clearly tailored for different needs (Power User vs. Apple Store Customer).
Nice analysis. I think the difference is the graphics stack for Peacekeeper, since it does test and points out it does test graphics and animation performance, although I'm somewhat surprised that there was a significant difference between b9 and 4.0s; I didn't touch that code myself, but maybe Mozilla did. The graphics performance is something that I acknowledge is comparatively lacking (it's good, but it's not excellent). I really hope Mozilla lands Cairo 1.10 in the mozilla-2.0 branch and we should start getting back towards 3.6 screen speeds.
ReplyDeleteDromaeo and SunSpider are pure JS benchmarks and 10.4Fx's JIT should win those tests easily simply because it has a PPC JIT and Safari never will. I can make the JIT even faster, too, once I figure out a few root causes, but as I say for stable 4 I want to stay safe.
Exactly. Speed tests are fun for a while, but for productivity I need a stable browser, even if it's slower. That's why I still use SeaMonkey 2 as my main browser, but since it's dead now on PPC and there is no Ten4Monkey, Ten4Fox will probably become the successor for its browser module.
ReplyDelete