Mozilla dragged its collective feetsies on Firefox 8 and didn't finally sign off on it until late this week, which is why this RC is so tardy. However, the G5 jammed all night (which was helpful because we had a winter storm, and it's keeping the office nice and cozy) and coughed out the release candidates for you the beta audience to bang on. As usual, reports of serious bugs appreciated, but most of the bugs I know about should be corrected.
Issue 84, the irritating table malformation bug, turned out to have been caused by one of our AltiVec optimizers (specifically for text fragments). This is a curious manifestation and one we would not have found in testing. We're going to be more cautious about further optimizations on this particular portion of code, but being the rash developers we are, more optimizations are nevertheless in the pipeline for 9. A fixed version of the optimizer is in the release and the parser bandaid can go into the rubbish bin where it belongs (whew!). Note that this means this bug never appeared on G3, because G3 uses the original C code.
Tobias is continuing his work on more AltiVec-specific optimizations and faster ones of what we've got. Many/most of his optimizations will appear in 9. However, priority one remains the methodjit and I'd like to make a public shout-out to Ben Stuhl who polished off the opcode work on it and it actually parses. It doesn't work yet, but this is super awesome stuff and he gets a beer too. I've got feelers out to another heavy POWER user who has expressed interest and if this gets off the ground, we may fork js into our own internal repo to speed collaborative development and merge this back into our usual changesets. The first draft of this will appear in the 9 beta changesets, although I doubt very much I will have it working by then. However, Ben's strong work puts us with a decent chance of having this ready by 10 beta, and Mozilla has given us until 11 before the tracer infrastructure is completely excised (a thank-you to Nick Nethercote and Dave Mandelin). More about that when 9 appears.
8 final still includes Tobias' patches for AltiVec JPEG decoding with ImageIO and faster AltiVec text processing. I also made a small tweak to the tracejit for a marginal performance benefit we weren't getting, and fixed the remaining theme glitches. This should cover all the major bugs. Those of you who hated tab dragging will be relieved to note that Mozilla has bowed to complaints and backed it out, but it will be returning. My estimated timeframe is somewhere around Fx10.
There is a simmering attitude of discontent with 8 (and to a lesser extent 7) that it has periods where it can drag or temporarily grind to a halt. I personally have not experienced this, but a fast G5 covers a multitude of sins and I know some of you have indeed seen issues like that which appear caused by some interaction with the database thread Firefox uses for history. This is not specific to us; it is a Mozilla bug and if you search Bugzilla there are several open and active issues related to it. It's hard to be maintaining a port of the browser and be the lightning rod for criticism of it when a good portion of perceived performance problems is systemic and not port-specific. I point out, for example, this comment (at the bottom); we'll use him as a public example since he has chosen to make his irritation public. Even though TenFourFox is a Firefox port, and does have its own unique issues, it is still overwhelmingly Firefox, and I think people should be willing to voice their concerns about the browser to Mozilla directly if at all possible. I can't be everyone's punching bag for a port where I control very little of the code, and I don't think there's any reasonable response I could make to a guy like that from this position (though I am reminded of this blog post). Unless someone comes up with Chrome for PPC, which has a huge hurdle and I know I've talked to people about that who have asked, you're stuck with Gecko, and Mozilla is already talking about dropping 10.5. Make it your own while ye may.
With that disagreeable topic dispensed with, let's go back to goodies. I've compiled the feedback on the QuickTime Enabler, most of it good -- people love it when it works, but it just doesn't cover enough of what's available. So for alpha 113 (yes, there have been almost 70 revisions between alpha 45 [7.0] and this one), we're concentrating on expanding site support and I've started with the big one, which is YouTube.
Let's talk a little bit about the technology behind the QTE so that the limitations can be understood. QTE works by grabbing video URLs (preferably to H.264 video) and stuffing them into QuickTime playlists which it then hands to QuickTime Player. TenFourFox is not involved in downloading the video or even authenticating to get the video; it's all streamed, played and managed by QuickTime 7. Because of this, videos that require session cookies (Vimeo) or authentication will never work with the QTE because TenFourFox can't tell QuickTime how to send that information -- there is no API to do so. For Vimeo, for example, you will still have to login and download the video, which fortunately you can do for free.
That still leaves many sites that don't require session cookies or the like, and YouTube is fortunately one of them. In this release of the QTE, you can now go to any YouTube video (that has H.264 video available -- most do), right-click on the page, and select SD, HD 720 or HD 1080. HD 1080, btw, will probably chug badly on anything slower than a G5, but a fast G4 should be able to keep up with HD 720. In fact, you can right-click on any YouTube embedded iframe and do the same. It works better if you have the HTML5 trial enabled so that you can see the video instead of a blank box, but it will still work. Try it on this (rather slick) Microsoft video reported by Engadget which has all three resolutions available. Just right-click on the video box at the end of the article, choose your resolution, and Cmd-F to enjoy a full-screen experience in QuickTime Player.
Some videos can't be accessed from YouTube in this manner and you will get an error if you try to. Sorry, I can't do anything about that. I have encountered exactly two in the 50-odd videos I have tested, though. This will also not work for embedded objects -- i.e., those sites that embed the actual Flash applet rather than the iframe, which is the preferred method. I am thinking of a way around this, but it is likely to be convoluted.
This version also corrects an issue with corrupted characters in the destination URL dialogue box and improves performance slightly. Also, the issue with the video not automatically starting on some systems is in fact a QuickTime settings issue. If the video does not play automatically (give it some time to buffer, please!), go into Preferences in QuickTime Player and make sure that Automatically play movies when opened is checked.
To install alpha 113, make sure that alpha 45 is removed (it should be, it's not compatible with 8), and download the .xpi. Drop it on TenFourFox and it will install. No restart is required; you can play videos immediately.
I would like other suggestions about services to add in the comments. These services should be popular, widespread and have known ways to access their video streams. As I mention, some will not be compatible with this method -- Vimeo is the most notorious.
Well, go to it and have fun. TenFourFox 9 beta is probably about two weeks away. Release notes and architectures:
So far, this is great. I guess I hadn't understand fully what Quicktime Enabler was all about, but now I do. It seems to work on Youtube. The videos with ads may be the ones that don't work, as they don't work with the HTML5 testing either.
ReplyDeleteThanks for the hard work!
That's probably it, yes. Good spot.
ReplyDeleteI should also point out, too, that when the video is loaded into QuickTime Player it is a fully-fledged QT movie. You can even save it to disk (save it without dependencies), convert it, anything.
ReplyDeleteAbout the QTE: When I joined the YouTube HTML5 trial, rightclicking the Productivity Future Vision video results in that special HTML5 context menu (with no "Open in QuickTime" entry). I have to disallow JS to replace or disable the context menu in the browser preferences to get the normal context menu.
ReplyDeletehttp://postimage.org/image/y1mnbdcx7/
I know, so I engineered a workaround. Right-click the page and the QTE will still recognize the video.
ReplyDeleteNice. Right-click anywhere in the page? That does work on YouTube, but not on the website embedding the video.
ReplyDeleteGive me a URL to look at. There is probably a zone that isn't a hotspot.
ReplyDeleteNever mind, I found one. I don't think I can work around or disable the HTML5 menu without causing other side effects. However, it should work by allowing you to click the link and play the video from the YouTube page; probably for this version it's better after all just to turn the HTML5 trial off, ironically.
ReplyDeleteA nice feature might be to automatically stop the WebM video from playing so that it isn't taking up CPU cycles; I'm mulling over how I can do that easily.
Superb. Tenfourfox 8 is fast. Faster than 7, faster than the earlier beta. Quicktime enabler works well on youtube, though my ibook G4 can only handle the SD stream.
ReplyDeleteI know you get many thanks, but thanks again for all this spectacular work everyone involved with tenfourfox is doing. Its a real public service.
Thanks, downloading now.
ReplyDeleteI have a question: Firefox will be getting auto-updating Chrome-style around Firefox 10 I heard, will TenFourFox ever be like that?
@RMT, no. We don't have the infrastructure and I don't like the concept personally.
ReplyDelete@Dave, yeah, my little Luxo 1GHz G4 barely handles 720. The 167MHz bus does help. They did land some fixes at the end of the beta cycle and Tobias came up with a safe, faster UTF-8 scanner, so these do improve the release version quite a bit.
Do you have any tips to optimize the about:config settings for an old PowerPC?
ReplyDeleteJust want to comment about misplaced criticism. I read the comment of the person you linked to and I have to say that this mindset is universal.
ReplyDeleteI work in the Graphic Design industry. In my 12 years doing this I've met many, many designers who are stuck in this attitude. Adobe changed this, Quark is expensive, that doesn't work, this is broken…on and on. The complaints are loudest when releases are new. None of these people can ever seem to understand that things change. Yet they work in any industry that is constantly changing. They want to hold on to the past because they are comfortable with it. Never mind that the past often exists with compromises and workarounds. Yet they always want to be able to produce the newest kinds of things.
No matter what industry it's the same. People like this want the new without change. Therefore anything that causes them change is the fault of someone else. Well, it doesn't work that way.
As to TTF, I've been with you since version 4. Wanted to find a way to run FF4 on my PPC Mac. It's improved every step of the way, keeping my Macs relevant.
Please continue the hard work. You have my support and good wishes.
Thanks for the kind word, Erik!
ReplyDeleteJohnson, the default settings in my experience work pretty well and some of the settings if manipulated badly can actually worsen performance. However, perhaps some of our users (I know Chris does) have some specific settings you can try.
This tweak has helped me considerably.
ReplyDeletehttp://blog.gnu-designs.com/solved-firefox-high-cpu-load-with-plugin-container/
Do a Google search for firefox high+cpu or firefox memory and you'll find a bunch of settings you can use.
Last night I also moved my cache to a 1GB flash drive I have plugged in to my USB port. That combined with Better Cache (and addon) has made for faster performance.
I'm surprised that makes a difference for you; TenFourFox's (unsupported) plugins mode is hardwired to only run plugins in-process. There is no OOPP support in Chromium for 10.4 (yes, there is Chromium code in Firefox), so we basically gut their library to run singly.
ReplyDeleteThe flash cache is a good suggestion, though.
Well. I have two PBs. One has 1Ghz processor (G4) with 1GB Ram and the other is 1.67 with 2GB Ram. On the slower processor (which happens to be the Mac I use the most for web surfing) this made a big difference.
ReplyDeleteI don't run clean. I have a lot of addons for various things so maybe it set off something else. I don't know. All I can say is that I had made most of the changes involving pipelining, ngpaint delay, etc and while those helped using this helped most. I had to create the values, but I went from 50-75 percent CPU usage on idle to a range of about 15-50% after applying this.
I've NOT done much if any of these tweaks on my other PB simply because it's faster and has more memory and consequently TFF blazes along pretty much unmodified.
My 1Ghz machine also suffers from a failed external cache so that is perhaps a contributing factor here. Last mention,. I'm running 10.5.8 on both machines.
I used to tweak nglauout.initialpaint.delay on different Macs (fast/slow line vs. fast/slow computer/browser), but from (at the latest) TFF 7 (or 6? I forget) this isn't necessary anymore. Assuming that you have a reasonably fast line, you can leave it at default (=it doesn't show up at all in about:config). With Gecko 1.x and on dialup (eons ago) I would set it to 5000 or higher. I also tweaked network.http.max-connections (and its siblings), which really helped, but in Gecko 2.x and with a fast line I get best results just leaving them at default. I used to play with these setting until recently, but most of the perceived changes were probably chance or placebo in FF 3/SeaMonkey 2 and later.
ReplyDeleteI use some settings that don't make the browser faster per se, but save me some time while browsing because they make my workflow faster:
I show the full URL (browser.urlbar.trimURLs = false).
In addition to the popup blocker I use browser.link.open_newwindow=1 and browser.link.open_newwindow.restriction=0 which prevents unexpected opening of new windows or tabs (*I* decide that with cmd-click).
layout.spellcheckDefault=0 (spellcheck is useless for me and gets in my way constantly).
mousewheel.withaltkey.action=0 and mousewheel.withaltkey.numlines=28 to allow faster scrolling through websites with the Alt key. I switch off anything related to smooth scrolling.
I'm running 10.5.8 on a 1.33 GHz G4 PowerBook. I'll try the flash cache thing, sounds interesting.
@chtrusch
ReplyDeleteCan we define "fast line"?
My boss has a 256KB connection here at work. I'm using that network wirelessly with my personal Macs most of the time. I share it with about 20 wired PCs, a server and 4 Macs. Thus fooling with these settings works for me. Especially nglauout.initialpaint.delay. I hate waiting for the dang page to load.
At home I have 4Mbs. I don't define that as fast, considering that my ISP offers 256k, 4, 10, 25 and 50Mbs and pages still load slow (without these changes). So, again, this works for me. Given the latencies inherent in the hardware of my Macs themselves at what speed can I expect these settings to pretty much not matter? What's considered a "fast line"?
Well, to me it did'nt matter anymore when I got the 16 Mbps line that gives me about 12 Mbps in reality. I would consider this a fast line although this is already below average (in Germany).
ReplyDeletenglauout.initialpaint.delay is also a matter of personal taste. Do I want to see *something* right away, so I can start reading (makes sense on a slow line), with stuff added as the page loads, text and pictures jumping around (nglauout=0), or do I always want the complete page (just use nglayout=50000 or higher, the page will be shown as soon as it's complete, you won't have to wait 50secs if it's done quicker)?
I guess the default nglauout=250(?) is a good setting for fast lines. People will see something pretty much right away (the 1/4sec wait is neglectable), and many pages will have loaded completely already (if the server reacts quickly), so people don't have to see jumping layout most of the time.
This works amazingly well in a first gen G4 mini running Leopard. I'm floored. Great work!
ReplyDelete