Comment on The driver for my mouse occupies over 1 gb
Blackmist@feddit.uk 3 weeks agoI’m not 100% convinced that an emulation layer isn’t as heavy as a browser.
We had things like Java and QT, and none of it really took off. Apple is probably to blame here as well, for wanting everything to be native to iOS and ignoring the reality that developers don’t want to make five different versions of their software.
Buddahriffic@lemmy.world 3 weeks ago
It’s generally not as heavy because the layer is just reinterpreting API calls while the user code still runs natively. On a browser running JavaScript, it’s using an interpreter for every line of code. Depending on the specifics, it could be doing string processing for each operation, though it probably only does the string processing once and converts the code into something it can work with faster.
Like if you want to add two variables, a compiled program would do it in about 4 cpu instructions, assuming it needed to be loaded from memory and saved back to memory. Or maybe 7 if everything had a layer of indirection (eg pointers).
A scripting language needs to parse the statement (which alone will take on the order of dozens of cpu instructions, if not hundreds), then look up the variables in a map, which can be fast but not as fast as a memory load or two, then do the add, and store the result with another map lookup. Not to mention all of the type stuff being handled at run time, like figuring out what the variables are and what an add of those types even means, plus any necessary conversions. I understand that JavaScript can be compiled and that TypeScript is a thing, but the compiled code still needs to reproduce all of the same behaviour the scripting language does, so generic functions can still be more complex to handle calling and return conventions and making sure they work on all possible types that can be provided. And if they are using eval statements (or whatever it is to process dynamically generated code), then it’s back to string processing.
Plus the UI itself is all html and css, and the JavaScript interacts with it as such, limiting optimizations that would convert it into another format for faster processing. The GPU doesn’t render HTML and CSS directly; it all needs to be processed for each update.
For D3D to Vulkan, the GPU handles the repetitive work while any data that needs to be converted only needs to happen once per pass through the API (eg at load time).
That browser render stuff can all be done pretty quickly on today’s hardware, so it’s generally usable, but native stuff is still orders of magnitude faster and the way proton works is much closer to native than a browser.
Blackmist@feddit.uk 3 weeks ago
Going to be quite a bit heavier than that if you run it on a different CPU architecture though. And even if you’re not running on mobile, Apple still opened that can of worms a few years back. Linux too, I guess.
Honestly, I don’t mind HTML for a UI. It resizes nicely to fit a large number of devices. It looks pretty much the same no matter what you’re running it on. But it should just be that, a UI layer. Otherwise the solution you were looking for was a website, and not a dozen 500MB chunks of Chrome installed around my PC.