It is either a type of rubberized material degrading or one piece of plastic in the group. Being a home-labber/gamer I have gone through a couple hundred mice easily. In addition to Logitech, I’ve had lots of stock MS/Dell/HP and even Sun mice. A few can get this condition with the materials. Often it will be a rubberized component, but sometimes it is a plastic part. Like the mouse wheel is a more common part that gets sticky, but the rest of the mouse is okay. Nothing happened other than it sat around for a long time. It could be that the last user had grubby fingers stained orange from cheetos whilst using that mouse and that lent somehow to the degradation. Hard to say. Plastic does degrade for sure and maybe our grubby mitts help?

I knew someone would blame me. Yeah the cheap ones are normal plastic and would never disintegrate. Kind of, again, like the other 28 mice I’ve used in my life. The expensive Logitech mice I bought are a rubberized plastic meant for comfort but they aren’t durable. Literally did nothing wrong or different but that sticky shit is the pits, so I won’t be buying anymore $180 mice. I hadn’t before these either.

You described exactly my issue but it took under 5 years. Maybe 3? I’ve used $10 much much longer with only occasional hiccups like resolution issues on certain mousepads

Yeah and unfortunately it’s going to get worse when AI agents are also always running in the background (which is inevitable, let’s be honest).

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.

“One time only”? In theory yes, in practice I don’t have anything else that needs those KDE dependencies. When I remove qbittorrent I can safely remove them. This is just a reality check that desktop GUI frameworks and package management are really not much better than Electron/html as lots of comments in this thread seem to suggest.