• 1 Post
  • 39 Comments
Joined 1 month ago
cake
Cake day: August 22nd, 2024

help-circle


  • I’m a flutter dev, and I’ve seen testimonies from a former Windows 98 dev about limiting the number of redraws in the shell.

    There’s deffo extra overhead, but it’s not linear - 4k being 4 times as many pixels as 1080p doesn’t mean 4k the work to render after the first frame, as the browser/framework will cache certain layout elements.

    The initial layout is still expensive, though, so big tables will take longer, but that big table at high Res will probably be less chuggy when scrolling once loaded.










  • I like the approach here, but the requirements are a little vague and prone to bikeshedding. Stuff like “could this be used by multiple clients” might mean a protocol is held in limbo whilst it’s given extra scope for example.

    It’ll need some strong moderation which might rub people the wrong way, but if this keeps Wayland’s cutting edge moving whilst the official solutions are found, I’m all for it.


  • Wayland’s approach has always been to make 3rd party protocols easier to opt in and out of. Sway and Hyprland both used custom protocols whilst official solutions were being designed iirc. Nothing stopping anyone from switching from one protocol to another if they implement the same thing down the line.

    At least this way, compositors may be able to use something like frog as a shared “experimental branch” which can be enabled for users who need them, but otherwise disabled whilst Wayland core isn’t pressured to work faster.

    It’s up to Wayland to make these projects obsolete if it causes them or users a problem.





  • I think (aka speculate) that the fact that Windows is the largest OS plays into the fact that Linux-Mac compatibility isn’t more developed.

    I bet some 90% of desktop software is available on Windows (even many core KDE are on Windows!) so targeting them brings most Apple apps onto Linux “for free”. Especially since Apple’s insistence on trying to make Metal a thing hurts gaming support, which is a big driver behind Linux compatibility development.

    The few applications that MacOS has over both Linux and Windows are usually so embedded into the Apple ecosystem that you’re not getting much by porting them anyway. iTunes? The App Store? Garage Band? Probably doesn’t help that many of those apps also use Apple’s own UI framework which isn’t really portable.

    However, stuff not designed to live in Apple land like Teams for Mac or Adobe CC might be more possible. But still far too few applications to necessitate the effort to bring them over.


  • Pop is the only one that really ever makes any reference to windows in its marketing. I’m more talking about distros like Zorin which are targeting public sector orgs and windows users by bundling windows compatibility apps and features into the ISO.

    The other examples definitely do also target “new users” which of course means Windows users too, but they aren’t explicitly tying their distros to Windows software compatibility the same way some are.




  • MacOS still ships x86 builds, and most software either provides binaries for both platforms or some kind of universal/hybrid binary. Still a few years before that becomes an issue.

    At some point an ARM->x86 translation layer is going to be needed too, regardless. It’s not long until ARM becomes popular enough to make it necessary to translate both ways.