Friday, March 29, 2013
Thursday, March 28, 2013
Now, this is sort of my fault, because this "fix" (I use the term advisedly) was even back in the betas, but I was slack in the non-Dobbs way and only ensuring that the tests succeeded, not what the actual numbers were. However, you can see from AreWeFastYet that in early-mid December (ignore the actual numbers, just look at the trends) the red JM+TI line suddenly worsened (that's us) in SunSpider and V8, and most of the V8 regression seems to have been due to V8-Richards, which took a nose dive around the same time. This isn't of interest to Mozilla, because they built a fast path into IonMonkey (instead of the quick'n'dirty stub for JaegerMonkey) and the combined purple JM+TI+Ion line marches downwards apace since V8 mostly runs in Ion now, and for ports stuck on the interpreter the speed is probably not any more perceptibly glacial than it was before. It's only us weird arch ports like MIPS and SPARC that have only methodjit, and we're the only ones to get screwed. A heads up would have been nice instead of an opaque message about a minor change to the JSAPI in the technical newsgroup.
As far as IonMonkey, I've actually made a bit of progress with it. By basing ourselves on the x86 backend -- which incredibly is cleaner than the perverse little ARM one -- I was able to use hints in their code to hopefully preserve all the hard work Ben did on our assembler, particularly his tinkering with G3/G4 and G5 branching for performance on specific processors. I need to do some work on the existing PowerPC assembler to add some new opcodes and Ion jump handling methods, but this is value-added work that shouldn't affect methodjit and will be silently part of 21. The Ion macro assembler, however, is not much like the methodjit macro assembler and will need to be written from scratch using the template in the x86 version. I'm still rather bearish on Ion because it does a lot of mucking around with stack frames, something PowerPC is not very good at, and it's questionable how much advantage it will take of our register set even though theoretically we can pump all 32 at it (but then we have to save those extra non-volatiles in every function prologue plus any non-volatile floating point registers, and that sucks, so we're not going to do that). I think I have all the pieces in js/src/ion/ppcosx; they just don't work or build, and much of the code isn't written (particularly the higher level abstract stuff which I don't even understand yet). The first order of business is just to get it to compile. Volunteers, as always, solicited. These pieces will be part of the 20 changesets when they become available, but if you want an early peek, just ask.
17.0.5 will fix websites using databases affected by issue 213 and should be out sometime this weekend or late Sunday, so watch for it then. 20 (also with that fix) will probably not be out until next weekend because I'm on a work trip in Sacramento, that wretched hive of scum and villainy known as the state capital, but we'll see if I can get some downtime between meetings. However, I want to do some basic compatibility testing on it prior to release to make sure our reverting the "fix" didn't cause some other unpleasant regression somewhere else, so I'll need to be at my desk first.
Monday, March 18, 2013
The orderly transition will happen like this:
- The home page, blog and Tenderapp end-user support will remain at the same locations until there is a reason to change.
- This Saturday, 23 March, all aurora or beta releases (i.e., with an "a" or "b" in their version number) will be deleted from Google Code, along with all retracted releases. Changesets will remain; only the binaries will be expunged. This should buy us enough space to get to 24, the expected next ESR and stable release. If you want these binaries, you must grab them by Friday. The only exception will be 4.0b7 and b8, simply for nostalgia.
- All 17.x stable releases and unstable releases through 22 inclusive will still be uploaded to Google Code as usual, using the space freed up above. I'm pretty confident we'll make it to 24ESR, so I'm going to proceed with that assumption (if we turn out to drop parity sooner, substitute that version for "24" in what follows). Starting with 24 aurora and 24 beta, these releases will be uploaded to Sourceforge, and the expected 24ESR stable branch (and subsequent unstable releases) will be offered only from Sourceforge. The final release of 17 will also be on Sourceforge for posterity. Development on Google Code will cease completely at that time and all links to it will be removed.
- During the migration to 24ESR, all open issues will be reviewed for relevancy and likelihood of repair. Open issues judged irrelevant and/or unlikely to be fixed will be closed. Other open issues will be reopened at Sourceforge and relevant context transplanted if possible, and then closed on Google Code.
- Existing wiki release notes will remain at Google Code indefinitely until Google Code declines to maintain the project's files, whenever that is. At that time, they will become permanently unavailable as I don't see any reason to transfer these to the new project. However, currently maintained wiki entries such as the FAQ, build instructions, etc., will be rewritten on Sourceforge during the transition to 24ESR, and all release notes for 24+ will only be on Sourceforge.
- Remaining archived stable and unstable releases will remain at Google Code indefinitely until Google Code declines to maintain the project's files, whenever that is. At that time, I'll have to decide whether it's worth putting them somewhere else, but until then the files will remain available from there.
In other news, the 20 port is very nice. You'll get to play with it in a little under two weeks. Besides further improvements to graphics performance, plus WebRTC and user media, you'll also enjoy the new downloads interface which is now finally default and judged ready for primetime. Mozilla continues to concentrate on improving throughput and it's definitely paying off.
Anyway, I think this little experience with Google Code goes to show that everything is only worth what you pay for it. Watch for more news here as we meet transition milestones.
Tuesday, March 12, 2013
To be frank, WebRTC per se has limited utility. While Fx20 has even better graphics improvement than 19, the low-hanging fruit is finally being plucked and graphics stack gains are likely to be less improved in 20 and 21. While audio-only communications should be possible on most G4s and maybe even upper-range G3s, full video and audio communication is likely only going to be satisfactory on high-spec multi-core G5 systems. The WebRTC library is massive, touching large amounts of browser code, and it required a lot of hacking to even build on 10.4. In fact, we are taking advantage of a minor Mozilla oversight: even though the default build uses a QTKit-based video capture system, and 10.4 should have QTKit, too many things don't work in 10.4's implementation and what does work in it does not properly mesh with the Objective-C support in gcc 4.6.3. But Mozilla also ported over the QuickTime 7 backend even though they themselves do not use it. This works nearly perfectly with 10.4; my iSight FireWire camera generated the image displayed, and theoretically any device that can be recorded by QuickTime is compatible with TenFourFox's implementation (however, my FireWire Orange Micro iBOT camera makes a scrambled image and I'm not sure what the difference is). If Mozilla or Google change the code so that the QuickTime backend doesn't work or is removed, then our WebRTC support might be shot. So far I've only tested the media capture components. It's entirely possible the networking section doesn't work right on 10.4 and I don't have a good way yet of testing this on my internal network.
So if it's so tenuous, and works fully only on a subset of Power Macs, and may one day not work at all, why put a lot of effort into it? The reason is simple: even though WebRTC is the best-known consumer, it's all part of a generic API called getUserMedia, which allows applications to capture video and audio for a whole range of functions. (Yes, audio works too, although there aren't a lot of examples that work properly with Firefox; most of them want Chrome. So much for standards.) For example, there's quite a few "photo booth" examples that let the browser capture an image and then work with it (submit it to imgur, save it to disk, you name it). The range of applications for even a simple feature like that should be obvious. Video display is run through QuickTime, meaning it can take advantage of all its little operating system cheats, and is AltiVec-accelerated on G4 and G5.
And, for you tinfoil hats, privacy is extremely rigid. The browser will make you verify when a page wants to get at your QuickTime video sources and let you pick the video and audio sources, which can be two different devices. If you refuse, nothing is sent. If you have no devices, nothing happens. I still need to do some polishing on the build system to make this work well, but I think it's good enough to unveil in 20. The interested can track progress in issue 214.
On the 17 front, a user discovered a serious bug in our IndexedDB support -- the compression library "Snappy" Mozilla started using between 10 and 17 never had its big-endian path turned on, causing corrupted tables and crashes on sites such as Kindle Cloud Reader. This bug affects all builds of Firefox on PowerPC and I upstreamed the fix in issue 213. It will be in 17.0.5 and 20.
That brings me to our second issue: we're running out of space in Google Code and although I filed a polite request for more quota (we're nearing our 4GB allotment), Google is balking at expanding our limit. We may need to delete some deprecated files and old betas (note: formal stable and unstable releases will never be deleted) to recover some of this capacity, or, look into a permanent solution if I'm not able to recover enough. We've never paid for the service, so I can't really be upset, but if Google decides they're not going to give us any more room we'll have to think of some other plan of action to keep things operating. While the wiki, issue tracker and build changesets would remain on Google Code for consistency no matter what, one option is to find (or, possibly, buy) off-site hosting for the binaries and/or try to start a mirror network. More hopefully next week when I get an up or down from Google Code's user support.
Saturday, March 9, 2013
Friday, March 8, 2013
Thursday, March 7, 2013
Monday, March 4, 2013
The other problem actually existed in 19 as well; if you resize a window to be larger, you might get a flash of black or garbage until the repaint driver wakes up and redraws the window. This is merely a nuisance really, but it looks ugly, so I'm thinking of how to force the resize event to invalidate immediately.
Intel 17.0.2 users affected by the freeze bug, recently confirmed by Claudio, may wish to watch issue 209. Again, no ETA -- it's unsupported, remember?
More this weekend when I'm back from my business trip.