> macOS users on dual-graphics-card machines (like MacBook Pro) will switch back to the low-power GPU more aggressively, saving battery life.
macOS user base can now consider FF as a viable browser alternative.
back
8 comments
There are more macOS battery life improvements coming in Firefox 70 in around six weeks: https://news.ycombinator.com/item?id=20864255
For some measurements: https://bugzilla.mozilla.org/show_bug.cgi?id=1429522#c45
I just got 70b3 via the beta channel and the difference is notable when using gmail and google drive. They load faster and there's a bit less latency when you click something in the UI. I can't tell you if this completely closes the gap as I don't really use other browsers. But it definitely improved a bit.
Two big changes related to performance: - the baseline javascript interpreter is now enabled (this is probably responsible for improving things for Google related stuff). - they optimized a few things with the compositor for mac to further reduce battery usage. I'm guessing this might include some of the work that has been done to port parts of the browser to rust.
Upcoming versions should at some point include the webrender changes that are currently available to some windows users already.
If you are wondering, the beta channel is generally rock solid for me. You end up restarting the browser a bit more often to get the latest beta and obviously they are still finding and fixing bugs. But I can't remember the last time Firefox crashed on me. I've been on the beta channel for close to two years. By the time features land to the beta channel, they've been on nightly for some time already. So, that generally means all the obvious stuff has been resolved already.
For me, not viable on macOS until they implement pinch to zoom.
https://bugzilla.mozilla.org/show_bug.cgi?id=688990
Edit: https://addons.mozilla.org/en-GB/firefox/addon/multi-touch-z... seems to help, though still not perfect.
Please be the case - this is reason #1 why I haven't switched.
I've been using nightly and developer edition. It's greatly improved. I still don't think it's as good as Safari, but it's at least as good as Chrome. I've gotten nearly 3 hours of battery life back from these improvements.
You could try Firefox Nightly to see it for yourself ;)
You don't need nightly. This is released already.
Nightly is supposed to be even better, and with further improvements in the pipeline: https://news.ycombinator.com/item?id=20857892
A significant number of changes are still pending the release of version 70.
My MBP doesn’t have a dedicated card and yet firefox manages to eat my battery as a snack
For me (MBP from early 2015 w/o dedicated card) the upcoming FF 70 made a huge difference. I installed the beta today and I finally can go to youtube, facebook and reddit (the new design!) without the fan spinning up.
Sounds like I'll give FF another try on the Mac. I do love it on Windows
I wonder if this will help address the system freezes I've been getting for the past month on my early 2011 MacBook Pro. The fix I was going to pursue makes an attempt to disable usage of the "bad" GPU:
https://forums.macrumors.com/threads/2011-%E2%80%A2-15-17-in...
Most of my lock-ups seem to happen when I try to access specific sites using Firefox, especially financial sites.
On my 2018 Air, firefox runs a lot better if I put it into low res mode (macOS setting, not ffx setting). Downside is text looks pretty bad but somehow images/videos are fine and content is the same right so whatever.
This was the single thing I was hoping to see here. Upgrading now.
Firefox 70 will be the first version where enough of the changes that they have been working towards will land to yield really substantial power savings, with more changes yet to land beyond that.
The next version will drop OpenGL and use Core Animation instead.
I know a lot of people have become impatient, but they have been doing a huge amount of work behind the scenes.
Technically it'll still be using OpenGL, it'll just have system compositor integration via CoreAnimation for scrolling, and possibly some elements in the page like video.
Does anyone know the technical reason that the OS can't handle that itself?
Not using OSX, but I have some ideas.
An app tells an OS it gonna use OpenGL to 3D render stuff. Generally, the OS doesn’t know whether it’s a competitive 3D shooter where each FPS really matters, or a web browser which only uses OpenGL to render a few textured quads. If the OS will default to slower integrated GPU, users will be unhappy, they want 3D performance. So the OSes typically power up the faster GPU in such cases.
On dual-GPU Windows laptop, nVidia partially solves this in their drivers, they have very long list of process names saying which ones are games or other 3D intense apps.
It usually works but very far from being 100% reliable. It requires GPU drivers to be updated regularly. For cases when it fails even with latest drivers, they have multiple methods for user to select the GPU. They implemented context menu on .exe files “Run with graphic processor” with 2 further options, for nVidia and Intel GPUs. They implemented GUI for users to customize that apps list. They also implemented a proprietary API for programmers to customize that list in code, I’m using this method in the installer of a CAD/CAM app I’ve developed.
These things cause quite a lot of complexity, both software bloat, and UI clutter. Traditionally, Apple wants the GUI to be clean. AFAIK they don’t push driver updates, and they avoid UI clutter even if it means some power users won’t get some advanced settings they might like.
I guess I was thinking of this from a heterogeneous architecture standpoint (e.g. big.LITTLE) . You have differently-capable compute resources, and you need to pick the one thats best suited for the work-load. Rather than the app talking directly to the hardware, I suppose the OS should let the app pick its work-load type, similar to letting it choose a process scheduling priority.
Unlike ARM cores, GPU code is expensive to migrate between them. Two GPUs have different ISA, each GPU driver compiles platform-independent bytecode like DXBC or SPIR-V into proprietary instruction set. VRAM can contain many GB of data, when migrating, everything needs to be copied. The asymmetric ARM cores at least have same RAM, and very similar instruction set.
These issues make live migration impractical. AFAIK, modern OSes don’t do that, the GPU is fixed at the moment an app creates D3D or GL context.
Picking the best GPU for the job can be tricky. By the time the app creates a 3D rendering context, the OS has no idea what it’s going to render.
Write a code that renders something simple, then downloads the frame buffer from GPU back to system RAM — Intel will probably be faster, for nVidia that copy back is expensive because PCIx, for Intel very cheap, no PCIx IO, just memcpy.
Even exposing an OS API where apps can request high or lower power GPUs is still unreliable. An app which does very simple rendering can sometimes demand way more resources, connect a 5k monitor and simple rendering can become too expensive for intel due to count of pixels. A game which reports it needs a lot of GPU power will be very light workload in 10 years from release, perfectly suitable for low-power integrated GPUs.
When switching from onboard -> dedicated, the resources (textures, shaders, etc) to migrate will be quite small. There is no question of migrating resources from dedicated -> onboard as that is never going to happen, unless .. again the resources are tiny. The context switch performance hit will depend on the other components on the board, but for a high end CPU/RAM/SSD combo, it wont be much. It will be equal to re-loading the all the browser tabs (for e.g. after a browser crashes).
>they have very long list of process names saying which ones are games or other 3D intense apps.
Is it possible to submit application names for this? This issue frequently comes up with our free simulator/game.
I have no idea whether nVidia willing to change that list for small software publishers. Technically, I know 2 workarounds.
1. If your app’s main .exe is written in C, C++ or something similar, you can change the default by DLL exporting a DWORD variable from your exe. For more info, search the web for `NvOptimusEnablement`.
2. If you can’t export variables from your .exe, you can do what I did: make an installer, write a custom installer action in C (technically they’re just DLLs), in that custom action consume NVApi and create a new profile for the main executable of your software. For more info, read this: https://stackoverflow.com/a/40915100
Update: you can also detect dual-GPU system and use NVApi from your app, but it has 2 disadvantages. Slightly increases startup time. Also the new settings will only be applied next time user launches the app, you’ll need to communicate it that with your user, with a message like “please restart the game for better 3D performance”.
It tries based on the libraries you’re using. Sounds like they’ve improved what they’re using so the built in heuristics don’t force the dedicated GPU on.