Chrome became so bloated and crap and slow that in 2020 I moved over to Firefox (which has been imperfect, but better), so my anecdata suggests that browsers don't actually get faster overall, but ebb and flow as feature creep and optimization compete for dominance.
To me it feels like bloated browser profiles makes the browsers sluggish.
I get annoyed with how slow Chrome is, so I switch Firefox. After a while the Firefox profile gets bloated and I get annoyed and switch back to Chrome with a clean profile and it feels really quick again. Ad infinitum.
On Firefox, if you have an unbelievably large number of entries in your History, Bookmarks, and/or Downloads (your Firefox "Library" — chrome://browser/content/places/places.xhtml), you could theoretically become limited by insert/update performance in Firefox's embedded sqlite, I believe.
Some 10x rockstar developer with a wrinklebrain considered it low IQ rambling and got offended but got quickly btfo by fellow smoothbrain hackernews readers who share my sentiments.
Popular apps will be as slow as user can tolerate. Because if they're not slow enough, it invites developers to introduce another abstraction layer.
Good thing is, that it's possible to create truly groundbreaking apps using non-conventional techniques, as web becomes faster and richer with new APIs.
For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll be awesome.
I have one example to prove my words. I used iPhone 4S. With iOS 6 I was able to use navigator software which worked very snappy and awesome. Few years later with iOS 9, navigator was very slow, forcing me to buy new phone eventually. With iPhone 8 it returned to blazing fast. But it did not have any new functions. They just started to consume more memory, just because they can. My UX did not change a little bit. I just had to buy new phone with infinitely faster CPU and loads of RAM, just to keep my UX from degrading.
> For example with Wasm and WebGPU it's possible to create AAA games running in the browser.
This has been promised since at least the WebGL and asm.js days. It still won't happen, but not mainly for technical reasons, but for business reasons.
...but of course also some technical reasons. Asm.js/WASM and WebGL/WebGPU are fine, but most other web APIs are a mess and the web is a highly unstable platform, APIs are deactivated or deprecated on a whim, APIs change behaviour unpredictably, behaviour differs between browsers, etc etc...
TL;DR: the web needs a proper "DirectX initiative" like what Microsoft did in the late 90's to get Windows gaming off the ground.
I agree, but tell that to the "money people" in big game studios ;) The web simply isn't on their radar, even mobile isn't for the most part. They want strong centralized platforms like Steam, EGS, Xbox, Playstation or Nintendo and a platform owner to negotiate with.
This can change very quickly if there's actually some breakthrough web game, but that hasn't happened so far, and nobody wants to be the first to take the risk.
Both Unreal Engine and Unity already have Google Stadia for a compile target ( Debian/vulkan )and it runs in the browser.
As consoles have become more and more generic and all carry a browser, less money is being invested in platform specific engines because there is less relative performance increase & return on investment compared to the past. ( Games sold the platform, not the other way round )
Risks have been taken by big players and everything is becoming more and more platform agnostic therefore we could reasonable expect "breakthrough" when they are done milking the cow previously invested in and see them expand to a bigger market.
That's not correct though, the game runs on a Linux box in Google's datacenters (granted, from a business perspective that's nitpicking - but not quite, see below, but it's a massive difference from a technical perspective).
Scaling to large audiences is much more expensive with the game streaming approach though (but we'll never really know because Stadia bombed, just as all other game streaming platforms before).
It's not just a remote control video feed ( Unlike other game streaming platforms ) so there is tons of incentives and capability for them to offload as much as possible onto the client.
> the web needs a proper "DirectX initiative" like what Microsoft did in the late 90's to get Windows gaming off the ground
Why? We can already play AAA games on our computers. It works very well, much better than anything web-based. Why would anyone put effort into replicating the same thing inside the browser?
Mostly independence from the whims of platform owners who control the distribution, a space to try out quirky new ideas, and less hassle both for devs and users (no lengthy download or installation process for instance).
This is much more important for indie devs than AAA devs though (the current problems of the web platforms are not really 'AAA specific').
Also, don't forget that PC gaming could very well have died out during the transition from DOS to Windows without Microsoft actively supporting game development on Windows (with the DirectX APIs), without this, AAA gaming could very well be console-exclusive now.
> Why do you think AAA games will not need downloading assets and logic?
As internet connections get faster it makes sense to stream/prefetch data directly from CDNs as needed instead of downloading everything upfront.
> Look at steam's catalog. Plenty of whacky quirky stuff is available.
Agreed, but that's the exception, not the rule. Look at Apple's app store ecosystem for a counter example where apps and developers are banned on Apple's whim. This couldn't happen on the web.
Well that's what Google already does anyway with web APIs, except that their APIs are usually a broken mess (see WebAudio).
But apart from that, Microsoft was in a unique position to dictate standards to GPU vendors, as draconian as it sounds, this worked much better than Khronos' design-by-committee approach in OpenGL.
I've always wondered why nobody built Kongregate 2.0 using modern web technologies. The indie game dev scene seems to be thriving, and you can play tons of games for free on itch.io While some of them have a webplayer, it's disorganized, and the user experience is usually terrible.
In its last few years Kongregate was largely JS games.
That didn't help the large move to mobile gaming by its primary audience (which I'm guessing was teens).
Towards the end Kongregate became a platform for idle games that pushed users hard towards pay to win. Sucks, but they grew huge off the glory days of ad revenue and I presume they had to do something to keep surviving.
None of what's outlined on that blog has anything to do with Rust. And wgpu has to validate code for undefined behavior because it needs to run in browsers, as well as translate it to other backends that aren't SPIRV--it again doesn't really have anything to do with Rust. In fact according to the Rust memory model, most UB on the GPU would technically be okay (though obviously not ideal) but not in the context of a browser. So just saying "eh that stuff is undefined" or "this is just Rust stuff" doesn't really address the issues outlined there.
Admittedly I don't know kvark, but some of his statement there were wrong, in a way that gives impression he didn't do much 3D programming before hand. That's why I imagine he worked on the If one were to go through a point by point rebuttal, it'd go like this:
- Not knowing you need to have entry point for the shader to be executed.
- kvark's complaint about OpFmod being misnamed are kinda missing the point, % isn't the mod operator but remainder operator (in C/C++)
kvark is a GPU expert who's worked on GPU programming, 3D games, and GPU standards for years now. And he's not the only one working on naga, either.
I'm also really not sure how you got the first point from what he wrote. He was not saying he was surprised to find "you need to have an entry point" he was saying the restriction made no sense, and that existing tools didn't even take advantage of having more than one entry point due to driver bugs.
The rest of your points are basically just opinions masquerading as something else. In any case I don't actually care how hard WGSL is to write, because I don't have to write it (you can go through a translation layer). What I'm not going to do is pretend that SPIR-V is a great choice for this intermediate layer solely on the basis of what I've heard from other graphics people who haven't actually tried to use it for that purpose--which is exactly what the article is about.
Kvark's good, but he's still fallible. And I don't know what games he made, but I can tell you, others that had experience with shipping games/software, laughed his articles out loud.
> he was saying the restriction made no sense
So presented with reality of a complex, buggy drivers, his solution is - to ignore it? Wow imagine in UTF-8 people just said, yeah 8bit 0 are ok everywhere and caused hundred of billions of lines of code to be written to deal with null mid UTF8 stream.
> I don't actually care how hard WGSL is to write
Awfully dismissive. Well, ok, you won't have to write it but someone will. And those someone are going to curse whoever wrote that abomination of a spec.
A spec that:
- That doesn't respect backwards compatibility
- Looks like pure torture to write in
- Misunderstands some part like OpRem
I'm not very confident in it to be honest. Looks to me just another overly elaborate moat for browser implementors.
Ugh, please not this again. Considering the alternatives, WGSL is fine. It could have been much worse (e.g. Apple jumping ship and doing their own thing just because they have a problem with Khronos), and not requiring web apps like shadertoy to download and run a shader compiler WASM blob is also a good thing. WebGPU also needs to cover other scenarios than games.
>For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll be awesome.
You get a shitty distribution model (relying on browser for cache or limited localstorage, or whatever you want it's shitty in the browser and inconsistent, browsers aren't built to handle GB sized assets).
You pay the sandbox tax even in the ideal scenario and there are plenty pathological ones. And even if you aren't performance constrained you're adding battery drain for no benefit.
Then there's the shitty input model and interaction with browser chrome.
And what are the benefits exactly ? Avoiding app stores ? Might benefit the developer but not really a benefit for the consumer.
>And what are the benefits exactly ? Avoiding app stores ? Might benefit the developer but not really a benefit for the consumer.
well, if a company can avoid paying a significant portion of revenue to an app store they might be able to hire better or more developers which might conceivably be a benefit for the consumer.
no, it suggests that just as the amount of developers past a certain point on a project is a drag on that project the amount of developers of a product past a certain point does not significantly increase the quality of that product.
If indeed the amount of developers employed was inversely correlated with software quality then the best software is that which does not exist. I realize there is a pithy saying that the best code is no code at all but I am not especially fond of such illogical pithiness.
There may be products that it is best they not exist at all, but for products we do want to exist it follows that some number of developers of that product correlates with the quality of its existence.
I was thinking in terms of Amdahls and Brooks law. Of course zero is an edge case, but in my experience the best designs in terms of quality (not number of features) come from individual work. You can not scale this part out.
Slightly off topic but I wonder if WASM and the web can provide a “fixed” virtual platform for games.
A lot of games are heavily platform dependent, when the hardware for those platforms die the games will be nigh unplayable without a huge remastering effort or building an emulator of said platform which may or may not be technically feasible - even on PC we have games breaking as hardware advanced, e.g. Deus Ex had to be patched to work with multi core CPUs if I remembered right.
You don't need such assets to make good games anyway. The obsessions with AAA are unhealthy - many of the best games are not AAA at all, but strictly indie.
This reminds me of Parkinson's law (https://en.wikipedia.org/wiki/Parkinson's_law). Paraphrased: "complexity expands so as to fill the time available for its consumption". The faster a software can be, the more things it seems to do just for achieving the same features.
It's also probably another view of the Jevons Paradox: as efficiency of software increases, it gives more way for more complexity and "optimizations" that in the end make the end result as slow as before.
> Paraphrased: "complexity expands so as to fill the time available for its consumption"
That's a very liberal paraphrasing. Parkinson's law is specifically about the amount of time that it takes to complete work (by humans, e.g. for a project deadline).
If you want to reference something that serves as good commentary about software performance, Wirth's law is right there for the using.
Quake Live didn't run in the browser. It used the browser as a UI for configuration and connecting to the servers but the game itself ran as a native plugin.
Not just the internet: case in point, the new Xcode 13 has some really embarassing performance problems on my mid-2014 13"MBP. I guess the Xcode team switched to shiny new M1 Macs between Xcode 12 and 13.
The thing is, this is in areas that worked fine for over
a decade. Somebody must have decided that Xcode's text input code (that's one of the things that got slower) needs to be rewritten for no obvious reasons, but then didn't optimize it as much as the old code.
What's the point of new hardware if the new software that's written for it makes it just as slow (or in this case: much slower) than the old hardware?
not OP, but for the lifetime of the hardware ? or, at least, should be specified in T&C when buying the hardware
I am still pissed off that my 2012 Macbook Air is no longer receiving OS updates - compare that to Microsoft that allows me to run windows on basically any PC
The “lifetime of the hardware” is defined by the lifetime of the supporting software, which ultimately boils down to the popularity of the platform you’re on
8-10 years is what the Consumer Rights watchdog expects for devices in the price range of a MacBook in my nation to continue to provide hardware support, so I would say that seems like a reasonable amount of time for there to continue to be software support.
MacBooks aren't cheap. For the average person they are a significant expense. So the lifetime of support should reflect that.
It's good I need to use the apple laptop & Xcode only just to build my flutter app, otherwise I would have given up just how slow it is, every click takes ~5 seconds.
Back in 1980s and 90s I had MS Quick C 1.0 and Borland Turbo Pascal 3.0-5.5. On my 386 system back in early 90s, these used to be super fast with most of the small hobby programs I wrote then. Type program name on MS dos command prompt, press enter and you can start coding or editing your file in WP or 123 in the blink of an eye. Press key combo to run program in debug mode and it would be ready in less than 1 second.
That system did run Windows 3.0, and later on 3.1 & Windows 95, but for a lot of tasks I would just use MSDOS and be done with that. Even running character mode Linux with pre 1.0 kernel in multiuser mode was fairly snappy in those days.
The first generation unibody macbook pros running OSX felt fairly fast and snappy back in the day, but even that was no match to the peak MSDOS speed. And I suppose that snappiness was felt mostly because Windows XP while fast, was not the snappiest OS out there.
In 2021 with every component seemingly 100x faster than those systems, with a 8 core i9 CPU on my MBP 16, I dont see any environment being that fast. I really miss peak MSDOS experience from the days of Windows 3.0 era.
Sometimes I wonder how much of this feeling comes from expecting more from more power/thermal/area constrained devices. My experience working with top-shelf workstation-grade CPUs in mid-tower cases with excellent cooling is far separated from my experience even with M1 Macs. Having 16 cores, 64GB+ RAM, and 300W of thermal capacity is a big improvement.
Compare Zen 3 to M1... M1 is a generation ahead in lithography and enjoys an appreciable thermal/efficiency advantage resultingly. Zen 3 and M1 have neck-and-neck single core performance on many tasks. Yet Zen 3 can offer many more cores and make up for its efficiency in raw thermal envelope availability.
Then also the expectation from older and more inexpensive devices. If one gets used to M1-level performance, a $200 CPU from 4 years ago starts to look quite slow; e.g., the Ryzen 5 1600:
Once we start to look at the truly power constrained, say a mainstream phone from a few years ago; let's say the iPhone 8/X since it's one of the best selling in recent history. Then you're at about 50% of the single threaded performance AND working with fewer cores.
There is another large factor at play in the past 20 years in particular though: that is the increasing predominance of "Python-like" languages. I mean that in the sense that more of the code we interact with on a daily basis is written at a very high level than 20 years ago. Python in particular is just about the least efficient of all the most widely deployed languages.
Https multiplied latency by three when opening websites compared to 10/15years ago where many websites were http.
And also many websites include more tracking, for example Google search results used to directly send you to the result page. Now they first send you to Google so that they know you clicked but it also adds noticeable latency.
With the advent of CDNs, edge routing and global hosting, things have actually gotten way better for those of us who use US based websites from the other side of the world. I am from India and back in 1990s the latency used to be huge because we had internet via satellite. Then we got internet via submarine cables but even with that latency is > 300ms for a server based in the US.
Now in 2021, most popular websites use CDNs and have servers based out datacentres closer to India and the page load speed and latency has gone down significantly for us.
But page bloat is a different matter, I still remember spending the greater part of a day (or maybe more0 downloading the MSIE 2.0 installer on a 1200bps dial up modem. Today page sizes > 1mb are common even on mobile sites.
I'm pretty sure Google currently uses an async ping https://www.w3schools.com/tags/att_a_ping.asp) instead of a redirect to log what's been clicked. It's been a very long time (if ever?) since they didn't have result click logging at all.
Indeed, I didn't know about the ping attribute. However, you will see they still do click tracking on the google image results for example.
And if you check this article from 2013, you will see that they had it back then (I'm not sure when they removed it): https://chainsawonatireswing.com/2013/03/20/how-to-disable-g...
What the browser giveth, the web developer taketh away.
I tremendously hate it and it’s not like developers are incapable of building performant software, quite the opposite. But that’s just not where the resources go. The common sentiment (I have heard this directly uttered) is “If the user has 8GB of RAM, why wouldn’t I use it?”.
1) Chrome in Android has recently begun to hang when trying to go back to a previous page. It's gotten so bad that I end up clicking multiple times, which all register in rapid succession. If I click more times than the history depth for the tab (say 3 or 4), I end up back on the home screen and a lost tab with lost (or at least not conveniently recoverable) history.
2) AMP. When Google began pushing AMP my objections were mostly based on principle; performance was mostly a wash for me. Now the AMP viewer is so slow and so crash prone that I'm conflicted. On the one hand, I'm glad to see that AMP is clearly failing. On the other hand, Android and Chrome still strongly favor AMP, and I'm too lazy to wrestle with Google over default settings, so when I don't have the presence of mind to explicitly open a web site (e.g. when using Google News) I'm left to suffer the poor performance and bugginess in addition to other intentional AMP headaches--lack of copy+paste, less scrolling and zooming control, etc.
Not quite the same thing, but related, technologies like QUIC are really only beneficial in the context of a web ecosystem built by Google. QUIC shines on websites pulling in many resources from disparate hosts, which in most cases is a situation created by advertising and analytics services. IOW, these days much of the benefits of Google's work simply pays down the debts Google itself created or advocated. And while Google still stands out for the amount of labor it invests in open source security and performance, it's just a matter of time before we pass break even into negative return territory. That happened long ago with Google Search itself; Google Search results are as slow, irrelevant, and obscured by obnoxious and misleading advertising as the competitors it originally, rapidly displaced. Heck, when Google began those investments (Android, Chrome, OS security, etc) they were crystal clear why they were making them--to nurture and grow an ecosystem into which they could grow their advertising business, same as their rationale for making a snappy search service and a non-intrusive advertising network. There's a limit to how well they can improve that ecosystem, but the limit for exploiting that ecosystem can easily result into a situation far worse than the one Google originally saved us all from.
Consider why rendering work is even relevant in 2021. It's not for the benefit of services like Netflix or YouTube, which already enjoy low-power hardware acceleration, and arguably not for games or similar interactive content. It's so they can continue shifting their advertising ecosystem from minimalistic text-focused display boxes to animations and videos peppered up, down, over, and under content views. They can't do that if advertising-laden web pages drain your battery in 15 minutes, as notorious Flash-based ads once did. Steve Jobs' famously removed Flash from mobile; Google, for obvious reasons, is taking the alternative path.
I really don’t think this is such a bad thing. It makes it much easier to develop software and has helped result in the explosion of awesome digital products that we see today.
I do have my fingers crossed that Rust+WASM+WGPU will bring about some more efficient products, though.
But I don’t think non-technical users value memory efficiency as much as we like to think sometimes.
It's not just memory efficiency - webtech applications are significantly more CPU-hungry than desktop applications.
> It makes it much easier to develop software
I've never seen compelling evidence that this is the case. Every time this argument is made, it seems to be by a webdev who has no significant experience with building desktop applications. Sure, if you already know webdev, it's easy to build things with webtech. This isn't particularly interesting. I'm much more productive building desktop applications than webapps, but that's because I've spent almost all of my time building desktop applications.
The real question is, given an average developer who has spent around the same amount of time on learning web development and desktop development, and both at a minimum amount of time (say, 100 hours) - which is more productive, and by how much?
I think that is the wrong question to ask. Web apps are more productive, almost by default, because you don’t need to rewrite the application for each distribution target.
I can build a web application and deploy it on the web, on Windows, on Mac OSX, on iOS, on Android, on Linux, immediately. With minimal extra effort, assuming I know what I’m doing.
Correct me if I’m wrong (it’s possible), but I don’t think that’s at all possible with native libraries, or even cross-platform frameworks like Qt.
It also means companies don’t have to hire multiple product teams. They can hire one team.
So even if native development is 10-20% more productive (I’d disagree, but for arguments sake), it’d still fall short.
Webtech might score low on the CPU efficiency scale, but it scores very high when it comes product timelines, headcount, payroll and (arguably) ease-of-hiring.
This is why I think webtech almost always makes more business sense. At least for your typical SaaS product.
This is why I’m excited for WASM. We might finally have the tooling for truly cross-platform development without sacrificing efficiency/low level control.
IMO the frontend JavaScript ecosystem is a complete mess. Nobody cares about maintaining things properly or backwards compatibility. I mostly do backend, but occasionally do frontend work, and whenever I do I feel like bashing my head against a wall.
Case in point: Early last year I created a proof of concept web app that needs to run in the browser and a webview on an old version of Android. I used create-react-app which at the time was the most popular way to... create React apps. This year I updated all the deps and something in the build broke meaning it no longer produces something runnable on the old version of Android we need. There's been an open issue on create-react-app for nearly a year, however it seems Facebook have abadoned that project and everyone has switched to Vite/Rollup now. I spend half a day switching to that which mostly works, except as it doesn't actually bundle, the dev build no longer works on the Android webview - but that's not such a deal breaker. However in the production build treeshaking seems to be completely broken, so the resulting build is a few mb instead of a few hundred kb.
So you took something you don't understand, pushed it up, then complain when it doesn't update correctly and something goes wrong.
Do you not see that you are the problem in this scenario? Facebook has not abandoned the project and very very few people have switched to Vite/Rollup. You're doing hype driven development.
Now I get this is how a lot of these front end tech are portrayed, and that a lot of these projects could be better in terms of defaults, but what has to be accomplished in front end tech is very difficult. It has to run across so many different browsers, on different operating systems, with different engines across who knows how many devices.
Part of the reason front end development is a mess is because people like you come in, think you don't have to spend any time learning it, and can just put something up because "it's just javascript, it's a toy language". Learn the platform and develop for it. You reached for the biggest hammer you could find when you probably could have used something much smaller and easier to use. You chose the wrong tool, and it's probably because you didn't bother putting in the time to actually figure out what you know and how it would be maintained.
I agree that my original complaint was a bit of an overreaction, but I still think my complaint about maintenance and backwards compatability is true. I've been doing frontend development for over 15 years, and SPAs for at least 10 (I started with Backbone.js), so saying 'people like me come in' is not accurate or very fair. Nowadays I mostly do backend Typescript, mainly so I can avoid issues like this.
The reason why I choose create-react-app when I first started this project was because it was most popular and recommended way to create a React app. I've hand rolled Webpack and Babel configurations before, and upgrading to the next major version is alwyays a headache, which I wanted to avoid again. Sticking to old versions is equally bad because if someone wants to try something new it's not always possible (two of the biggest frontend apps our company has are stuck on React 15). I figured it's an official project from Facebook, so will be around for a long time and well maintained, but obviously that assumption was wrong for my use case.
The upgrade instructions don't say much [0], but in my case it was a dependency of a dependency of create-react-app which was causing issues. Because of the way create-react-app is built, it isn't usually possible to downgrade or upgrade specific dependencies, or change the configuration for certain parts of it. You just have to go with what they suggest and hope that works for you - which in my case it did not.
In the backend world you will be able to find a LTS version that receives security updates and critical bug fixes for a long time, while in the frontend world your choice is upgrade to a newer version - which often has breaking changes - or stick with the old version - bugs and all.
I gave up with Vite because of the issues I had and went back to create-react-app. I've used it successfully on other - much smaller - projects, but yes for this project it isn't the right tool. Right now I'm trying to make the ejected version do what I need and fix the dependency issues, but if you have any suggestions of what else to try I'm all ears.
Even if the developers working on a website care about performance, the company’s marketing department won’t. Unless the manager in charge of the developers is particularly good, marketing will be better at convincing management to do things their way than the developers.
“improves battery life by up to 0.5%”
To me this line is quite ridiculous.
We all know that Chrome is now the main responsible for battery consumption on any laptop and could be optimized much more.
You mean the total energy saved across all devices? The only context in which anybody could give a fig about that is as it relates to total global energy consumption, of which it is an utterly neglible speck.
Edit: Had a go at putting some numbers on that for fun, and will partially retract my comment (no I don't, see below).
If it takes [1] around 0.01kWh to charge a smartphone, there are [2] around 6 billion smartphones, each is charged once a day and this saves 0.05 (wrong,see below) of that usage, the saving is on the order of 3GWh/day, i.e. around 125MW.
Total global energy consumption is [3] around 20 TW, so the saving is around 0.0006% of it, and this is a very generous estimate (chrome isn't all the consumption of a smartphone, not all phones are in active use and charging once a day, etc).
That said, in absolute terms it's more than I would have guessed - comparable to the electricity consumption of a small town (no, much less, probably less than the output of a single wind turbine - see below).
Yes, Google (and other global companies) actually cares about that. They work on fleet-level changes to make such differences worth it. It might not matter to you though.
What fleet-level changes are you referring to? The energy saving is certainly a nice thing (environmentally if nothing else) but it's not energy they are paying for. I don't see how it would change Google's operations in any way.
Everything is neglible in comparison to global energy consumption though, because we use energy for so many different things.
If everyone who is in a position to reduce the energy consumption of their small part significantly does their part then it will add up to a significant effort.
I don't disagree at all, but the comment I was responding to was saying that globally it's "massive" which it really isn't. Every little helps, but this is little.
I don't get how they could get a chart that is so hilariously bad into a technical post. No numbers & no tick labels. It only shows that newer = better, which is pretty much obvious from the title.
The linked vsync-tester[1] is very cool. But it's sad to see that (at least on my system) nothing has changed since 2012[2] - Firefox still misses frames; Chrome consistently lags an extra frame.
I use a wired mouse with a 1000hz polling rate on an M1 Macbook Pro with vsync disabled system wide (through Additional Tools for Xcode 13.dmg[0] => Quartz Debug.app => Enable Vertical Sync; it only actually disables vsync if you use an external monitor and close the lid of the MacBook).
Like switching to the Classic Theme from Aero in Windows 7[1], as far as I can tell, this removes at minimum 1-2 frames of input lag (typing, mouse movement, etc.) throughout all of macOS.
, I'm shocked by just how slow and laggy Chrome's builtin smooth scrolling implementation feels by comparison. In fact, it's so bad that I now open Chrome and all Electron apps with
open -a Google\ Chrome --args --disable-smooth-scrolling --disable-gpu-vsync --disable-frame-rate-limit
open -a Slack --args --disable-smooth-scrolling
open -a Spotify --args --disable-smooth-scrolling
You used to be able to disable Chrome's smooth scrolling with chrome://flags/#disable-smooth-scrolling, but that flag was removed for whatever reason.
I'm also surprised by how much faster Firefox's builtin middle mouse click autoscroll is compared to Chrome's ersatz AutoScroll[2] extension.
> I use a wired mouse with a 1000hz polling rate on an M1 Macbook Pro with vsync disabled system wide; it only actually disables vsync if you use an external monitor and close the lid of the MacBook
Are you using a >120Hz Monitor or don't you care about the occasional tearing?
I, unfortunately, still use a cheap 60hz acer monitor from my workplace.
I don't mind the occasional tearing — I usually only notice it when using autoscroll in Firefox at a lower speed/velocity.
As a remote SWE, I sit in front of my computer all day every day, so I find that the benefit in speed I get from removing at least one frame of input lag outweighs the occasional tearing which occurs as a result. I'm not exactly sure why, but I haven't noticed any tearing when playing video content.
I also spend a lot of time in XQuartz, which has some longstanding rendering bugs unless you disable vsync.
Yes, there are also platform specific tradeoffs involved. For example on Windows >8, you can't disable VSYNC on an OS level. Only option to disable VSYNC is to circumvent DWM which must be supported by the individual application (e.g. by starting in exclusive fullscreen, which is not supported by Chrome).
An important thing, as far as I'm aware of, is that if you have a Gsync monitor, you want vsync enabled, but you don't want your GPU to max-out usage-wise or reach the max refresh rate of your monitor:
Not sure how it behaves on windowed modes. For instance, Doom Eternal's fullscreen is actually composited on the desktop (could be a Vulkan thing), but doesn't seem to suffer from DWM overhead, latency wise.
That seems to be the case with a lot of modern rendering. I imagine it's why what's considered "acceptable framerates" in games keeps rising. 50 FPS on a (PAL) NES game is incredibly snappy and allows frame perfect inputs, whereas in a modern shooter it's almost unplayably sluggish.
I agree. Seems like the idea is to not worry about additional frames of lag but instead increase display refresh rates so that for example at 144Hz, 2 frames of lag "only" amount to 14ms.
Old game consoles and home computers had much better input latency so that input was usually 'realized' within the same video frame. This is much harder to do on modern hardware and operating systems (and frame rate is also only one aspect of button-to-screen latency).
The pipeline rendering architecture is probably also in part to blame. It doesn't degrade particularly gracefully.
Modern GPUs have staggered rendering where one frame is rendered while the previous frame is postprocessed (that's a bit simplified, it's more like a waterfall with a bunch of different steps). That sort of a conveyor belt-like operation always induces latency, and a struggling GPU increases the time it takes the frame to hit the screen. We blame the frame rate, but in reality that's just another symptom of what's causing the perception of sluggishness, rather than the cause itself.
Both Nvidia (and AMD?) have options to reduce latency to like 1 frame (edit: due to render ahead queue; not total latency) in their control panels. You probably pay for it with a bit of stutter when your system is pushed to the max - since there is no leeway buffer when frames don’t get finished in time.
Display latency from LCDs are another factor - something that was completely absence on CRTs.
Picture the rendering process like a conveyor belt factory. This is a bit of a simplified model, GPUs are incredibly complex and things aren't quite this straightforward, but it's good enough way of reasoning about how they operate by imagining something like Factorio.
First you load up a scene, and then it goes into one machine that does the first part of the rendering, then the next machine does the next part, and so on and so forth, until it arrives at the other end and is drawn on the screen.
It's easy to see you can start working on the next frame while the first frame is in the second machine and that's probably in general a good idea.
Reducing how many items are on the belt doesn't reduce the time it takes to go from start to finish (i.e. the latency), it still has to go through the same steps. Loading up more items on the belt at the same (probably) improves the stability of the framerate, but again it does nothing for latency. If you load up too much on the belt may cause problems, but such a condition is easy enough to determine and avoid programmatically. The frames still take the same time to go from start to finish.
Bottom line is that the time between frames and the time to render a frame are disconnected, if they seem connected it's because getting a better GPU increases them both. But you could (hypothetically) render at 120 Hz refresh rate with a 30 second rendering latency.
Having one more "spare" slot on the belt (e.g. triple- instead of double-buffering) can help to smooth over unpredictable spikes caused by other systems, but it always costs one more frame of latency even if the spare slot isn't usually needed.
In game engines, long frame pipelines were all the rage in the early 2000's to distribute work across CPU cores without having to rewrite entire single-threaded systems to multithreading (so you might have a pipeline of input-, AI-, physics- and render-thread, each adding one frame of latency).
But that's also when "input latency" became a problem, so game engines went away from this pipeline architecture and ran all those steps in a single frame by parallelizing within systems, but still chaining the inputs and output of those big systems together in a linear sequence (but all ideally within one frame).
After that came the general task schedulers, where everything that needs to happen in one frame is split into very small tasks arranged in a dependency tree, and those small tasks are run by a general task scheduler running on a thread pool (sometimes even on the GPU).
The general goal is to distribute the same work across available CPU and GPU resources, but without introducing a deep frame pipeline, and for the only reason to reduce button-to-screen latency (while still cramming as much work as possible/needed onto the CPU and GPU).
> Having one more "spare" slot on the belt (e.g. triple- instead of double-buffering) can help to smooth over unpredictable spikes caused by other systems, but it always costs one more frame of latency even if the spare slot isn't usually needed.
This is not correct:
If your application frame rate is higher than your display refresh rate, triple buffering has lower latencies than double buffering. This is due to much more frames being rendered (and most of them discarded) so that the average age of the last frame rendered before being sent to the display is much younger (but never older) as in double buffering.
In terms of latency: VSYNC off < Triple Buffering < Double Buffering.
I think we are talking about different things. I'm talking about what the GPU is doing to render a scene once the CPU has handed it off to the GPU, not what the engine is doing to produce the scene.
> But you could (hypothetically) render at 120 Hz refresh rate with a 30 second rendering latency.
This is an important point. A 120Hz refresh rate causes _at least_ a worst-case latency of 8ms. People often drop the "at least" or ignore that latency compounds across the pipeline.
> Both Nvidia (and AMD?) have options to reduce latency to like 1 frame in their control panels.
In case you are referring to pre-rendered frames, this only affects the amount of additional latency (not actual or total latency).
> You probably pay for it with a bit of stutter when your system is pushed to the max - since there is no leeway buffer when frames don’t get finished in time.
True, if your system is not maxed out, you can enable Triple Buffering. If your rendering framerate is higher than your display, it will discard obsolete frames and only push the most recent one to the display.
On ChromeOS and Windows, you can use a desynchronized 2D or WebGL canvas to avoid the additional latency at the cost of tearing artifacts and no ability to synchronize updates with the surrounding DOM.
Do you have any experience if this actually improves things on Windows (not ChromeOS)?
AFAIK DWM is the main culprit here (1-2 frames) and `desynchronized` does not circumvent it (but avoids at best 1 frame of canvas vs DOM synchronization).
It's been a long time since I used Chrome on Windows — do you know if Chrome's fullscreen mode leverages exclusive fullscreen/fse/fullscreen optimizations[0]?
I'm pretty sure that's what most games use to bypass the forced DWM vsync. For example, when I used Dolphin on one of those cheap 60hz IPS LCD monitors with no internal scaler, I always preferred the lower latency + tearing in exclusive fullscreen compared to the laggy + smooth windowed mode. There was honestly such a stark difference between the two that I found the game to be unplayable in DWM's windowed vsync mode.
> additional, unnecessary input lag when compared to Firefox:
Not for me. When scrolling in Firefox I see pauses of about 0.5 seconds every 10 seconds or so, on all websites. After the end of each pause, scroll position jumps, as if the rendered suddenly catches up with the target position.
Similar pauses when entering text in a form
I tried playing agar.io on Firefox 93 a few days ago and it was unplayably janky.
I've been using Firefox for 20 years. This problem arrived in the last year, roughly, and has been annoyingly consistent since it arrived.
I don't like Chrome. But it feels more fluid to use because I've never noticed this level of periodic stalls. It has the feel of a difference in garbage collection strategy.
I still dont understand why people call chrome a memory hog and safari efficient. Try loading Outlook on the web or confluence and you will see that both Safari and Chrome eat up tons of RAM and cpu.
I, for one, would like to stand up and offer a digital salute to the people that worked on this. This announcement doesn't do justice to the amount of work that's gone into Chromium for RenderingNG.
>A great way Chrome can render content faster is to take advantage of the multi-core CPUs and advanced GPUs present in today’s devices. Multi-core means we can do multiple kinds of work in parallel. For example, Chrome parallelizes running JavaScript, scrolling a web page, decoding an image or video,
I just re-tested this on the latest Firefox 93.0 and while it pegs an entire cpu, the playback performance is still jerky and unusable. And changing the oft-suggested setting of "gfx.webrender.all = true" still doesn't resolve it.
I don't know what Chrome is doing differently but 4k playback just works with the default settings.
gfx.webrender.all no longer has any effect, as webrender is enabled everywhere by default (if supported by your hardware, which it probably is)
It would be very helpful if you could capture a performance profile while playing the video, by going to profiler.firefox.com and following the instructions.
Over the past ~10 years, I've come to the conclusion that it's best to just pipe high quality video streams into a cross-platform external video player like mpv[0][1][2].
I can't remember what Firefox uses internally to decode/display different video codecs (ffmpeg like mpv? system builtins? hardware media encode/decode, like on the M1?), but I've always found that, through yt-dlp[3]/
streamlink[4] integration, a native external video player like mpv is better able to support high quality video streams without constantly dropping frames or tanking the performance of the tab/browser.
I can't put my finger on exactly why browser video streams feel so bad to me, but they do. Maybe it's the DOM overhead, or maybe it's something else. My personal takeaway is that browsers still just aren't optimized enough for fast/performant video playback.
Chromium seems consistently faster than Firefox to me, and I'm pretty sure that many other people have noticed this, too.
The Chromium development team intentionally optimizes for speed (at the expense of higher memory usage) more than the Firefox team does - and, if you want, you know, long battery life, this seems ideal.
I'm pretty sure because Apple is doing full-stack optimization. I'm willing to bet you that Safari has a worse trade-off than Chromium or Firefox on non-Apple platforms.
How does that have anything to do with my point? I said that Safari has an advantage over Chrome on Apple hardware only because it has an integration advantage. Chrome is still faster on most other platforms... including non-Google ones, like Windows and Linux - which the majority of users use. That is impressive. Meanwhile, there is nothing special about a browser that does best on hardware made by the same developer as it.
Plus, both Firefox and Chrome have significantly more useful features than Safari on all platforms.
Safari only wins when you care about pure performance on specifically Apple hardware without concern for features or add-ons. Not commendable.
Chrome is definitely faster at using up all available resources! Platform-level optimization cannot lead to drastic changes in memory utilizations unless Google completely ignores the macOS platform! Which features are needed for the 99.99% browser usage? I open Chrome with 10 tabs opened and 15 minutes later it's using 8GB of RAM! Basic pages, like Messenger, Facebook, and Gmail. The same pages with the exact used browser features in Safari use just a fraction of the resources and actually provide a better browsing experience! So, Google should rethink what a browser is nowadays - from a thin client, they turned the browser into a morbidly-obese client!
> Basic pages, like Messenger, Facebook, and Gmail.
You belay your ignorance of webdev. Those three sites are all extremely heavy web applications - barely even "sites" - and I'm willing to bet you they still are faster on Chrome than on Safari (on non-Apple platforms).
> The same pages with the exact used browser features in Safari use just a fraction of the resources and actually provide a better browsing experience!
Instead of using your own subjective perception, you should try running a series of standard performance benchmarks, like the SunSpider JavaScript benchmarks[1] on Chrome and Safari on a non-Apple platform - then see if your perceived performance gap remains.
Subjective, really? So, I open the same tabs in both browsers and I see the resource utilization difference and that's subjective? I don't care about the browser features, which make Chrome use all available resources on my computer in 10 minutes after launching!
I didn't say "resource utilization". I said "are faster" and "standard performance benchmarks". Those are two completely different things. Please read comments more carefully before replying.
Meanwhile, even if you don't care about the features - tons of people do, and those browsers are built for them, too, not just you on your Apple hardware.
On the topic of improving Chrome — can we get it to stop making 2-4 attempts to put its updater in macOS launchd every time it runs? What’s the purpose of that? Obviously non-technical users didn’t remove it. Seems obnoxious.
It is a nice long term approach, but right now there should be more focus on the issue with service workers running amok and consuming a major part of the CPU without doing anything useful. The problem was worse in the past, but it is still not full ysolved and if you think about the huge number of Chrome installations running worldwide, is a huge waste of energy.
Here is one issue from the Chromium issue tracker if you are interested in details:
So i'm personally a NoScript (Tor Browser) user, but every single time i've enabled JavaScript in the past years, i wished it was not multi-threaded. Most times, a random tab will start eating most of my CPU, and i wish i had just one process-per-tab to kill to own my computer again.
On lower-end hardware especially, multi-threaded client-side scripting can make your entire computer unresponsive super quickly. I wish browser/website developers made UX testing on actual hardware (not everybody owns the latest Macbook Pro) before shipping stuff.
EDIT: To the downvoters, why? Am i missing something? Is there an easy way to make JS engines respect my resources and to keep my computer responsive when browsing the "modern" web?
Does anyone here know whether/how this should affect WebGL rendering?
I'm developing a browser-based 3D game, and since a week or two ago I've noticed the rendering on mac/chrome is way slower than before. In fact my game now seems to be GPU-bound, where up to now it's always been CPU-bound. I think this started right around Chrome 94 shipped, but it's hard to downgrade and check. This is only on mac; PC performance doesn't seem to have changed.
TFA makes it sound like whatever is new in v94 is only about page rendering, not WebGL, but does anyone know for sure?
I've also seen a somewhat recent performance degradation on MacOS+Chrome in WebGL when the WebGL canvas is close to fullscreen size, and even for extremely simple scenes (it's inconsistent though, maybe related to remaining battery life?). My guess is that this is some problem in the interfacing between Chrome and macOS, or purely in macOS though, because other platforms are fine.
The issue reproduces in Chrome 94 but not current mac/Firefox, so I think it's new (though with now way to downgrade Chrome it's hard to be sure). Unfortunately I don't have a shareable URL that reproduces it, but if I can find one I'll file.
Rendering fast is nice, but when are they going to make the rendering look good? Image scaling at non-integer scales in Chrome is atrocious -- either coming out a blurry or aliased mess.
I almost always need to zoom in 20% to 50% because web designers love tiny fonts too much, and setting a minimum font size breaks their fancy layouts. This results in Chrome making a mess of all images on the page.
Thankfully Firefox resamples images so they look good at non-integer scaling factors too.
This is only tangentially related (images vs fonts), but a small pet peeve of mine that kept me from migrating to Chrome from Firefox on my Windows machine back in the day is the fact that Chrome uses an internal text antialiasing engine that is, as far as I can tell, impossible to disable. Firefox, on the other hand, honors the system antialiasing settings.
So, for example, if you disable cleartype on Windows, you will have crisp aliased fonts at default font sizes on Firefox, but you will still get blurry antialiased fonts in Chrome no matter what.
160 comments
[ 4.1 ms ] story [ 245 ms ] threadHow long can this x% faster continue? There must be some theoretical optimum, how far are we away?
That's on a Galaxy S4, mind you.
Dillo is blazing fast on desktop, but doesn't support https very well. It also doesn't support JavaScript, which isn't a big deal to me.
I get annoyed with how slow Chrome is, so I switch Firefox. After a while the Firefox profile gets bloated and I get annoyed and switch back to Chrome with a clean profile and it feels really quick again. Ad infinitum.
Good thing is, that it's possible to create truly groundbreaking apps using non-conventional techniques, as web becomes faster and richer with new APIs.
For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll be awesome.
I have one example to prove my words. I used iPhone 4S. With iOS 6 I was able to use navigator software which worked very snappy and awesome. Few years later with iOS 9, navigator was very slow, forcing me to buy new phone eventually. With iPhone 8 it returned to blazing fast. But it did not have any new functions. They just started to consume more memory, just because they can. My UX did not change a little bit. I just had to buy new phone with infinitely faster CPU and loads of RAM, just to keep my UX from degrading.
This has been promised since at least the WebGL and asm.js days. It still won't happen, but not mainly for technical reasons, but for business reasons.
...but of course also some technical reasons. Asm.js/WASM and WebGL/WebGPU are fine, but most other web APIs are a mess and the web is a highly unstable platform, APIs are deactivated or deprecated on a whim, APIs change behaviour unpredictably, behaviour differs between browsers, etc etc...
TL;DR: the web needs a proper "DirectX initiative" like what Microsoft did in the late 90's to get Windows gaming off the ground.
This can change very quickly if there's actually some breakthrough web game, but that hasn't happened so far, and nobody wants to be the first to take the risk.
That's not correct though, the game runs on a Linux box in Google's datacenters (granted, from a business perspective that's nitpicking - but not quite, see below, but it's a massive difference from a technical perspective).
Scaling to large audiences is much more expensive with the game streaming approach though (but we'll never really know because Stadia bombed, just as all other game streaming platforms before).
Why? We can already play AAA games on our computers. It works very well, much better than anything web-based. Why would anyone put effort into replicating the same thing inside the browser?
This is much more important for indie devs than AAA devs though (the current problems of the web platforms are not really 'AAA specific').
Also, don't forget that PC gaming could very well have died out during the transition from DOS to Windows without Microsoft actively supporting game development on Windows (with the DirectX APIs), without this, AAA gaming could very well be console-exclusive now.
Agreed, however platforms that restrict app distribution also heavily restrict what you can run via the browser (see Ios). So the benefit is minimal.
> a space to try out quirky new ideas
This has nothing to do with web. Look at steam's catalog. Plenty of whacky quirky stuff is available.
> no lengthy download or installation process for instance
Why do you think AAA games will not need downloading assets and logic?
> This is much more important for indie devs than AAA devs though
I agree, but this is a solved problem with Steam. No need to develop your own over the web.
As internet connections get faster it makes sense to stream/prefetch data directly from CDNs as needed instead of downloading everything upfront.
> Look at steam's catalog. Plenty of whacky quirky stuff is available.
Agreed, but that's the exception, not the rule. Look at Apple's app store ecosystem for a counter example where apps and developers are banned on Apple's whim. This couldn't happen on the web.
You want one browser vendor to implement a proprietary API and then have the ramining vendors try to emulate it?
But apart from that, Microsoft was in a unique position to dictate standards to GPU vendors, as draconian as it sounds, this worked much better than Khronos' design-by-committee approach in OpenGL.
That didn't help the large move to mobile gaming by its primary audience (which I'm guessing was teens).
Towards the end Kongregate became a platform for idle games that pushed users hard towards pay to win. Sucks, but they grew huge off the glory days of ad revenue and I presume they had to do something to keep surviving.
https://github.com/gpuweb/gpuweb/issues/566
Basically. Rather than doing something better w3c is designing by committee so hard it somehow made worse OpenGL.
A fellow contributor, that had to deal with pain of OpenGL, laughed this shit out of the gate.
And I mean look at it. Who in their right mind looked at that and said, yeah that looks decent.
Basically bunch of stuff listed in that blog are Rust specific uint vs int.
Others are kinda standards problem of undefined behavior being well - undefined. Gamedevs are used to this, but not Rust devs.
I'm reminded of xkcd https://xkcd.com/927/
So rather than relying on previous work, they wrote their own somehow ugliest standard.
- Not knowing you need to have entry point for the shader to be executed.
- kvark's complaint about OpFmod being misnamed are kinda missing the point, % isn't the mod operator but remainder operator (in C/C++)
- https://mobile.twitter.com/TheSpydog/status/1232819839888166... You know it's a pretty bad idea when Unity and Adobe are begging you not to do this.
- I mean what you prefer to write?
GLSL:
WSGL:I'm also really not sure how you got the first point from what he wrote. He was not saying he was surprised to find "you need to have an entry point" he was saying the restriction made no sense, and that existing tools didn't even take advantage of having more than one entry point due to driver bugs.
The rest of your points are basically just opinions masquerading as something else. In any case I don't actually care how hard WGSL is to write, because I don't have to write it (you can go through a translation layer). What I'm not going to do is pretend that SPIR-V is a great choice for this intermediate layer solely on the basis of what I've heard from other graphics people who haven't actually tried to use it for that purpose--which is exactly what the article is about.
> he was saying the restriction made no sense
So presented with reality of a complex, buggy drivers, his solution is - to ignore it? Wow imagine in UTF-8 people just said, yeah 8bit 0 are ok everywhere and caused hundred of billions of lines of code to be written to deal with null mid UTF8 stream.
> I don't actually care how hard WGSL is to write
Awfully dismissive. Well, ok, you won't have to write it but someone will. And those someone are going to curse whoever wrote that abomination of a spec.
A spec that: - That doesn't respect backwards compatibility - Looks like pure torture to write in - Misunderstands some part like OpRem
I'm not very confident in it to be honest. Looks to me just another overly elaborate moat for browser implementors.
You get a shitty distribution model (relying on browser for cache or limited localstorage, or whatever you want it's shitty in the browser and inconsistent, browsers aren't built to handle GB sized assets).
You pay the sandbox tax even in the ideal scenario and there are plenty pathological ones. And even if you aren't performance constrained you're adding battery drain for no benefit.
Then there's the shitty input model and interaction with browser chrome.
And what are the benefits exactly ? Avoiding app stores ? Might benefit the developer but not really a benefit for the consumer.
well, if a company can avoid paying a significant portion of revenue to an app store they might be able to hire better or more developers which might conceivably be a benefit for the consumer.
If indeed the amount of developers employed was inversely correlated with software quality then the best software is that which does not exist. I realize there is a pithy saying that the best code is no code at all but I am not especially fond of such illogical pithiness.
There may be products that it is best they not exist at all, but for products we do want to exist it follows that some number of developers of that product correlates with the quality of its existence.
Slightly off topic but I wonder if WASM and the web can provide a “fixed” virtual platform for games.
A lot of games are heavily platform dependent, when the hardware for those platforms die the games will be nigh unplayable without a huge remastering effort or building an emulator of said platform which may or may not be technically feasible - even on PC we have games breaking as hardware advanced, e.g. Deus Ex had to be patched to work with multi core CPUs if I remembered right.
You don't need such assets to make good games anyway. The obsessions with AAA are unhealthy - many of the best games are not AAA at all, but strictly indie.
It's also probably another view of the Jevons Paradox: as efficiency of software increases, it gives more way for more complexity and "optimizations" that in the end make the end result as slow as before.
That's a very liberal paraphrasing. Parkinson's law is specifically about the amount of time that it takes to complete work (by humans, e.g. for a project deadline).
If you want to reference something that serves as good commentary about software performance, Wirth's law is right there for the using.
Carmack already tried to do it with Quake Live. It did not go far.
“What Intel giveth, Microsoft taketh away”
https://en.m.wikipedia.org/wiki/Andy_and_Bill%27s_law
What's the point of new hardware if the new software that's written for it makes it just as slow (or in this case: much slower) than the old hardware?
I am still pissed off that my 2012 Macbook Air is no longer receiving OS updates - compare that to Microsoft that allows me to run windows on basically any PC
MacBooks aren't cheap. For the average person they are a significant expense. So the lifetime of support should reflect that.
That system did run Windows 3.0, and later on 3.1 & Windows 95, but for a lot of tasks I would just use MSDOS and be done with that. Even running character mode Linux with pre 1.0 kernel in multiuser mode was fairly snappy in those days.
The first generation unibody macbook pros running OSX felt fairly fast and snappy back in the day, but even that was no match to the peak MSDOS speed. And I suppose that snappiness was felt mostly because Windows XP while fast, was not the snappiest OS out there.
In 2021 with every component seemingly 100x faster than those systems, with a 8 core i9 CPU on my MBP 16, I dont see any environment being that fast. I really miss peak MSDOS experience from the days of Windows 3.0 era.
https://nanoreview.net/en/cpu-compare/apple-m1-vs-amd-ryzen-...
Compare Zen 3 to M1... M1 is a generation ahead in lithography and enjoys an appreciable thermal/efficiency advantage resultingly. Zen 3 and M1 have neck-and-neck single core performance on many tasks. Yet Zen 3 can offer many more cores and make up for its efficiency in raw thermal envelope availability.
Then also the expectation from older and more inexpensive devices. If one gets used to M1-level performance, a $200 CPU from 4 years ago starts to look quite slow; e.g., the Ryzen 5 1600:
https://nanoreview.net/en/cpu-compare/apple-m1-vs-amd-ryzen-...
Once we start to look at the truly power constrained, say a mainstream phone from a few years ago; let's say the iPhone 8/X since it's one of the best selling in recent history. Then you're at about 50% of the single threaded performance AND working with fewer cores.
https://en.wikipedia.org/wiki/List_of_best-selling_mobile_ph...
https://www.cpu-monkey.com/en/compare_cpu-apple_a11_bionic-1...
There is another large factor at play in the past 20 years in particular though: that is the increasing predominance of "Python-like" languages. I mean that in the sense that more of the code we interact with on a daily basis is written at a very high level than 20 years ago. Python in particular is just about the least efficient of all the most widely deployed languages.
Ranking Programming Languages by Energy Efficiency: https://haslab.github.io/SAFER/scp21.pdf
2021 Top Languages: https://spectrum.ieee.org/top-programming-languages/
And also many websites include more tracking, for example Google search results used to directly send you to the result page. Now they first send you to Google so that they know you clicked but it also adds noticeable latency.
Now in 2021, most popular websites use CDNs and have servers based out datacentres closer to India and the page load speed and latency has gone down significantly for us.
But page bloat is a different matter, I still remember spending the greater part of a day (or maybe more0 downloading the MSIE 2.0 installer on a 1200bps dial up modem. Today page sizes > 1mb are common even on mobile sites.
I tremendously hate it and it’s not like developers are incapable of building performant software, quite the opposite. But that’s just not where the resources go. The common sentiment (I have heard this directly uttered) is “If the user has 8GB of RAM, why wouldn’t I use it?”.
1) Chrome in Android has recently begun to hang when trying to go back to a previous page. It's gotten so bad that I end up clicking multiple times, which all register in rapid succession. If I click more times than the history depth for the tab (say 3 or 4), I end up back on the home screen and a lost tab with lost (or at least not conveniently recoverable) history.
2) AMP. When Google began pushing AMP my objections were mostly based on principle; performance was mostly a wash for me. Now the AMP viewer is so slow and so crash prone that I'm conflicted. On the one hand, I'm glad to see that AMP is clearly failing. On the other hand, Android and Chrome still strongly favor AMP, and I'm too lazy to wrestle with Google over default settings, so when I don't have the presence of mind to explicitly open a web site (e.g. when using Google News) I'm left to suffer the poor performance and bugginess in addition to other intentional AMP headaches--lack of copy+paste, less scrolling and zooming control, etc.
Not quite the same thing, but related, technologies like QUIC are really only beneficial in the context of a web ecosystem built by Google. QUIC shines on websites pulling in many resources from disparate hosts, which in most cases is a situation created by advertising and analytics services. IOW, these days much of the benefits of Google's work simply pays down the debts Google itself created or advocated. And while Google still stands out for the amount of labor it invests in open source security and performance, it's just a matter of time before we pass break even into negative return territory. That happened long ago with Google Search itself; Google Search results are as slow, irrelevant, and obscured by obnoxious and misleading advertising as the competitors it originally, rapidly displaced. Heck, when Google began those investments (Android, Chrome, OS security, etc) they were crystal clear why they were making them--to nurture and grow an ecosystem into which they could grow their advertising business, same as their rationale for making a snappy search service and a non-intrusive advertising network. There's a limit to how well they can improve that ecosystem, but the limit for exploiting that ecosystem can easily result into a situation far worse than the one Google originally saved us all from.
Consider why rendering work is even relevant in 2021. It's not for the benefit of services like Netflix or YouTube, which already enjoy low-power hardware acceleration, and arguably not for games or similar interactive content. It's so they can continue shifting their advertising ecosystem from minimalistic text-focused display boxes to animations and videos peppered up, down, over, and under content views. They can't do that if advertising-laden web pages drain your battery in 15 minutes, as notorious Flash-based ads once did. Steve Jobs' famously removed Flash from mobile; Google, for obvious reasons, is taking the alternative path.
I do have my fingers crossed that Rust+WASM+WGPU will bring about some more efficient products, though.
But I don’t think non-technical users value memory efficiency as much as we like to think sometimes.
> It makes it much easier to develop software
I've never seen compelling evidence that this is the case. Every time this argument is made, it seems to be by a webdev who has no significant experience with building desktop applications. Sure, if you already know webdev, it's easy to build things with webtech. This isn't particularly interesting. I'm much more productive building desktop applications than webapps, but that's because I've spent almost all of my time building desktop applications.
The real question is, given an average developer who has spent around the same amount of time on learning web development and desktop development, and both at a minimum amount of time (say, 100 hours) - which is more productive, and by how much?
I can build a web application and deploy it on the web, on Windows, on Mac OSX, on iOS, on Android, on Linux, immediately. With minimal extra effort, assuming I know what I’m doing.
Correct me if I’m wrong (it’s possible), but I don’t think that’s at all possible with native libraries, or even cross-platform frameworks like Qt.
It also means companies don’t have to hire multiple product teams. They can hire one team.
So even if native development is 10-20% more productive (I’d disagree, but for arguments sake), it’d still fall short.
Webtech might score low on the CPU efficiency scale, but it scores very high when it comes product timelines, headcount, payroll and (arguably) ease-of-hiring.
This is why I think webtech almost always makes more business sense. At least for your typical SaaS product.
This is why I’m excited for WASM. We might finally have the tooling for truly cross-platform development without sacrificing efficiency/low level control.
Case in point: Early last year I created a proof of concept web app that needs to run in the browser and a webview on an old version of Android. I used create-react-app which at the time was the most popular way to... create React apps. This year I updated all the deps and something in the build broke meaning it no longer produces something runnable on the old version of Android we need. There's been an open issue on create-react-app for nearly a year, however it seems Facebook have abadoned that project and everyone has switched to Vite/Rollup now. I spend half a day switching to that which mostly works, except as it doesn't actually bundle, the dev build no longer works on the Android webview - but that's not such a deal breaker. However in the production build treeshaking seems to be completely broken, so the resulting build is a few mb instead of a few hundred kb.
Do you not see that you are the problem in this scenario? Facebook has not abandoned the project and very very few people have switched to Vite/Rollup. You're doing hype driven development.
Now I get this is how a lot of these front end tech are portrayed, and that a lot of these projects could be better in terms of defaults, but what has to be accomplished in front end tech is very difficult. It has to run across so many different browsers, on different operating systems, with different engines across who knows how many devices.
Part of the reason front end development is a mess is because people like you come in, think you don't have to spend any time learning it, and can just put something up because "it's just javascript, it's a toy language". Learn the platform and develop for it. You reached for the biggest hammer you could find when you probably could have used something much smaller and easier to use. You chose the wrong tool, and it's probably because you didn't bother putting in the time to actually figure out what you know and how it would be maintained.
The reason why I choose create-react-app when I first started this project was because it was most popular and recommended way to create a React app. I've hand rolled Webpack and Babel configurations before, and upgrading to the next major version is alwyays a headache, which I wanted to avoid again. Sticking to old versions is equally bad because if someone wants to try something new it's not always possible (two of the biggest frontend apps our company has are stuck on React 15). I figured it's an official project from Facebook, so will be around for a long time and well maintained, but obviously that assumption was wrong for my use case.
The upgrade instructions don't say much [0], but in my case it was a dependency of a dependency of create-react-app which was causing issues. Because of the way create-react-app is built, it isn't usually possible to downgrade or upgrade specific dependencies, or change the configuration for certain parts of it. You just have to go with what they suggest and hope that works for you - which in my case it did not.
In the backend world you will be able to find a LTS version that receives security updates and critical bug fixes for a long time, while in the frontend world your choice is upgrade to a newer version - which often has breaking changes - or stick with the old version - bugs and all.
I gave up with Vite because of the issues I had and went back to create-react-app. I've used it successfully on other - much smaller - projects, but yes for this project it isn't the right tool. Right now I'm trying to make the ejected version do what I need and fix the dependency issues, but if you have any suggestions of what else to try I'm all ears.
[0] https://create-react-app.dev/docs/updating-to-new-releases/
https://en.wikipedia.org/wiki/Exokernel
(But they get more power efficient and quieter, this is true.)
Edit: Had a go at putting some numbers on that for fun, and will partially retract my comment (no I don't, see below).
If it takes [1] around 0.01kWh to charge a smartphone, there are [2] around 6 billion smartphones, each is charged once a day and this saves 0.05 (wrong,see below) of that usage, the saving is on the order of 3GWh/day, i.e. around 125MW.
Total global energy consumption is [3] around 20 TW, so the saving is around 0.0006% of it, and this is a very generous estimate (chrome isn't all the consumption of a smartphone, not all phones are in active use and charging once a day, etc).
That said, in absolute terms it's more than I would have guessed - comparable to the electricity consumption of a small town (no, much less, probably less than the output of a single wind turbine - see below).
[1] https://www.quora.com/How-much-in-kwh-does-it-take-to-charge...
[2] https://www.statista.com/statistics/330695/number-of-smartph...
[3] https://www.theworldcounts.com/stories/current_world_energy_...
Edit 2: On reflection, I think this is an big overestimate. I suspect the real saving is on the order of a few MW.
Edit 3: As the reply says, I missed a zero, which brings it down to probably on the order of a MW.
If everyone who is in a position to reduce the energy consumption of their small part significantly does their part then it will add up to a significant effort.
But it's still tiny in a relative sense.
Chrome has 1 to 2 frames (17ms to 33ms on a 60Hz display) of additional, unnecessary input lag when compared to Firefox:
https://bugs.chromium.org/p/chromium/issues/detail?id=460919
[1] https://www.vsynctester.com/
[2] https://phoboslab.org/log/2012/06/measuring-input-lag-in-bro...
Like switching to the Classic Theme from Aero in Windows 7[1], as far as I can tell, this removes at minimum 1-2 frames of input lag (typing, mouse movement, etc.) throughout all of macOS.
In Firefox's about:config, after setting
user_pref("accessibility.force_disabled", 1) user_pref("general.smoothScroll", false) user_pref("general.autoScroll", true)
, I'm shocked by just how slow and laggy Chrome's builtin smooth scrolling implementation feels by comparison. In fact, it's so bad that I now open Chrome and all Electron apps with
open -a Google\ Chrome --args --disable-smooth-scrolling --disable-gpu-vsync --disable-frame-rate-limit open -a Slack --args --disable-smooth-scrolling open -a Spotify --args --disable-smooth-scrolling
You used to be able to disable Chrome's smooth scrolling with chrome://flags/#disable-smooth-scrolling, but that flag was removed for whatever reason.
I'm also surprised by how much faster Firefox's builtin middle mouse click autoscroll is compared to Chrome's ersatz AutoScroll[2] extension.
[0]: https://download.developer.apple.com/Developer_Tools/Additio...
[1]: https://pavelfatin.com/typometer/
[2]: https://chrome.google.com/webstore/detail/autoscroll/occjjkg...
Are you using a >120Hz Monitor or don't you care about the occasional tearing?
I don't mind the occasional tearing — I usually only notice it when using autoscroll in Firefox at a lower speed/velocity.
As a remote SWE, I sit in front of my computer all day every day, so I find that the benefit in speed I get from removing at least one frame of input lag outweighs the occasional tearing which occurs as a result. I'm not exactly sure why, but I haven't noticed any tearing when playing video content.
I also spend a lot of time in XQuartz, which has some longstanding rendering bugs unless you disable vsync.
https://www.youtube.com/watch?v=IaPh4tc0_B0
user_pref("accessibility.force_disabled", 1)
user_pref("general.smoothScroll", false)
user_pref("general.autoScroll", true)
---
# --disable-frame-rate-limit is buggy on macOS
open -a Google\ Chrome --args --disable-gpu-vsync --disable-smooth-scrolling
open -a Slack --args --disable-frame-rate-limit --disable-gpu-vsync --disable-smooth-scrolling
open -a Spotify --args --disable-frame-rate-limit --disable-gpu-vsync --disable-smooth-scrolling
https://youtu.be/E3wTajGZOsA
https://www.youtube.com/watch?v=YR0vNs0ZdWI
Not sure how it behaves on windowed modes. For instance, Doom Eternal's fullscreen is actually composited on the desktop (could be a Vulkan thing), but doesn't seem to suffer from DWM overhead, latency wise.
Modern GPUs have staggered rendering where one frame is rendered while the previous frame is postprocessed (that's a bit simplified, it's more like a waterfall with a bunch of different steps). That sort of a conveyor belt-like operation always induces latency, and a struggling GPU increases the time it takes the frame to hit the screen. We blame the frame rate, but in reality that's just another symptom of what's causing the perception of sluggishness, rather than the cause itself.
Display latency from LCDs are another factor - something that was completely absence on CRTs.
Picture the rendering process like a conveyor belt factory. This is a bit of a simplified model, GPUs are incredibly complex and things aren't quite this straightforward, but it's good enough way of reasoning about how they operate by imagining something like Factorio.
First you load up a scene, and then it goes into one machine that does the first part of the rendering, then the next machine does the next part, and so on and so forth, until it arrives at the other end and is drawn on the screen.
It's easy to see you can start working on the next frame while the first frame is in the second machine and that's probably in general a good idea.
Reducing how many items are on the belt doesn't reduce the time it takes to go from start to finish (i.e. the latency), it still has to go through the same steps. Loading up more items on the belt at the same (probably) improves the stability of the framerate, but again it does nothing for latency. If you load up too much on the belt may cause problems, but such a condition is easy enough to determine and avoid programmatically. The frames still take the same time to go from start to finish.
Bottom line is that the time between frames and the time to render a frame are disconnected, if they seem connected it's because getting a better GPU increases them both. But you could (hypothetically) render at 120 Hz refresh rate with a 30 second rendering latency.
In game engines, long frame pipelines were all the rage in the early 2000's to distribute work across CPU cores without having to rewrite entire single-threaded systems to multithreading (so you might have a pipeline of input-, AI-, physics- and render-thread, each adding one frame of latency).
But that's also when "input latency" became a problem, so game engines went away from this pipeline architecture and ran all those steps in a single frame by parallelizing within systems, but still chaining the inputs and output of those big systems together in a linear sequence (but all ideally within one frame).
After that came the general task schedulers, where everything that needs to happen in one frame is split into very small tasks arranged in a dependency tree, and those small tasks are run by a general task scheduler running on a thread pool (sometimes even on the GPU).
The general goal is to distribute the same work across available CPU and GPU resources, but without introducing a deep frame pipeline, and for the only reason to reduce button-to-screen latency (while still cramming as much work as possible/needed onto the CPU and GPU).
This is not correct:
If your application frame rate is higher than your display refresh rate, triple buffering has lower latencies than double buffering. This is due to much more frames being rendered (and most of them discarded) so that the average age of the last frame rendered before being sent to the display is much younger (but never older) as in double buffering.
In terms of latency: VSYNC off < Triple Buffering < Double Buffering.
This pipeline: https://www.khronos.org/opengl/wiki/Rendering_Pipeline_Overv...
This is an important point. A 120Hz refresh rate causes _at least_ a worst-case latency of 8ms. People often drop the "at least" or ignore that latency compounds across the pipeline.
In case you are referring to pre-rendered frames, this only affects the amount of additional latency (not actual or total latency).
> You probably pay for it with a bit of stutter when your system is pushed to the max - since there is no leeway buffer when frames don’t get finished in time.
True, if your system is not maxed out, you can enable Triple Buffering. If your rendering framerate is higher than your display, it will discard obsolete frames and only push the most recent one to the display.
Yes, that. Should have been more careful with my words - i.e. I meant latency of 1 frame due to the render ahead queue.
https://developers.google.com/web/updates/2019/05/desynchron...
We added this for low latency drawing in Keep and Chrome Canvas and the ChromeOS PDF annotation mode.
AFAIK DWM is the main culprit here (1-2 frames) and `desynchronized` does not circumvent it (but avoids at best 1 frame of canvas vs DOM synchronization).
I'm pretty sure that's what most games use to bypass the forced DWM vsync. For example, when I used Dolphin on one of those cheap 60hz IPS LCD monitors with no internal scaler, I always preferred the lower latency + tearing in exclusive fullscreen compared to the laggy + smooth windowed mode. There was honestly such a stark difference between the two that I found the game to be unplayable in DWM's windowed vsync mode.
[0]: https://devblogs.microsoft.com/directx/demystifying-full-scr...
edit: to answer my own question, it looks like Chrome does not use exclusive fullscreen https://news.ycombinator.com/item?id=28784108
It has complex and non-obvious effects. greggman on the three.js issue wrote a really nice summary on why it shouldn't be the default.
It's really only appropriate for highly latency sensitive applications, like drawing or certain games.
Not for me. When scrolling in Firefox I see pauses of about 0.5 seconds every 10 seconds or so, on all websites. After the end of each pause, scroll position jumps, as if the rendered suddenly catches up with the target position.
Similar pauses when entering text in a form
I tried playing agar.io on Firefox 93 a few days ago and it was unplayably janky.
I've been using Firefox for 20 years. This problem arrived in the last year, roughly, and has been annoyingly consistent since it arrived.
I don't like Chrome. But it feels more fluid to use because I've never noticed this level of periodic stalls. It has the feel of a difference in garbage collection strategy.
Safari is efficient. Chrome becomes efficient. The latter is only possible if Chrome isn’t efficient currently.
I've noticed that Firefox is not as smooth as Chrome when playing 4k video. This has been an ongoing issue experienced by many for several years: https://www.google.com/search?q=firefox+4k+video+stutters
I just re-tested this on the latest Firefox 93.0 and while it pegs an entire cpu, the playback performance is still jerky and unusable. And changing the oft-suggested setting of "gfx.webrender.all = true" still doesn't resolve it.
I don't know what Chrome is doing differently but 4k playback just works with the default settings.
It would be very helpful if you could capture a performance profile while playing the video, by going to profiler.firefox.com and following the instructions.
I can't remember what Firefox uses internally to decode/display different video codecs (ffmpeg like mpv? system builtins? hardware media encode/decode, like on the M1?), but I've always found that, through yt-dlp[3]/ streamlink[4] integration, a native external video player like mpv is better able to support high quality video streams without constantly dropping frames or tanking the performance of the tab/browser.
I can't put my finger on exactly why browser video streams feel so bad to me, but they do. Maybe it's the DOM overhead, or maybe it's something else. My personal takeaway is that browsers still just aren't optimized enough for fast/performant video playback.
[0]: https://mpv.io/
[1]: https://github.com/grmat/play-with
[2]: https://addons.mozilla.org/en-US/firefox/addon/play-with/
[3]: https://github.com/yt-dlp/yt-dlp
[4]: https://github.com/streamlink/streamlink
The Chromium development team intentionally optimizes for speed (at the expense of higher memory usage) more than the Firefox team does - and, if you want, you know, long battery life, this seems ideal.
Plus, both Firefox and Chrome have significantly more useful features than Safari on all platforms.
Safari only wins when you care about pure performance on specifically Apple hardware without concern for features or add-ons. Not commendable.
You belay your ignorance of webdev. Those three sites are all extremely heavy web applications - barely even "sites" - and I'm willing to bet you they still are faster on Chrome than on Safari (on non-Apple platforms).
> The same pages with the exact used browser features in Safari use just a fraction of the resources and actually provide a better browsing experience!
Instead of using your own subjective perception, you should try running a series of standard performance benchmarks, like the SunSpider JavaScript benchmarks[1] on Chrome and Safari on a non-Apple platform - then see if your perceived performance gap remains.
[1] https://webkit.org/perf/sunspider/sunspider.html
Meanwhile, even if you don't care about the features - tons of people do, and those browsers are built for them, too, not just you on your Apple hardware.
Here is one issue from the Chromium issue tracker if you are interested in details:
https://bugs.chromium.org/p/chromium/issues/detail?id=123168...
So i'm personally a NoScript (Tor Browser) user, but every single time i've enabled JavaScript in the past years, i wished it was not multi-threaded. Most times, a random tab will start eating most of my CPU, and i wish i had just one process-per-tab to kill to own my computer again.
On lower-end hardware especially, multi-threaded client-side scripting can make your entire computer unresponsive super quickly. I wish browser/website developers made UX testing on actual hardware (not everybody owns the latest Macbook Pro) before shipping stuff.
EDIT: To the downvoters, why? Am i missing something? Is there an easy way to make JS engines respect my resources and to keep my computer responsive when browsing the "modern" web?
I'm developing a browser-based 3D game, and since a week or two ago I've noticed the rendering on mac/chrome is way slower than before. In fact my game now seems to be GPU-bound, where up to now it's always been CPU-bound. I think this started right around Chrome 94 shipped, but it's hard to downgrade and check. This is only on mac; PC performance doesn't seem to have changed.
TFA makes it sound like whatever is new in v94 is only about page rendering, not WebGL, but does anyone know for sure?
The launch in Chrome 94 does not affect WebGL. It's just for HTML/CSS content.
If you can reproduce the issue and can share a URL that does so, please file a bug at crbug.com/new for us to investigate.
The issue reproduces in Chrome 94 but not current mac/Firefox, so I think it's new (though with now way to downgrade Chrome it's hard to be sure). Unfortunately I don't have a shareable URL that reproduces it, but if I can find one I'll file.
I almost always need to zoom in 20% to 50% because web designers love tiny fonts too much, and setting a minimum font size breaks their fancy layouts. This results in Chrome making a mess of all images on the page.
Thankfully Firefox resamples images so they look good at non-integer scaling factors too.
So, for example, if you disable cleartype on Windows, you will have crisp aliased fonts at default font sizes on Firefox, but you will still get blurry antialiased fonts in Chrome no matter what.
Could you file a bug with an example at crbug.com/new?