121–130 of 250 posts
Earlier quoted context omitted.
Have you tried playing a video? Or moving a window around fast? Without a compositor there will be tearing on X. With a compositor, X is just a useless middleman.
There's nothing stopping an X server implementation from doing compositing natively.
Earlier quoted context omitted.
ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.
The first ARM dates to 1985. I don't know if there was ever an X11 server for Acorn RISC-OS, but there were for similar era Amiga's. But that misses the point, which was that current era ARM chips are orders of magnitude faster than the old 68k family Unix terminals and 486's I ran X on through much of the 90's. You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower,…
Earlier quoted context omitted.
There's nothing stopping an X server implementation from doing compositing natively.
Other than writing an X server implementation is akin to writing a web browser from scratch?
You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done. It's nothing like matching a modern browser. Incidentally, if I were to try to do this today, I'd gut a proxy like Xephyr and make it rootless to support older clients, and make the main server itself only support the subset of the X protocol modern clients speak.
Earlier quoted context omitted.
> Xorg is an amazing piece of software Based on what? Because I rather believe its maintainers..
Maybe you didn't read my comment? Based on having used it for over 20 years.
Earlier quoted context omitted.
Do you have a link to a bug report? I tried digging around a bit as I got curious how bugs like these would manifest, but could not find anything good to link. What I am aware of is that Java application can break without workarounds (saw it in the documentation somewhere) and that Steam needs an explicit workaround [1]. [1]: https://dwm.suckless.org/patches/steam
All java applications refuse to render without said workaround, because AWT expects the WM to reparent its windows. This is IMO a bug in the JRE, because there is no requirement for the WM to reparent. I use steam on dwm without the steam patch, haven't noticed an issue so far.
IIRC the issue with AWT and non-reparenting WMs is mostly limited to popup (ie. override-redirect) windows that are positioned in relation to some kind of owner window (which means menus, tooltip popups...). AWT simply expectes that parent window of its window to be the frame window of reparenting WM and calulates the position in respect to that, if there isn't the frame window the position of the popup inside root window will be calculated as if the root window was the frame, which can result in anything from the position being slightly wrong (eg. shifted down by the height of awesome's "menu" bar) to the window being completely off-screen.
Slightly orthogonal to this: is there a good tutorial on writing your own simple Xserver?
Last time I checked it was work in progress and I'm not sure how complete it is at this moment, but it includes understandable explanations of the low-level algorithms and acceleration structures involved.
Edit: this shows how X works from the lazout and graphical side. One interesting thing that is not covered by this is the somewhat peculiar wire format of X11 connection (it was obviously designed by someone with LISP background).
Earlier quoted context omitted.
It is relatively easy to write an X based window manager that is actually usable. So the article could not exist in a Wayland context ... and it is not at all clear what framework will make Wayland usable in such a simple and straightforward way or if one is even possible.
Wlroots would like a word with you.
* http://inclem.net/2021/04/17/wayland/writing_a_wayland_compo...
Earlier quoted context omitted.
> There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old. This has been going on for at least 15 years now. I've been through multiple cycles like this with different desktop environments and GUI toolkits. The churn is even much greater in the Javascript world where if you come back to a project you haven't look at in about 3 months, the first…
Or just try to go at things with an open-mind and hell, you might learn something? X comes from a time when GPUs were not even a thing, it’s current role on a typical desktop is basically just to be a middleman in the communication of applications and the compositor. Wayland cuts out this middleman, fixes unfixable problems in X (you can’t have displays with different DPIs), and is backwards compatible through XWayla…
There's an implicit assumption here, that one is even using a compositing window manager. I'm guessing that you do, and that's cool -- you do you! But there are lots of people, who, when sitting down at a fresh install of any operating system, start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well.
The first thing I do on Android is disable all the useless (imho) animations and effects, the same on Windows (back when I used Windows), and on Debian, where I have real control, the last time I saw a compositing window manager was I think 2006. I remarked "Ok. I guess this is for people who want their Linux to look like a Mac" and then promptly removed it. I have nothing against people wanting eye candy! Eye candy sells! But... don't pretend that it's a necessary, or even important feature.
> you can’t have displays with different DPIs
This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy.
What I think you mean is "Wayland supports point based instead of pixel based rendering", or "Wayland does image resampling for you, making it easier for people who don't want to use native resolution" (I don't know Wayland internals).
Anyway, I think this whole comment thread is both educational and disturbing. :/ There appears to be two camps, both of which are incorrectly assuming that everyone else thinks like them. I'm guilty of this as well. Other than the comment about security, and use on embedded environments, all of the "features" that Wayland offers (according to these comments) are, from my perspective, things I would turn off because they'd get in the way.
And I will follow your suggestion, and sometime soon set up a VM, and try to install Wayland and whatever the current whiz bang desktop environment is.
Earlier quoted context omitted.
Maybe you didn't read my comment? Based on having used it for over 20 years.
That’s something about its stability. It says nothing about its fundamentally bad abstraction of modern graphics stacks, that can’t be fixed.
Earlier quoted context omitted.
> There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old. This has been going on for at least 15 years now. I've been through multiple cycles like this with different desktop environments and GUI toolkits. The churn is even much greater in the Javascript world where if you come back to a project you haven't look at in about 3 months, the first…
Or just try to go at things with an open-mind and hell, you might learn something? X comes from a time when GPUs were not even a thing, it’s current role on a typical desktop is basically just to be a middleman in the communication of applications and the compositor. Wayland cuts out this middleman, fixes unfixable problems in X (you can’t have displays with different DPIs), and is backwards compatible through XWayla…