Hacker News new | past | comments | ask | show | jobs | submit login

I switched to chrome before I became technically literate, because it seemed a lot faster and less prone to breaking. I couldn't describe why, but the effect was felt.

Now, I still struggle to move to firefox as I'm on a retina MBP, where firefox riles up my cpu and drains my battery.




Yup. I'm using Firefox on macOS as well and suffering from the same bug. If you use your Macbook with the resolution set to 'scaled' Firefox absolutely murders your battery. On top of that there's a bug where H264 video doesn't get properly accelerated. Both these bugs have been in Firefox at least since FF62. Both have alternatingly been marked 'priority 2' or 'fix-optional' which is absolutely baffling to me considering how crucial battery life is in today's portable world. I've even gone into the Firefox IRC multiple times where the fix has been promised to be in a 'point release' since FF63..

I get that they have limited resources but it makes getting people to switch (and stay) on Firefox increasingly hard if it cuts battery life of their laptop nearly in half.


It isn't a bug; it's the fact that Firefox uses a transparent window and doesn't yet use Core Animation, which offloads scrolling to the window server. Switching to CA involves heavy lifting inside the compositor and is not an easy task. My planeshift crate does some of the work needed to make the WebRender path use Core Animation.

In the meantime, setting gfx.compositor.glcontext.opaque to true in about:config helps battery life significantly, at the cost of rounded corners and vibrancy.


I'm curious (genuine curiosity, not meant sarcastic), why is Firefox only now switching to CoreAnimation? AFAIK CoreAnimation has been around since Leopard which makes it nearly 12 year old, which is positively ancient in the tech world.

Also, coincidentally, do you know what exactly causes the H264 problem on macOS? I've tried to track it down in bugzilla to no success, but I am 100% sure it is a bug. The energy impact for playing a H264 YouTube video in Safari has an energy impact of ~25. Firefox used to be ~60, but these days its ~180 (!)

> In the meantime, setting gfx.compositor.glcontext.opaque to true in about:config helps battery life significantly, at the cost of rounded corners and vibrancy.

Thanks for this! :)


> I'm curious (genuine curiosity, not meant sarcastic), why is Firefox only now switching to CoreAnimation? AFAIK CoreAnimation has been around since Leopard which makes it nearly 12 year old, which is positively ancient in the tech world.

I think CA was only moved to the window server relatively recently. Before then, my understanding is that it simply used OpenGL in-process, so it had no energy advantages over Firefox's built-in compositor. There was also a long time when the APIs to host CA content in the window server were private APIs and only Safari could use them.

> Also, coincidentally, do you know what exactly causes the H264 problem on macOS?

I believe, but am not sure, that H.264 is decoded in software in Firefox but is decoded in hardware in Safari.


Thanks for clearing up the CA stuff

> I believe, but am not sure, that H.264 is decoded in software in Firefox but is decoded in hardware in Safari.

I am 100% certain it is (was?) on Firefox as well, because it would have been impossible to hit the aforementioned 60 energy impact without hardware acceleration. This is done through VideoToolBox, but that might have changed.


Unless the intended behaviour is to cut battery life in half then yes it's a bug. Just because it's hard to fix doesn't mean it's not a bug.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: