Originally posted by Hibbelharry
View Post
> This depends on the used codec. There are currently many highly compressed videocodecs available, used on multiple bigger platforms, which won't playback nicely without huge cpu hits or failing on older systems. We still need more performance work here (=gpu acceleration)
That, I'm less sure we can agree on: I don't think you're ever going to get decent decode performance for anything more complex than HEVC without dedicated blocks. It's not browser developers that made h264 performant, it's having hardware support for the basic principles of it in commodity CPUs. We had (albeit generally pretty crappy) versions on ATI / nvidia cards long before that, but it wasn't really relevant to almost anybody. Modern IGP is much more capable now I suppose, and general enough that you could probably offload "enough" to get ... well, low-precision blocky versions for almost anything :P, but it's not going to be the browsers that make even that much happen: it'll be nvidia / ATI / Intel, or plugins built out of ffmpeg code. (Unless it "has to be" the browsers for DRM reasons). And again, we're already there: that's the old Atom CPUs I referenced, 1080p x265, and nothing to do with the browser. All they have to do is link to the damn thing. (Unless, again, DRM issues).
The "huge cpu hits" CAN'T really be magicked away on older systems: the grunt simply isn't there, and no amount of optimization will change that. As long as the browser isn't doing something Incredibly Stupid (tm) of course, in which case all bets are off anyway.
> Based on my explanations, I think you're wrong.
I like being wrong. I'm good at it. :P
TBH, I'm not convinced by some of your points - but you are, and that's enough. You're probably a more normal case than I am as well, so overall that's a bigger win.
> These matter, too. That's why mozilla invested in new anti tracking mechanisms, fixing memory leaks, and so on. They do all of that, in a balanced way.
Maybe. But the CTRL-Q bug, even if it only hits you once a year, costs you more time than all their optimisations over that same year combined save you. And it could trivially be fixed in a day. So it's fairly annoying that their "balanced way" is still more worried about "winning" BS benchmarks than actually fixing bugs. (And, c.f. the 2-line browser lockup script that we were reminded of this week, which they've ALSO been ignoring for over 2 years).
@starshipeleven - No Adblock, but yeah, I do use NoScript on most sites. That's probably a bigger factor for *perceived* performance than every browser change from the last 5+ years combined. And, running the browser in a VM cut down to 2GB this weekend, because my desktop is undergoing maintenance, Firefox basically exhausts the VM's RAM with only a dozen tabs open. Without NoScript, the garbage code of 50 trackers / Like buttons / etc per site would probably have cut that down to half that.
ADD> The reason I came back to this thread was because I had to boot the HTPC into W7 the other day, and while I was messing around there I ran a 1080p x264 clip for yuks. It takes *12%* of the CPU to play that, fullscreen. mpv takes about 20%. But Firefox, for just *720p* video? Well over 50%. And whatever the "Webrender" BS is supposed to be doing, it's "blocked by hardware/etc" on Linux FF on that machine, despite it clearly being fully capable of hardware decode and running the same Mesa stack as other machines where it IS available. So, I reiterate, the Firefox devs should be fixing their damn bugs first, instead of doing a shitty job of something that other people have already done much better that's readily available for them to just link to. Bah!
Leave a comment: