Showing posts with label qte. Show all posts
Showing posts with label qte. Show all posts

Saturday, February 4, 2017

An experiment: introducing the PopOutPlayer (plus: microbenchmarking PowerPC SPRs)

TenFourFox 45.8 is coming along -- Operation Short Change (my initiative to rework IonMonkey to properly emit single branch instructions instead of entire branch stanzas when the target is guaranteed to be in range) is smoothing out the browser quite a bit but there are hundreds of places that need to be changed. I've finished the macroassembler and the regular expression engine (and improved both of them in a couple other minor ways), and now I'm working on the Ion code generator. This mostly benefits systems that cannot fit generated code into cache, so while the Quad G5 with its (comparatively large) 1MB per core has only improved somewhere on the order of about 5%, I expect more on low-end systems because hot code is now more likely to stay in the i-cache. I am also planning to put user agent support in 45.8, and there are a few other custodial improvements. The idea is to release that to beta testing around Valentine's Day so I don't have to buy you lot any flowers.

A long while back I mentioned a couple secret projects; one of them was SandboxSafari, and the other was intended as a followup to the now obsolete MacTubes Enabler. That second project got backburnered for awhile, but since I'm noticing changes that may obsolete the work I've done on it as well, I'm going to push it out the door in its current state. Without further ado, let's introduce the PopOutPlayer.

This is not Photoshop. There is, just as you see, a floating video window playing the Vimeo movie that TenFourFox cannot (no built-in H.264 codec). In fact, I think this is the only way you can play Vimeo movies on Tiger now -- neither Safari nor OmniWeb work either.

Yes, it works fine with YouTube also:

Drop the application in your apps folder, drop the PopOutPlayer Enabler addon on TenFourFox, and then on any Vimeo (10.4 only) or YouTube (10.4 or 10.5) page or embedded video, right-click or SHIFT-right-click and select Pop Out Video. The video floats in its own window on top of other windows. You can close the browser tab and go look at something else while the video plays; the playback is a completely independent process. When you open another video, the window pops up in the same location where you left it. On multiprocessor Power Macs it can even get scheduled on another core for even smoother playback.

Sounds great, right? Well, there's a few reasons why I hadn't released this earlier.

First, the app itself is, and I'm actually feeling ill writing this, based on these sites' Flash players. Flash was the only reliable way to do playback and was even more performant than native H.264 in WebKit, and it also had substantially fewer user interface problems at the risk of sometimes being crashy. Flash is no safer now than it was before I condemned it from the browser, but I've learned a few lessons from SandboxSafari, of which the PopOutPlayer is actually a descendant. To remember its window location means we have to run the app with your uid (which eliminates SandboxSafari's primary means of protection), but we also have the advantage of only needing to support at most two specific video player applets, so we can design a very restrictive environment that protects the app from being subverted and rejects running video or Flash applets from other sources.

This different type of sandbox implements other restrictions, most notably preventing the applet from going full-screen. This is necessity reborn as virtue because most of our systems would not do well with full-screen playback, let alone HD (which is also blocked/unsupported), and prevents a subverted player from monkeying with the rest of your screen. The sandbox doesn't let URLs open from the applet either, and has its own Mach exception handler and CGEventTap to filter other possible avenues of exploit. However, that also means that you can't do many of the things you would expect to do if the Flash player were embedded in the browser. That won't change.

The window is fixed-size and floats. Allowing the window to resize caused lots of problems because the applets didn't expect to deal with that possibility. You get one size no matter how big your screen is, and you can only close it or move it.

Although the PopOutPlayer can play more YouTube videos than the QuickTime Enabler, there are still many it cannot play, though at least the Flash player will give you some explanation (the Vevo ones are the most notorious). The PopOutPlayer also isn't intended for generic HTML5 video playback; it doesn't replace the QTE in that sense, and the QTE is still the official video solution in general. The application will reject passing it URLs from other video sites.

The really big limitation, however, is that I could not get the Vimeo applet to run on 10.5 using the hacks I devised for 10.4. Leopard WebKit can play some Vimeo videos, so all is not lost, but no matter what I tried the PopOutPlayer simply wouldn't display any video itself. For the time being, Vimeo URLs on Leopard will generate an "Unsupported video URL" message. It is quite possible this might never be able to be fixed with the current method the PopOutPlayer uses for display, so don't expect it will necessarily be repaired in the future. For that matter, Vimeo on-demand doesn't even work with 10.4.

I consider the PopOutPlayer to be highly experimental, and when (not if) Vimeo and YouTube decommission their Flash players, it will abruptly cease to work without warning. But because I expect that time is coming sooner and not later you are welcome to use the PopOutPlayer for as long as it benefits you, and if I can solve some of these issues I might even make it a supported option in the future -- just don't hold your breath.

Download it here. It is unsupported. Source code is not currently available.

So back to TenFourFox. If you would, permit me now to indulge in some gratuitous nerderosity. Part of Operation Short Change was also to explore whether our branch stanza far calls could be made more efficient. Currently, if the target of a branch instruction exceeds the displacement the branch instruction (i.e., b(l) or bc(l)) can encode, we load the target into a general purpose register (GPR), transfer it to the counter register (a special purpose register, or SPR), and branch to that (i.e., lis/ori/mtctr/b(c)ctr(l)). The PowerPC ISA does not allow directly branching to a GPR or FPR, only to the counter register (CTR) and the link register (LR), which are both SPRs.

This would be all well and good except that the G5 groups instructions together, and IBM warns that there is a substantial execution penalty if mtctr and b(c)ctr(l) are in the same dispatch group. Since mtspr instructions like mtctr must always lead dispatch groups, the above stanza is guaranteed to put them both together (recall instruction dispatch groups are no more than four, or five with a branch, with branches being the last slot). Is it faster to insert nops and accept the code bloat? What about using the link register instead?

It's time for ... assembly language microbenchmarking!

#define REPS 0x4000
_main:
        .globl _main

        mflr r0
        stwu r0, -4(r1)

        li r3,0
        lis r5,REPS
        bl .+4
        ; the location of the following mflr is now in r4
        mflr r4
        addi r4, r4, 8
        ; now r4 points to the addi below

        addi r3,r3,1
        cmp cr0,r3,r5
        beq done
#if USE_LR
        mtlr r4
#if USE_NOPS
        nop
        nop
        nop
        nop
#endif
        blr
#else
        mtctr r4
#if USE_NOPS
        nop
        nop
        nop
        nop
#endif
        bctr
#endif

done:
        lwz r0, 0(r1)
        mtlr r0
        li r3,0
        addi r1, r1, 4
        blr
This just runs a tight loop 1,073,741,824 times, branching to the loop header with either LR or CTR, and with the mtspr instruction separated from the blr/bctr with sufficient nops to put them in separate dispatch groups or not (there must be four to prevent the branch from getting in the terminal branch slot). That gives us four variations to test with a loop so tight the cost of the branch should substantially weigh on total runtime. Let's see what we get. If you're following along on your own Power Mac, compile these like so:
gcc -o lrctr_ctr lrctr.s
gcc -DUSE_NOPS -o lrctr_ctrn lrctr.s
gcc -DUSE_LR -o lrctr_lr lrctr.s
gcc -DUSE_LR -DUSE_NOPS -o lrctr_lrn lrctr.s
If you want to confirm what was actually assembled, you can look at the result with otool -tV.

Our control will be our trusty 1.0GHz iMac G4 (256K L2 cache). There should be no difference between the SPRs, and it all fits into cache and there are no dispatch groups, so if we did this right the runtimes should be nearly identical. In this case we are only interested in the user CPU time (the first field).

luxojr% time ./lrctr_ctr
7.550u 0.077s 0:08.88 85.8%     0+0k 0+2io 0pf+0w
luxojr% time ./lrctr_ctrn
7.550u 0.071s 0:08.55 89.1%     0+0k 0+0io 0pf+0w
luxojr% time ./lrctr_lr
7.550u 0.070s 0:10.08 75.5%     0+0k 0+2io 0pf+0w
luxojr% time ./lrctr_lrn
7.550u 0.069s 0:08.43 90.2%     0+0k 0+0io 0pf+0w
Excellent. Let's run it on the Quad G5 (numbers in reduced performance mode).
bruce% time ./lrctr_ctr
4.298u 0.028s 0:04.33 99.5%     0+0k 0+2io 0pf+0w
bruce% time ./lrctr_ctrn
4.986u 0.035s 0:05.03 99.6%     0+0k 0+2io 0pf+0w
bruce% time ./lrctr_lr
13.755u 0.050s 0:13.82 99.8%    0+0k 0+1io 0pf+0w
bruce% time ./lrctr_lrn
13.752u 0.048s 0:13.82 99.7%    0+0k 0+2io 0pf+0w
Wait, what? Putting mtctr and bctr in the same dispatch group was actually the fastest of these four variations. Not only was using LR slower, it was over three times slower. Even spacing the two CTR instructions apart was marginally worse. Just to see if it was an artifact of throttling, I ran them again in highest performance. Same thing:
bruce% time ./lrctr_ctr
2.149u 0.012s 0:02.16 99.5%     0+0k 0+1io 0pf+0w
bruce% time ./lrctr_ctrn
2.492u 0.010s 0:02.50 100.0%    0+0k 0+0io 0pf+0w
bruce% time ./lrctr_lr
6.876u 0.013s 0:06.89 99.8%     0+0k 0+0io 0pf+0w
bruce% time ./lrctr_lrn
6.874u 0.017s 0:06.89 99.8%     0+0k 0+1io 0pf+0w

I found this so surprising I rewrote it for AIX and put it on my POWER6, which is also dispatch-group based and uses an evolved version of the same instruction pipeline as the POWER4 (from which the G5 is derived). And, well ...

uppsala% time ./lrctr_ctr
3.752u 0.001s 0:04.41 85.0%     0+1k 0+0io 0pf+0w
uppsala% time ./lrctr_ctrn
4.064u 0.001s 0:04.94 82.1%     0+1k 0+0io 0pf+0w
uppsala% time ./lrctr_lr
13.499u 0.001s 0:16.19 83.3%    0+1k 0+0io 0pf+0w
uppsala% time ./lrctr_lrn
13.215u 0.001s 0:15.66 84.3%    0+1k 0+0io 0pf+0w
Execution times should consider that I run this POWER6 throttled in ASMI to reduce power consumption and its microarchitectural differences, but the same relative run times hold. It's actually not faster to space the CTR and branch (that is, if there's nothing better you could be doing -- see below), and the CTR is the best SPR to use for branching on the G5 regardless of any penalty paid. It may well be that using LR fouls the CPU link cache and thus tanks runtime, but whatever the explanation, using it for far calls is clearly the worst option.

Now, as you may have guessed, I've deliberately presented a false choice here because all four of these options are patently pathological. The optimal instruction sequence would be to schedule some work between the mtctr and the bctr. We don't have much work to, uh, work with here, but here's one way.

#define REPS 0x4000
_main:
        .globl _main

        mflr r0
        stwu r0, -4(r1)

        li r3,0
        lis r5,REPS
        bl .+4
        ; the location of the following mflr is now in r4
        mflr r4
        addi r4, r4, 8
        ; now r4 points to the mtctr below

        mtctr r4
        addi r3,r3,1
        cmp cr0,r3,r5
        beq done
        bctr

done:
        lwz r0, 0(r1)
        mtlr r0
        li r3,0
        addi r1, r1, 4
        blr

bruce% gcc -o ctrop ctrop.s
bruce% time ./ctrop
4.299u 0.028s 0:04.34 99.3%     0+0k 0+1io 0pf+0w
Almost identical runtimes (in reduced mode), but the beq takes the branch slot away from the bctr, guaranteeing the SPR operations will be split into two dispatch groups without trying to space them with nops. But inexplicably, if you coalesce the beq/bctr simply into bnectr (which does occupy the same branch slot), you get even faster:
bruce% time ./ctrop2
3.824u 0.039s 0:04.02 95.7%     0+0k 0+0io 0pf+0w
Is this optimal on the G4 and POWER6 as well?
luxojr% time ./ctrop
6.472u 0.064s 0:12.05 54.1%     0+0k 0+2io 0pf+0w
luxojr% time ./ctrop2
6.471u 0.063s 0:09.33 69.9%     0+0k 0+0io 0pf+0w

uppsala% time ./ctrop
3.918u 0.001s 0:04.61 84.8%     0+1k 0+0io 0pf+0w
uppsala% time ./ctrop2
2.612u 0.001s 0:03.09 84.4%     0+1k 0+0io 0pf+0w
Yup, it is, though it's worth noting the G4 did not improve with the bnectr. (This is still pathological, mind you: the best instruction sequence would be simply addi/cmp/bne, which the G5 in reduced mode runs in 2.580u 0.029s and the POWER6 in 1.261u 0.001s, reclaiming its speed crown. But when you have a far call, you don't have a choice.)

The moral of the story? Don't fix what ain't broke.

Thursday, May 7, 2015

The End of the Road for MacTubes Enabler, et al?

As Dan DeVoto reports, Google in its never-ending arms race to prevent people watching YouTube clips in convenient and less annoying ways has caused them to shut down the YouTube v2 API in favour of the v3 API, which is more complex, requires an API key, disallows downloads, and demands you to send your nubile young daughters to Eric Schmidt is the typical unnecessary API churn that occurs whenever people try to rely on a Google-based service like, you know, Google Code. (What's that, Google? My blog violates terms of service? Oh yeah? Well, I've got your terms of service RIGHT HERE.) The upshot is, virtually none of the YouTube clients for Power Macs, including MacTubes which was my personal favourite, will work anymore.

Fixing MacTubes will not be trivial. Although I have the source code for it, which the author graciously provides, it relies on the older GData framework. Unfortunately, the API is so different that it will need to be completely rewritten and some features will probably not translate. If/until that happens, the MacTubes Enabler (MTE) will no longer be supported, though the QuickTime Enabler (QTE) will still work for those YouTube videos it generally supports (it relies on a different method which Google will probably break again next week), and of course WebM still functions on YouTube if your Power Mac is fast enough and the video is available in that format.

I suppose this is a good time to mention that I've been working on a sandbox solution for "things like this" as a secret project for some time on the side. I will only say that it exists as an internal proof of concept and actually works, but I'm not offering more information until I have something releaseworthy and that's not going to happen until 38 comes out. For the time being, we appreciated all the work that went into MacTubes and its related applications, and we will be overjoyed if they are fixed, but I'd rather just find a way around Google instead of playing their stupid little games with their moving-target APIs. That is where our effort will be focused post-38.

31.7.0 is scheduled for testing availability this weekend, just in time to upgrade your mother's computer, because she loves you and misses you and wants to know why you never call.

Sunday, May 25, 2014

31: close to beta (plus: new QTE and Mac|Life goes Low End)

Good news: there's going to be another stable release; 31 builds, links, gets off the ground and generally works. Yay! 24 will go into maintenance mode until 31 is ready for prime time, but the chance is better than even money that we'll have an on-time launch.

Between 29 and 31, Mozilla reworked the basic layers canvas code and this fixed the display problem with Google Maps and a lot of other sites. Plus, there don't appear to be any new regressions with the graphics code switching to Moz2D, and our "blue thumbnails" patch sticks fine in 31, so that's a lot of potential problems avoided and repaired.

The four major bugs we have left are all holdovers from 29, except this one: Google Maps does display correctly now, but it crashes with a null pointer assertion within the JavaScript virtual machine even with the JIT off. This looks like an endian problem introduced with bug 912456 or a related patch; simply wallpapering the assertion to make the browser continue doesn't cause any crashes, but Google Maps won't download new map content, so that's not very helpful. I consider this a showstopper. However, I also have a good idea where the problem is.

The second major bug is that the current version of the QuickTime Enabler does indeed hang up in TenFourFox 29+, as reported by a couple folks earlier. This is a problem with the old Add-on SDK jetpack version in v116, confirmed in that the MacTubes Enabler, which has a later jetpack, doesn't do this. Both of them will need a jetpack update for 31, but I updated the QTE jetpack and added a couple minor bug fixes and released that as QTE v120. You can get it from the QuickTime Enabler wiki page. It will work with 24 and 31 both, and then the QTE and MTE will be refreshed again after 31 is released. So that should be solved.

The two remaining issues are also 29 holdovers and while I consider them important to fix, I don't consider them showstoppers. It does look like editing keys have regressed per your reports, but not all keys have, so I'm not sure what's going on (menu keys and productivity shortcuts, for example, all function). This looks like our bug, but while I intend to fix it I don't consider this a shipping blocker for 31.0. Also, we still have the problem where webcam audio does not work (and neither does video-with-audio). However, our patch to force webcam video and video-without-audio does work, so the webcam can still be used for snapshots as its primary use case, and this is also shippable even if it's suboptimal.

31 also uses Mozilla's new generational garbage collector (GGC), which is even more aggressive about memory than the exact rooting GC in 29. The settings 29 use that we experimentally determined earlier in this blog are tuned for the older conservative garbage collector and may be counterproductive with GGC. I will likely change the time slice and some other parameters for 31 beta, so if you are using these custom GC settings please revert them before upgrading or the browser may not perform well.

Other than that, the browser appears to work fine and I think we're in good shape for another successful stable branch. Once I have the Google Maps problem fixed, I'll grab the beta source when 31 migrates from aurora and we should have a full-spectrum 31 beta release available a few days after the 24.6.0 update. Speaking of, 24.6.0 will be a security update only; there are no bugs on our side that will land, and I am not likely to do further feature work on 24 as the switchover to 31ESR approaches.

By the way, if you've got a newsstand nearby, you might want to pick up the current (June 2014) issue of Mac|Life and their article on rejuvenating your old Mac:

Even though it's a relatively basic article and their tips won't be big news to most of this blog's denizens, it's nice to see classic Macs still getting coverage in major Mac publications, and they even have a little section on Linux and alternative operating systems. Thanks to @thedoctor on App.net for spotting their shouts-out to TenFourFox and Classilla -- that's how you know you've arrived.

Friday, January 24, 2014

Ten years of the Twentieth Anniversary Macintosh ... or something (plus: try MTE v2)

The Twentieth Anniversary Macintosh still doesn't know what to make of this:

On the other hand, I have a 1984-2004 poster on my machine room wall.

And yes, today is indeed the 30th anniversary of the original Macintosh Super Bowl big game ad, for those of you hiding out under a rock for the last several decades. Apple did a retrospective video for apple.com, which because they used a weird manner to do it, is not compatible with the QTE. However, here are the low bandwidth and high bandwidth versions (QTE users can right click and select "Open Link in QuickTime" to play the movie). While much of it is the usual Apple equals sex design twaddle, the following classic and vintage Macs are featured, in order of appearance: the original 128K (of course), the Macintosh XL (presumably standing in for the Lisa), the Macintosh II, the Macintosh Portable, the Macintosh LC, the PowerBook 100, a Quadra 9x0 (either a 900 or a 950, amusingly lacking the key), a Color Classic, a Power Macintosh 8500 or 9500, a Macintosh SE/30 (called SE 301, with an FWB hard drive icon), a Twentieth Anniversary Macintosh (mine is better), a tower beige Power Macintosh G3, a Bondi Blue iMac G3 (the machine that arguably saved Apple), a graphite Power Mac G4 (either a Yikes! or a Sawtooth), a Blueberry iBook G3, a Titanium PowerBook G4, a 15" iMac G4, a 14" iBook G4, and finally the Power Mac G5. After that is all the Intel rot. But it's fun to see the creative luminaries assembled for this well-produced short, and of course the return (however briefly) of the rainbow Apple logo we all loved back when:

For the record, I own about 2/3rds of the featured pre-Intel Macs; the first Mac I used was my friend's dad's Mac Plus, and the first Mac I personally owned was a IIsi. And, btw, as a physician the scene of an iPad over a sterile surgical field near the end makes me shudder.

The real anniversary for us is March 14, 2014, the 20th anniversary of the Power Mac 6100 and the first Power Mac (along with the 7100 and 8100). I remember the new Power Mac well when I was in college. We'll do a special retrospective then.

No one has indicated serious intestinal distress over the highly automated way I've taken the new MacTubes Enabler, so you can download a prototype and try it. Here's an appropriate one: the Apple 1984 Super Bowl big game ad. As a bug I've subsumed as a feature (I think this is a glitch in the Add-on SDK), if you search for a video in YouTube and go to it from there, the video plays in the browser, so you can still interact with the (puke) comments and (gag) other users. But if you click on a YouTube URL anywhere else, or you cut and paste a YouTube URL into the address bar, it automatically opens in MacTubes and goes back to what you were doing. If the URL opens in a new tab, the tab automatically closes. Try it. I like it.

24.3.0 should come out this week or weekend.

Friday, November 15, 2013

The MacTubes Enabler. Because we loved all those damn System Enablers back in the day.

H.264 is still several cycles away -- IonMonkey and Australis have highest priority for new development. But that doesn't mean we shouldn't look for shortcuts, like the QuickTime Enabler, which has gradually evolved over time into a general purpose tool for pushing video to QuickTime for external decoding (where possible, of course, and it isn't always).

In that vein many of you have explored and used MacTubes, which is a delightful tool for direct playback of YouTube videos. It's kept up to date with Google's frequent screwings around on the backend, it has a variety of playback methods including Flash, WebKit and QuickTime, and it's probably the highest performance way to play YouTube videos on a Power Mac (even HD is possible with sufficient grunt). I downloaded the source to play with and discovered it can be fed a URL through Launch Services, so I tried that, and it worked -- it figured out the video location and automatically started playing it.

Thus, may I present the MacTubes Enabler for your consideration. The MTE reuses a bit of the Carbon-CoreFoundation-JavaScript glue from the QTE, but is far simpler: it just pushes the YouTube page you're on to MacTubes, and MacTubes does the heavy lifting and starts playing it. Piece of cake.

The MTE also has a trick that the QTE doesn't yet: you can direct it to start playing in MacTubes and close the tab in one step. One big irritation involving the QTE, and with YouTube in particular, is that YouTube will start streaming the WebM video while the QTE is trying to load the H.264 version at the same time (this can be bad enough on a slow link to make QuickTime think there's no data and give up). There used to be browser addons that would defeat YouTube's autoplay feature, but none of them work anymore and Google seems to be trying to bust these techniques also, thus this feature (that will always work): now the full bandwidth is devoted to streaming the video through MacTubes. If people like this feature, I'll add it to the QTE. (Another idea might be to back up to the previous page, or if there is none, then close it. What do you think?)

The MTE does not replace the QTE (and, for that matter, the MTE is completely independent of the QTE; you can have both of them installed simultaneously, even): you'll still need the QTE to play non-YouTube HTML5 video, which MacTubes doesn't handle, and if MacTubes becomes unsupported one day we'll still need QuickTime. (However, I'm able to build MacTubes from source on my G5 independently, so that's a solveable problem if its author someday decides to hang up his hat.) I'm also not planning to merge the MTE and the QTE for the foreseeable future because it's nice to have a playback alternative, and saving video and getting to HD formats is a little easier in QuickTime Player.

Consider the MTE a beta and give it a spin. Download it from its wiki page. The MTE requires TenFourFox 24. Test it out on Jean-Claude Van Damme injuring himself, or maybe some of MTV's finest cartoons when they actually played music.

17.0.11 is live. I'm going to make one tiny change to garbage collection scheduling to help intermittent stalls prior to release of 24.2.0, which should be the first public release. It looks like we will have a mostly full set of langpacks, too, so a "great work, guys" to Chris and all the localizers.

Monday, October 29, 2012

17.0 beta 2 and QTE v.116

17.0 beta 2 is out, available from (guess where?) the Downloads tab. I wanted to do some work on issue 187 first, since I suspect it is a simple issue, but it was more important to get this into your hands since there is security content in it. Please upgrade if you are still using beta 1.

The font fix has either completely repaired or significantly improved the situation of all those who have reported in. If you are experiencing missing text, "boxes" or weird fonts, please try this release. Fonts that are filtered by this fix are logged to Console.app so you can see what's going on, and the filtering only affects TenFourFox, not other apps on the system.

In addition, the new QuickTime Enabler v.116 is out for 17. There are no new features, but it fixes the jetpack SDK in use to avoid a potential security hazard. You should upgrade to 116 if you are using 17. Only use v.115 if you are still using 10.x.

Finally, we have German, French and Polish language packs in issue 61, and our new addition is Swedish. Please test the locale installer for your chosen language and give Chris feedback so we can have the language packs available on 17's launch day. 10.0.11, the final release of 10.x (I hope), will be built and made available the weekend of November 16; 17.0 will be out shortly after and made available to the public on November 20, just in time for us to give thanks for our bountiful Power Macintoshes.

In Mozilla news, Growl support gets a reprieve for Firefox 18 while we wait for XUL notifications to become a reality. I plan to support XUL notifications, since they will be more flexible than Growl and more future-proof, but until then we need Growl, and it looks like it will be still there for at least the next two releases. We'll see what happens with Fx19. Also, the patches currently landing for drawing browser content in the titlebar, which is a pre-requisite for Australis (the new Firefox interface), look like they will probably work fine with 10.4. More about that later; Australis is not likely to land for Mac anytime real soon.

Saturday, October 13, 2012

QuickTime Enabler v.115

Are you sick of me yet? QuickTime Enabler v.115 is out, but it requires TenFourFox 17; it is not tested, nor supported, with 10.x. and since by accident I built it with an old addon SDK version, we will offer it for 10.x users as well; there will be a v.116 for TenFourFox 17 with the correct SDK. This v.116 will become the new QTE when 17.0 becomes final. Test it!

This version fixes the problem with YouTube URLs, so they should work again (well, at least as well as they usually work, which is fine with non-ad-based videos and crummy with ones with ads), and allows you to directly feed a link to QuickTime Player (so you can right-click on a link to an MP3 or video file, and the URL will go straight to QuickTime Player as if you had right-clicked on an HTML5 video). Note that it will offer you this option on any link, since it really has no way of knowing what's on the other end, so don't expect you can play your tax returns in QuickTime Player, and they would probably sound pretty ominous.

So go grab the stuff. It's Christmas in October, yo.

Saturday, July 14, 2012

10.0.6 available, QTE goes beta, and more Mozilla soap operatics

The RC for 10.0.6 is now available. Please give it a spin. Assuming no issues, it will be released to the yearning masses on Monday evening. Here are the release notes.

As the release notes will intimate, 10.0.6 has the JIT latency patch and a preventative (hopefully) tweak to the JIT trampoline to avoid a crash which cropped up early in the 14.0 cycle. Unfortunately, 10.0.6 is also missing something now: the tracejit. Although severely gutted and not fully functional, TM was left in 10.x for purposes of comparison against JM+TI. However, one of the security patches in this release causes the tracejit to no longer compile and breaks the build, and I am not entirely certain it can be repaired even if it were worth it to repair, so this last remnant of TraceMonkey is now sadly gone. If you were one of those users who turned off JM+TI and turned on TM against my advice, you will no longer have JavaScript acceleration; it will simply run in the interpreter. It's time to come home and turn methodjit back on. Sorry. Remove your hats, and let us have a moment of silence for TraceMonkey, which brought us a long way.

(moment of silence)

I have also promoted the QuickTime Enabler to beta, and created a QTE wiki page to promote it to users. To maintain compatibility with 10.x, this is the same version (v.114) we used for the QTE alpha. Feedback from the larger user base will then be used to create a 17.0-specific QTE. Unfortunately, as I explained earlier, the Jetpack library I used to create the QTE does not lend itself to making the QTE a permanent part of the browser, so it will remain an optional add-on.

A postscript to the Mozilla drama I reported on two posts ago. Gervase Markham is a solid, stand-up guy who has helped us out several times, but I am unhappy with this blog post saying these kinds of Mozilla discussions should go underground. Moving soulsearching or controversial discussions like Jono's into a secured, less-public forum is the last thing that Mozilla needs. Besides the self-serving interest that having Mozilla discussions in public fora allows ecosystem projects like us to have a voice in things coming down the pike (none of us are paid Mozilla staffers and while I have a seat on Mozilla's security group, I am only a contributor and not a regular "Mozillian"), the upshot that should have been learned is that Mozilla didn't listen to community frustration until it boiled over. And Asa Dotzler, G-d love him, has regularly and often made controversial policy statements in public for freaking years; they just happen to be controversial statements that MoCo agrees with. Frankly, I don't think "a safe place to vent" is really the issue here.

More to the point, limiting these kind of discussions to secret dark corners makes the project just as closed as, say, WebKit, and increasingly Mozilla's openness is the only thing that makes it distinctive nowadays. I have long complained in this blog about public sniping of a project without involving the creators to make it better, but what's worse is insulating real discussion of real concerns away from constructive analysis. We're open here. We don't restrict comments, even if I totally disagree. We solicit them, for better or worse; just don't do it behind our back. If Mozilla pulls this kind of metadiscussion inwards, they will lose the community feeling and sense of open ownership that makes them unique. Weathering such discussion would be painful for anyone and it's hard to listen to, no doubt. But it's important that they do, and that process of public involvement is a big part of what makes Mozilla special.

Tuesday, December 13, 2011

QTE 9 available

The QuickTime Enabler for 9.0 is now available (alpha 114). As the version bump indicates, the only change from a113 to a114 is compatibility with 9. I am really hoping that Mozilla starts issuing simultaneous Add-On SDK compatibility updates with their betas, because it somewhat harshes our buzz to lose the QTE temporarily when we test our own betas. However, the QTE does not seem to cause any problems with stability, and because of this we may simply start including this as a built-in part of TenFourFox (I have not decided yet).

Simon Royal from LowEndMac has been trying to drum up interest in porting one of the open-source Flashes to PPC OS X. This is not a project I can personally donate time to, but if some of you out there are looking for a project the best one to port would be Lightspark (plus-minus Gnash for the older Flash applets), as it contains the most current version of the Adobe ActionScript virtual machine. The code is known to already work on PowerPC Linux, but the code would need to be altered to use either QuickDraw or CoreGraphics, and it would need to be buildable on OS X, so the port is possible but non-trivial. I'll add a carrot here: if someone gets this running and is able to maintain it, I will consider (technical limitations notwithstanding) lifting the plugin embargo. If the plugin exists, the plugin code in TenFourFox still works (we no longer test it, people are on their own) and someone is keeping it up-to-date, I'll not let it wither on the vine from this end. It's not much of a carrot, but hey, if you're just hanging around the house on the weekends now's your chance to be an abandoned platform rockstar.

Mozilla is due to sign off on Firefox 9 tomorrow, and we will do RC builds immediately after that. Tobias has fixes available for our VMX text converters which will appear in the beta immediately following. We also have a fix in tree for the icons problem, which is Mozilla bug 705516, so those of you using the image.mem.decodeondraw tweak mentioned in that bug should set it back to true before you upgrade to the RC or you will use more memory unnecessarily. RCs willl be announced here when they are ready, most likely by Friday or Saturday.

Methodjit is pretty much done, but we still have six tests (though out of over 1700) that fail and the browser is not able to stand up with the current code. I have not decided if I will hold Firefox 10 until methodjit is done -- tracejit is still in 10, just disabled. That buys us time for me to fix the last remaining failures by the end of tracejit in Fx11. Remember, don't try to enable it in Fx9 -- it will almost certainly not work, even though it is "secretly lurking."

Saturday, November 5, 2011

8.0 RC and QuickTime Enabler alpha 113 now available

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:

Friday, September 23, 2011

Super omnibus update: 7.0 RC, updated QuickTime Enabler, and Floodgap is back up

Well, heck, let's start with the good news first. AT&T installed the T1 on Monday and DSL Extreme activated it earlier today, so Floodgap and its associated projects, including TenFourFox.com, is back online. Point your friends, enemies, rather less good enemies of theirs and friends of those people's less good enemies to it.

The T1 comes at (naturally) a substantially greater hosting cost; though it is amortized against using it for my other projects and as my regular means of Net access, it's still a pricey (but very smooth and low-latency) way of getting hosts online compared to DSL or cable, neither of which were practical options for reasons many of you already know. As a policy matter I do not accept project donations as this has the risk of encouraging expectations I and the other contributors can't satisfy, but I am considering allowing Blogger to put ads on this blog to make a little of the money back. I won't object if you Adblock them away, of course.

Mozilla has signed off on the 7 release candidate, so now we have our release candidate available ahead of Firefox 7's formal launch on September 27th. As with previous release candidates, if there are no showstoppers then this will become the formal release. There is one small fix in this version (in addition to Mozilla's fixes): because Floodgap was down there was nothing to post update snippets against, so this fix adds the 7-specific update checks. As a result, there is also a new set of changesets for builders. Read the release notes and grab for your architecture:
Also available, as promised in the previous blog entry, is a new version of the TenFourFox QuickTime Enabler. If you are new to the QTE, please see this blog entry for basic instructions; in short, the QTE allows you to play certain media types outside of the browser in QuickTime, including H.264 video (which Firefox can't play at all) and most other audio and video files by right-clicking and selecting Open Media in QuickTime. In alpha-45, here's what's new:
  • Updated for Gecko 7 (alpha-43 will not work with 7.0)
  • Overly long URLs don't cause garbage characters in the URL dialogue anymore; they will simply be truncated (but will still play)
  • If you are not offered the QuickTime option initially, start to play the video. When the video appears and starts, right click again and see if the option is offered then. If it is, and you open the file in QuickTime, the enabler will now automatically stop the video in the browser (if possible) so that you aren't playing it in two places. This should enable JavaScript-based video code that tries to detect browser capabilities to also be playable in the Enabler.
Download QTE alpha-45 and drop it on your browser window to enable it. It does not require a restart. Remember, this add-on is still in testing and development.

"One more thing." Many of you will have read the press coverage about the "BEAST" SSL chosen plaintext attack demonstrated at ekoparty this weekend. Virtually every browser is vulnerable to this; Opera has already released a patch and Chrome has one in testing. Note that Mozilla and Chrome share SSL code (i.e., they both use NSS), so the same fix is likely to appear in Firefox, but it is not currently in 7. There is substantial argument about how easy it is to pull off in practice, but certain things can make it easier, and we might talk about this once Mozilla goes public with a final determination.

Man, it's good to be online again.

Wednesday, July 20, 2011

2 6 4 H what browser do we 'preciate

So Lion came out today and as expected it only serves to make Macs stupid. So maybe we were the smart ones for sticking with PowerPC after all. Still, Walt Mossberg likes it, in the way he likes most things Apple puts out, as I found out from watching his H.264 video at the Wall Street Journal. ... Oh, snap! Did I not tell you? Let's watch H.264 videos from TenFourFox! Not even Firefox can do this trick!

Because Flash or Safari are obviously the only ways to watch H.264 video online from a Power Mac, and we're trying to jettison Flash, an idea I'd had kicking around for awhile was to enable a QuickTime window so that you could watch the video, at least, even if it wasn't composited into the browser. While fiddling around with 6.0, I realized that Firefox's js-ctypes module could allow the browser to do this kind of manipulation in JavaScript. Better still, it could be implemented as an add-on so that people who want to play with it can. Even better still, Mozilla had a supported example of feeding images to iPhoto which I could modify to feed videos to QuickTime. It just needed to be updated to be a restartless Jetpack, which I've done too.

The trick is QuickTime Media Links (.qtl), a little-used feature of QuickTime classic -- but notably not QuickTime X -- which lets you build lightweight Internet "media shortcuts" and feed them to QuickTime Player, which then goes and fetches the video online for you. So this add-on is, in essence, quite simple: select a media element (video, audio and images are supported), determine its source and write up a temporary .qtl file, and then feed that to QuickTime Player. QuickTime handles all the streaming and playback. No mucking around with AppleScript, just "clean" CoreFoundation code. In practice it's not quite that simple, but we'll talk about the limitations in a bit after you've had a chance to play.
  1. Download the add-on. Don't install it yet. Remember, this is alpha software. It has not been well-tested on 10.5 or on a large number of sites.
  2. These make good demos: either Walt Mossberg's Lion video review, which won't play at all in TenFourFox, or this HTML5 video test, which will normally play WebM in TenFourFox (but has H.264 as an alternate). Open it up for the standard behaviour to see what it does without the add-on.
  3. Drop the add-on on the TenFourFox window. This extension is only supported for TenFourFox 6. I do not plan to support it in 5 or 4. You will be prompted to confirm its installation. It will install without a restart.
  4. Now, right-click or Ctrl-click the video. There's a new choice: Open Media in QuickTime. Click it. A dialogue will tell you the new destination (mostly for debugging purposes). Then QuickTime Player will open, and ...
  5. OMG!
The extension works for images, HTML5 audio and HTML5 video (although audio is not well tested yet). It will scan the available choices and prefer MPEG-4 (or MPEG-4 in an MOV container) since MPEG-4 can be hardware accelerated in QuickTime; otherwise it will go with what it can get. Images work too, mostly for purposes of demonstration. I'm considering making it prefer MP3 audio, but haven't decided about that yet.

Here's what doesn't work:
  • WebM video for some reason won't play, even with Perian 1.2.2 installed, and I'm not sure why (QuickTime objects to the video format). I'm not really too concerned about this since the browser can play it, but it would be nice because it would expand the number of machines that can handle WebM video. I'm wondering if its media sniffing code is failing and I have to hint it a bit more.
  • Autoplay doesn't work, even though I'm asking QuickTime to do it.
  • Not all elements are detected by Firefox's context menu code as qualifying selectors, so some video elements will not offer you the option. I may need to simply ask for 'everything' and then filter it myself rather than relying on the browser.
I don't plan to make this a part of the browser for awhile, mostly because it needs a lot more testing and because even when it will be working it's still somewhat of a hack. Still, it does work, and gives us another way to keep our Power Macs supported with modern Web video. Please give it a try and let me know your thoughts. Remember, this is very alpha and very unfinished.

I have not heard much noise from Mozilla about the next 6.0 release. I am presently in the process of moving to a new house, so I will not able to generate builds for about a two-week period starting next week as the G5 is in transit. With luck this should coincide with the 6.0RC, since there have been no major problems reported thus far. Your patience is appreciated.