4 ms·

> Sweet.. the "go fast" generation is thrilled. We're optimized for a single popular commercialized case! Yes, you should optimize for the 99% case. That is ba

> Sweet.. the "go fast" generation is thrilled. We're optimized for a single popular commercialized case! Yes, you should optimize for the 99% case. That is basic software engineering. > Whoops.. we're no longer optimal. I don't know what this means. X toolkits since GTK in 1998 have been drawing bitmaps to shared memory. The basic X 2D vector graphics primitives haven't been commonly used for, like, upwards of 20 years. > Which, X also has. So, we've gone completely full circle, and we're less capable for it. X doesn't have the synchronization features that necessitated Wayland. It's simply not the case that X can do everything that Wayland can do.

akira2501 3y ago
> Yes, you should optimize for the 99% case. That is basic software engineering. Without considering /why/ it's the 99% case? Even so, just turn this around, top tier games and "tear free" experiences on linux are the 1% case. Why should we rip up the whole graphics stack to chase a "year of linux on the desktop" that's probably never going to materialize? > I don't know what this means. I might have failed to follow that thread from the original post, but the author implies this is an issue with Wayland, not X. Then points out that a simple extension covers it, which ironically means, implementations are _not_ free to optimize for any particular case. > X doesn't have the synchronization features that necessitated Wayland. It's simply not the case that X can do everything that Wayland can do. Would that be "implicit sync" or "explicit sync?" Anyways, I'm not trying to show malice to any one project or the other or even express favoritism to one or the other, just trying to show that the authors criticism of X is far too strenuous to be useful and seems to be based in a particular and peculiar modern mindset.
sprash 3y ago
> Yes, you should optimize for the 99% case. That is basic software engineering. Wayland is optimized for car entertainment systems and digital signage. Is this your 99% case? > X toolkits since GTK in 1998 have been drawing bitmaps to shared memory. Not true. E.g. several Gtk2.x rendering backends utilized XRender to draw Buttons with gradients without a single bitmap in shared memory. > X doesn't have the synchronization features that necessitated Wayland. It's simply not the case that X can do everything that Wayland can do. The X11 extension "Present" does exactly the same as Wayland concerning "synchronization features". What exactly can Wayland do that X11 can't do?

akira2501 3y ago

> Yes, you should optimize for the 99% case. That is basic software engineering. Without considering /why/ it's the 99% case? Even so, just turn this around, top tier games and "tear free" experiences on linux are the 1% case. Why should we rip up the whole graphics stack to chase a "year of linux on the desktop" that's probably never going to materialize? > I don't know what this means. I might have failed to follow that thread from the original post, but the author implies this is an issue with Wayland, not X. Then points out that a simple extension covers it, which ironically means, implementations are _not_ free to optimize for any particular case. > X doesn't have the synchronization features that necessitated Wayland. It's simply not the case that X can do everything that Wayland can do. Would that be "implicit sync" or "explicit sync?" Anyways, I'm not trying to show malice to any one project or the other or even express favoritism to one or the other, just trying to show that the authors criticism of X is far too strenuous to be useful and seems to be based in a particular and peculiar modern mindset.

sprash 3y ago

> Yes, you should optimize for the 99% case. That is basic software engineering. Wayland is optimized for car entertainment systems and digital signage. Is this your 99% case? > X toolkits since GTK in 1998 have been drawing bitmaps to shared memory. Not true. E.g. several Gtk2.x rendering backends utilized XRender to draw Buttons with gradients without a single bitmap in shared memory. > X doesn't have the synchronization features that necessitated Wayland. It's simply not the case that X can do everything that Wayland can do. The X11 extension "Present" does exactly the same as Wayland concerning "synchronization features". What exactly can Wayland do that X11 can't do?