Thursday, June 11, 2020

TenFourFox FPR23 for Intel available

Ken Cunningham figured out the build issues he was having with the Intel version and has updated TenFourFox for Intel systems to FPR23, now up to date with the Power Mac version. As always, there is no support for any Intel build of TenFourFox; do not report issues to Tenderapp. You can get it from SourceForge.

Ken's patches have also been incorporated into the tree along with a workaround submitted by Raphaël Guay to deal with Twitch overflowing our JIT stack. This is probably due to something we don't support causing infinite function call recursion since with the JIT disabled it correctly just runs out of stack and stops. There is no way to increase stack further since we are strictly 32-bit builds and the stack already consumes 1GB of our 2.2-ish GB available, so we need to a) figure out why the stack overflow happens without being detected and b) temporarily disable that script until we do. It's part B that is implemented as a second blacklist which is on unless disabled, since other sites may do this, until we find a better solution to part A. This will be in FPR24 along with probably some work on MP3 compliance issues since TenFourFox gets used as a simple little Internet radio a lot more than I realized, and a few other odds and ends.

In case you missed it, I am now posting content I used to post here as "And now for something completely different" over on a new separate blog christened Old Vintage Computing Research, or my Old VCR (previous posts will remain here indefinitely). Although it will necessarily have Power Mac content, it will also cover some of my other beloved older systems all in one place. Check out properly putting your old Mac to Terminal sleep (and waking it back up again), along with screenshots of the unscreenshotable, including grabs off the biggest computer Apple ever made, the Apple Network Server. REWIND a bit and PLAY.


  1. I know questions regarding Intel builds are discouraged, but am wondering if anyone knows what the OS requirements are. Given that Ken has made available single builds for FPR18 and FPR23, can I assume that they may work on systems running 10.4.11-10.8.5?

    1. I don't know the upper end, but I believe they are Tiger compatible on the low end.

    2. Thanks, Cameron. Maybe I'll do some testing of the upper limit tomorrow.

    3. Tried FPR23 on 10.6.8, working.

    4. Yup, FPR23 for Intel seems to play nice with 10.6.8, as well as 10.7.5 It failed to start the first time on 10.8.5 and 10.9.5--maybe dying during the add-on check?--but opened fine and loaded pages normally after that. Initial and subsequent starts and page loading worked fine on 10.10.5, 10.11.6 and 10.12.6. Not surprisingly, 10.13.6 reported that TFF "is not optimized for your Mac" on initial startup. Some subsequent starts of TFF failed, but if I was careful to pause a few seconds after quit before restarting, it opened normally. I noticed some cosmetic glitches (tab bar, for example), but web pages loaded ok.

  2. Cameron, can we assume that all the variables in pref.js are the same as TFF PPC? — meaning the variables themselves and/or their values.
    Just to be sure that whatever setting I see in my Intel VM reflects what is on my G4, so that I can possibly prepare a user.js in my VM and then try it on the G4.

    1. The meanings should be the same, though since I don't maintain them personally, I can't guarantee that or that they work exactly the same, either.

    2. Thanks. :-)
      Talking about prefs.js, what do you think about the "optimizations" (pipelining, etc.) that we can find around (mainly at MacRumors Forums: eyoungren (aimed specifically at TFF) and foxPEP).
      I've never been convinced but it puzzles me to read people saying they see a "huge difference"...
      If you think some of them are relevant, that might be the subject of a blog post. ;-)

    3. I try not to deal with those things specifically because there's a lot of things mixed in together and it's tough to say what they're all doing. I do periodically look at them, so without being specific to anybody's set, here are my general impressions on some of the common ones:

      - Pipelining really can make a difference, and it works with many (even most) sites, but because it still won't work with some servers it's not default in Firefox and it's not default here.
      - Disabling caching to disk eliminates some overhead and may be a good idea for systems where TenFourFox has a long runtime, but not everyone has TenFourFox running all the time.
      - Disabling WebM (VP8/VP9) will force the browser to use MPEG-4 decoding, which is faster if the site supports it, but you have to have the MP4 Enabler installed. Since this will never happen because of licensing, it will never be the default in TenFourFox.

      Here are some potentially counterproductive ones:

      - Reducing layout paint delay to zero will make the browser seem more responsive because *something* appears right away, but will make some pages longer to render because the browser has to keep going back and redoing stuff as more data comes in.
      - Increasing some memory caches, particularly for images, may have performance benefits on image-heavy sites. Unfortunately, this can also make TenFourFox potentially more unstable because we're busting at the seams with our 2GB addressing space already. If you add the MP4 Enabler, you can run out of memory in a hurry. And the browser doesn't like running out of memory.
      - People should stop messing with the JIT settings. They're probably the one part of TenFourFox that is tuned to the hilt. Messing with them might show improvements on some sites but I guarantee it will degrade others. You should only be changing them for compatibility reasons, not performance.

    4. Thanks for that precious info. Just two more questions, if you don't mind. :-)
      - about network.prefetch-next and network.dns.disablePrefetch: some say to enable prefetch, other to disable it — seems to make sense to save CPU cycles...
      - about TenFourFoxBox: is it feasible to box Youtube? Will there be some fluidity gain? (I have MP4 Enabler installed)

    5. Prefetching is sometimes difficult to predict, but since we don't pre-render, it's usually a win on most systems. On slower systems you may notice a small benefit turning it off, but on faster ones I don't think disabling it pays off.

      Yes, you can box YouTube, and like most sites because there is less browser chrome it will probably run faster with the diminished overhead.

    6. Thanks again! :-)
      On my Mini G4 1st gen, I wasn't very lucky with YouTube boxing, as it defaults to 360p while I'm limited to 144p/240p (for the record, I've also tried putting a user.js in the box profile, it works, so I can use mp4 instead).
      But in the end I have slightly better results (talking about fluidity vs resolution) and less manipulations with my TFF setup + uBlock to filter out useless stuff (right column and comments).


Due to an increased frequency of spam, comments are now subject to moderation.