Mozilla's Next Big 'Quantum' Enhancement Will Make Firefox Silky-Smooth

[nikolajj]

It might also be worth noting, that no matter what renders det webpage, the GPU still draws 60 frames a second on a 60 hz monitor anyway. To the GPU, this might not really make much of a difference.

 

[samer.forums]

It might also be worth noting, that no matter what renders det webpage, the GPU still draws 60 frames a second on a 60 hz monitor anyway. To the GPU, this might not really make much of a difference.

It does make a difference . when the GPU changes the pixel values in the table, it draws more power for this process , unlike when the card simply draws the same pixels from unchanged table stored in memory at 60 hz.

 

[nikolajj]

It might also be worth noting, that no matter what renders det webpage, the GPU still draws 60 frames a second on a 60 hz monitor anyway. To the GPU, this might not really make much of a difference.

It does make a difference . when the GPU changes the pixel values in the table, it draws more power for this process , unlike when the card simply draws the same pixels from unchanged table stored in memory at 60 hz.

Well, that confirms that a static page draws no extra power at 60 FPS.
And what you describe happens in any case already, no matter the sofware (browser or not).

So unless you for SOME reason run your monitor at less that 60 hz (why would you?), not much will change except smoothness.

 

[nikolajj]

https://www.cnet.com/news/firefox-quantum-mozilla-faster-web-gecko-engine/
(Skip to end if lazy.)

http://gigazine.net/gsc_news/en/20170927-firefox-quantum-browser-beta/

 

[bit_user]

1) It might only render 60FPS when something is happening. This is quite achievable.
2) It is not done yet. So testing now might not have much relevance in the end.

You're contradicting what they've publicly stated about how it's designed to work.

...based on what? Some personal belief that Mozilla can do no wrong?

 

[bit_user]

It might also be worth noting, that no matter what renders det webpage, the GPU still draws 60 frames a second on a 60 hz monitor anyway. To the GPU, this might not really make much of a difference.

No, you clearly don't understand how GPUs work.

Refreshing the video display simply reads the contents of a frame buffer and sends it to the monitor. Rendering is the process of drawing into that frame buffer.

Rendering consumes more power than display refresh. In the best case (i.e. where the screen is just a solid color), it's about the same. So, that means if you're redrawing even the simplest content, you should get at least a doubling of the incremental power used for display refresh.

 

[bit_user]

https://www.cnet.com/news/firefox-quantum-mozilla-faster-web-gecko-engine/
(Skip to end if lazy.)

http://gigazine.net/gsc_news/en/20170927-firefox-quantum-browser-beta/

The first article is 1 year old. They hadn't implemented it yet. The news in this article we're commenting on is much more up to date.

And I don't even know what you want us to see in the second one.

 

[nikolajj]

1) It might only render 60FPS when something is happening. This is quite achievable.
2) It is not done yet. So testing now might not have much relevance in the end.

You're contradicting what they've publicly stated about how it's designed to work.

...based on what? Some personal belief that Mozilla can do no wrong?

Source? I Can't find any proof of increased power consumption. And if there is any, it is still on a incomplete product. Games in beta runs like shit too.
The word 'might' means that it is not certain, just a posibility. All that I have agued for is that we don't know yet.
I have already stated that if power consumption ends up being a problem, I will only use this on my desktop where I don't care.

It might also be worth noting, that no matter what renders det webpage, the GPU still draws 60 frames a second on a 60 hz monitor anyway. To the GPU, this might not really make much of a difference.

No, you clearly don't understand how GPUs work.

Refreshing the video display simply reads the contents of a frame buffer and sends it to the monitor. Rendering is the process of drawing into that frame buffer.

Rendering consumes more power than display refresh. In the best case (i.e. where the screen is just a solid color), it's about the same. So, that means if you're redrawing even the simplest content, you should get at least a doubling of the incremental power used for display refresh.

Everything you say is true. But you fail to see the whole picture.
Yes, the GPU will have to do more work, obviously. But the CPU will have to do less. The task is being moved from one place to another. The new place is specialized at this kind of task. If (and ofc only if) the new place is double as efficient as the old place, you can double the framerate and end op with unchanged power consumption. If the new place is more than double af efficient, then yay, power savings.

And I feel that I have to repeat myself: Maybe power consumption will increase and maybe it will not, I don't know. And what I am trying to say is, the you don't know for sure either.

https://www.cnet.com/news/firefox-quantum-mozilla-faster-web-gecko-engine/
(Skip to end if lazy.)

http://gigazine.net/gsc_news/en/20170927-firefox-quantum-browser-beta/

The first article is 1 year old. They hadn't implemented it yet. The news in this article we're commenting on is much more up to date.

And I don't even know what you want us to see in the second one.

One year old or not, it is part of the goal and the team working on it think that they can. If they are right or not, we will know when it is done and refined.
The news in this article we're commenting on is not addressing power consumption.
The second one... memory uses power. No biggie on the desktop, but on a phone it is relevant.

 

[bit_user]

1) It might only render 60FPS when something is happening. This is quite achievable.
2) It is not done yet. So testing now might not have much relevance in the end.

You're contradicting what they've publicly stated about how it's designed to work.

...based on what? Some personal belief that Mozilla can do no wrong?

Source? I Can't find any proof of increased power consumption.

It's axiomatic. GPUs are typically 10x to 100x as efficient as CPUs. If they're literally redrawing the entire window at 60 Hz - even when nothing's changing - then you're probably talking about at least 1000x as many draw operations. That yields a net loss in energy efficiency. And it's not like the CPU is going to be completely idle - it has to orchestrate each of those redraws.

My original comment couldn't have been clearer. It was a direct reaction to the statement I quoted from the article. It wasn't an attack on Mozilla writ large. If it's implemented exactly like that, my speculation is that it's going to use more power. I base this on a fair amount of experience with graphics & GPU programming.

Now, because I'm a bit of a graphics geek, I'm actually intrigued to see it in action. Plus, Firefox being my main browser, it's not like I harbor any antipathy towards them. I even wanted to buy a Firefox Phone, before they killed it. So, as I read the article, I was immediately struck with a mixture of fascination and trepidation.

But, the thing is, you voted down the one person here who said he actually tried it. Why? Is it because he contradicted what you wanted to believe about it and about Mozilla/Firefox?

And I feel that I have to repeat myself: Maybe power consumption will increase and maybe it will not, I don't know. And what I am trying to say is, the you don't know for sure either.

What I don't know is if they'll end up going with the approach described in the article. What I do know is if they do exactly that, then it's bad news for battery life and power bills.

If they end up doing loads of clever optimizations and caching of partial composites and renders, then it might even be a net win. It didn't sound like the direction they're headed, but I actually think that's where they're most likely to end up, sooner or later. Even then, maybe they'll still have to climb down from 60 Hz, when on battery.

 

[nikolajj]

But, the thing is, you voted down the one person here who said he actually tried it. Why?

Because it assumes something about the end products performance based on unfinished software. You just cannot do that. The downvote helps informs other to not take it as fact.
That is really my only point in all this. We can't know for sure about battery before it is done. So all in all, we might really just basically agree.

 

[bit_user]

But, the thing is, you voted down the one person here who said he actually tried it. Why?

Because it assumes something about the end products performance based on unfinished software. You just cannot do that.

Depends on what you read into it. If you take it as proof that the end result will have power problems, then that's going too far. But it confirms that the end result might have power problems. On the other hand, if someone tried a prototype and found their battery life went up, well you can pretty safely assume the final release will perform at least that well.

So, the way I see it is that it validates the concern. And for that, it's a worthwhile contribution and think the down-vote was unjustified. But it's not like there's a strict policy for voting, AFAIK.

 

[nikolajj]

But, the thing is, you voted down the one person here who said he actually tried it. Why?

Because it assumes something about the end products performance based on unfinished software. You just cannot do that.

Depends on what you read into it. If you take it as proof that the end result will have power problems, then that's going too far. But it confirms that the end result might have power problems. On the other hand, if someone tried a prototype and found their battery life went up, well you can pretty safely assume the final release will perform at least that well.

So, the way I see it is that it validates the concern. And for that, it's a worthwhile contribution and think the down-vote was unjustified. But it's not like there's a strict policy for voting, AFAIK.

Are we talking about the same post? "Yes this will be bad for battery life" is not a "Could be", it is a "This is how it is!". Having tried the current software does not make this sure fact.
If not to use the downvote system to help people avoid false information, what then? (and upvote for relevant information ofc.)