You need to patch Chromium on Linux to get hardware accelerated video playback. In addition, you need to either have a Skylake or later CPU or tell YouTube to serve H.264 encoded video instead of VP9. This has nothing to do with web app vs. native.
Considering you don't have to do any of this on a native app (VLC) and just automatically get all the performance improvements, this has everything to do with web app vs. native
Actually it is more a consequence of Web browsers blacklisting your GPUs, even when they should be ok.
This is why WebGL hasn't really taken off for gaming.
You can have the perfect game running on 60 FPS on your system, then random dude tries to play the game, and browser decides it is blacklisted, goes back into software rendering and everything is choppy.
Meanwhile he/she doesn't have any issue playing native games and wonders why the browser game doesn't cut it.
Ok, I'm very much pro-native for intensive applications, but...
> Meh, the first thing about the browser games is the load time. It's not like downloading a native game and reliably storing it.
What's the difference between native game on an SSD vs browser game on an SSD (web local storage)? (Ok, other than time taken compiling that js monster, unless webassembly is used.)
> The second thing were the CPU/memory problems because all the code was in js.
First of all, you can also use webassembly. Secondly, you can program js in ways that don't cause much memory bloat. Native arrays, etc. Especially when compiled from C/C++/Rust etc.
Of course browser games have significant handicap. But I don't see any reason for them not to eventually reach at least 50% performance compared to native. Maybe even more. For a lot of applications, that's more than enough.
1. Both VLC & Chrome are native apps. VLC defaults to SD resolution (you can check codec statistics during playback), while the YouTube web app adaptively streams the best quality your hardware and network can support.
2. VLC & chrome likely use the same decoder source code, especially for VP9. But video playback is just one component of Chrome. It has to do so much more, like run untrusted code from the internet, and Sandbox it all. And keep the 10 extensions loaded running while your video is playing (like an adblocker that skips YouTube ads)
3. While not the case in the instance, chrome also supports background tasks while your playback is in progress. Like downloading your favorite game while watching PewDiePie reviewing it on YouTube
4. Not to mention all the analytics Google is likely gathering and sending on your choice of video, what parts you skipped, ....
If anything, Chrome/Browser is likely to optimize the heck out of the playback/decoding pipeline because it needs to do so much more beyond just playback that VLC does
The point of the article is that a native program that was meant to do one thing (VLC, play videos, though ok the "do one thing" is a bit stretched when it comes to a media player) needs less resources to do that thing (with thing in this case being stream a video) than a web site running inside a browser.
And the reason is basically what you wrote. However the point wasn't why it happens, but to focus on that it happens - ie. native apps matter because they are (or can be) faster.
BTW...
> While not the case in the instance, chrome also supports background tasks while your playback is in progress. Like downloading your favorite game while watching PewDiePie reviewing it on YouTube
...this is why we have multitasking OSes. You can download your favorite game using wget (or that GOG command-line downloader or whatever) while watching PewDiePie reviewing it via VLC.
16 comments
[ 3.3 ms ] story [ 43.8 ms ] threadBut my post is just a sign at the state of things, that's all.
Considering you don't have to do any of this on a native app (VLC) and just automatically get all the performance improvements, this has everything to do with web app vs. native
This is why WebGL hasn't really taken off for gaming.
You can have the perfect game running on 60 FPS on your system, then random dude tries to play the game, and browser decides it is blacklisted, goes back into software rendering and everything is choppy.
Meanwhile he/she doesn't have any issue playing native games and wonders why the browser game doesn't cut it.
The second thing were the CPU/memory problems because all the code was in js.
> Meh, the first thing about the browser games is the load time. It's not like downloading a native game and reliably storing it.
What's the difference between native game on an SSD vs browser game on an SSD (web local storage)? (Ok, other than time taken compiling that js monster, unless webassembly is used.)
> The second thing were the CPU/memory problems because all the code was in js.
First of all, you can also use webassembly. Secondly, you can program js in ways that don't cause much memory bloat. Native arrays, etc. Especially when compiled from C/C++/Rust etc.
Of course browser games have significant handicap. But I don't see any reason for them not to eventually reach at least 50% performance compared to native. Maybe even more. For a lot of applications, that's more than enough.
1. Both VLC & Chrome are native apps. VLC defaults to SD resolution (you can check codec statistics during playback), while the YouTube web app adaptively streams the best quality your hardware and network can support.
2. VLC & chrome likely use the same decoder source code, especially for VP9. But video playback is just one component of Chrome. It has to do so much more, like run untrusted code from the internet, and Sandbox it all. And keep the 10 extensions loaded running while your video is playing (like an adblocker that skips YouTube ads)
3. While not the case in the instance, chrome also supports background tasks while your playback is in progress. Like downloading your favorite game while watching PewDiePie reviewing it on YouTube
4. Not to mention all the analytics Google is likely gathering and sending on your choice of video, what parts you skipped, ....
If anything, Chrome/Browser is likely to optimize the heck out of the playback/decoding pipeline because it needs to do so much more beyond just playback that VLC does
And the reason is basically what you wrote. However the point wasn't why it happens, but to focus on that it happens - ie. native apps matter because they are (or can be) faster.
BTW...
> While not the case in the instance, chrome also supports background tasks while your playback is in progress. Like downloading your favorite game while watching PewDiePie reviewing it on YouTube
...this is why we have multitasking OSes. You can download your favorite game using wget (or that GOG command-line downloader or whatever) while watching PewDiePie reviewing it via VLC.
Anyway, "number of features" has not to do with "native".
What sort of resources that Chrome has are you referring to?