It’s hard to tease out, but it sounds like you’re advocating for the state of the art drawing model of 1980 in 2019. I don’t think this is going to fly except for a very niche audience.
It's a completely unsubstantiative argument; its effect is to sweep under the rug any justification for the 'old way' of doing things.
For one very big thing, hardware accelerated rendering didn't exist in 1980.
Also, no one really cares about network support anymore, because it's simpler and better to just do a screen share.
I care about network support for GUI applications.
I don't think _whole screen_ shares are either simpler or better.
Give it a try and let us know.
Actually, some of us do make use of X11 network transparency on a regular basis. Running an X11 program on a remote CPU, but having its window appear on the screen of the machine I'm sitting in front of, is quite a useful feature. And one that I make use of quite regularly. And it is most definitely not the same as a 'screen share'.
> Is Wayland network transparent / does it support remote rendering?
> No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.
Note that the next two paragraphs do discuss how network transparency could be built, by clients, on top of Wayland.
So it depends on how you define "does wayland break X-forwarding":
If defined as Wayland, the new server, yes. Because network transparency is not built in to Wayland the new server.
If defined as Wayland, the ecosystem, well, there appear to be ways to do it by adding it back in.
ssh -X still works and wayland native is waypipe ssh (though one could probably wrap that into ssh -X to make it seamless).
[citation needed]
Let me guess, you live in a city?
On the other hand xlib toolkits like xathena widgets run blazingly fast even over modem style connections because all the drwaing happens server side and only a limited amount of drawing commands are transmitted over the network.
Then why the hell isn't it being used by GTK/Cairo nor Qt in production code. Oh yes, there are OpenGL(-ES) backends in both. But by far and large they're doing all their rendering on the CPU and then blit over to the graphics system. This is BTW the main reason for Wayland coming to be in the first place: The observation that the X server has been "reduced to a blitting engine" (if your world view is so narrow to cover only GTK and Qt).
And then they're draining the baby with the bathwater… Wayland is how old now, 9 to 10 years, and it's still far from usable for production. IF you compare that with X11, after 10 years it didn't have just a barely working server and some example application. It was a thriving ecosystem with multiple desktop environments, toolkits, loads of production applications and you could just run them all arbitrarily in the same environment.
Only last Friday I was working on a custom windowing library (something in the same vein as GLUT, SDL or GLFW, however with a focus on "desktop" programs with traditional GUIs instead of things like games) and whenever I start working with the Wayland side of things it turns into a severe headache. Wayland is an actively developer hostile (and I'd even wager to say user hostile, too) ecosystem. For example, because in Wayland there's no concept of windows, and whatever a window is, is left to the compositor, you can't even properly implement something like dockable windows. The best hack I could come up with was via the drag'n'drop mechanism that Wayland then does specify.
IMHO Wayland is a prime example for the sunken cost fallacy hitting hard.
I've used that feature every single day for the last 20 years.
Take for instance a big 3D game. It is much more bandwidth-efficient to compress the frames and send that over than to send the 3D models, textures and transformation matrices over the net. We still don't have PCIE Gen. 4 bandwidth for networking.
Okay, this is an extreme example. But most apps (just take Firefox as an example) send bitmaps over X forwarding anyways. I use Xpra for these, but waypipe should work a lot better, in theory (less round-trips, etc). Of course, it's better if the graphics toolkit is install at both ends and can render the stuff locally (which was the intent with X). AFAIK a few support that, I wonder if rdp doesn't specify something to negotiate its use on a per-client basis?
The GP was suggesting “without extensions”. Good luck with that.
(I also think modern fonts don't look nice; I want to use bitmap fonts on the screen!)
Also, on server implementations that support SCM_RIGHTS (the core protocol would have some way to check), it would be possible to pass a file descriptor opened with shm_open() to the client and share memory that way, if the client and server are on the same computer. In this way, direct rendering is more efficient than it is with the X11 core protocol.
I said a lot like the version 11 core protocol, not exactly like it; in what I am thinking there would still be many differences, although many things are similar (because I think much of it is good).
OK, I looked, and I think you are right; DRI is better. It would work with what my ideas are (and I think SCM_RIGHTS would be used for this purpose too). Handling resize though would just be you can continue to render a picture of the old size and it will be cropped (or if made larger, the X window background will be displayed in the part outside of the DRI picture), or else it may handle the resize event to close the DRI handle and open a new one with the new size if needed.
The protocol would still be independent of the implementation, though. But because DRI involves system-dependent features, this means that the use of DRI is not fully defined in the core protocol. However, that shouldn't be a problem.
Lots of people have ideas for an "X12" that turns out to be stuff already supported by the X11 protocol. Not enough people know about the true problems with X11, or have ever asked us Linux developers think about what needs fixing (hi, I'm a long-time Linux graphics contributor and co-wrote a large part of the Wayland spec). X11 extensions have not been a major problem in 25 years.
That is true, although many of them are messy in X11. One of these is that the protocol and implementation are tied together more than they should be (one of these problems is server configuration requests, which I think do not belong there). Some of my ideas are:
- Timestamps. The way timestamps work in X11 is messy. A better way is 64-bit timestamps with an unspecified rate; what is specified is that timestamps are monotonic; i.e. if any two requests/responses/events use timestamps, the later one is guaranteed to have a larger number as its timestamp. (However, timestamps might not always increase when the server is grabbed; this is implementation-dependent.)
- Font path configuration. This should not be part of the core protocol; it improperly exposes the directory structure and the font formats. (I do suggest a XSET extension, which is optional, and what settings they set and how are implementation-dependent; the "xset" command would pass its arguments (except -display) to the server, which returns the text which will be the response. This makes it completely general, but a separate specification would provide guidelines for consistency, although not strictly required.)
- Screen saver configuration. I would have the core protocol has only two things dealing with screen savers: the screen saver event, and the suppress screen saver flag in window attributes. If the suppress screen saver flag is set on any mapped window, then the server should suppress the screen saver. Other than that, how the screen saver is implemented (if at all) and what it does is implementation-dependent, and probably configurable by the user.
- Mouse cursor shapes. My proposition allows the server to substitute its own full colour cursor of arbitrary size and opacity (and maybe even animation) when a client requests a font-based cursor shape (either the standard X cursor font, or some others, depending on what the implementation supports), unless the user disables this feature. Whether or not this is implemented is implementation-dependent, and it is completely independent of the protocol. (Whether or not you get the same image as you would by loading the cursor font with EnableAntialiasing and rendering that character, is also implementation-dependent.) (Substituting cursor shapes is probably not a feature I would use (I like the standard monochrome cursors), but some users will like it, especially those with very high resolution displays.)
- Bells. The core bell request should instead be like XkbBell() (although none of its variants (such as XkbDeviceBell and XkbForceBell etc) are possible). The only thing the server is guaranteed to do is to send a bell event if any clients care; what else it might or might not do is implementation-dependent and would probaly be configurable by the user to some extend. (For example, it may be configurable to suppress the audible bell if the bell event is requested by any client.)
- Allow different screens to have their own keyboard, or to share. Same is true of the mouse, and there may even be more than one mouse per screen (this is to support touch-screens; I don't like touch screens, but some people like it). Clients that don't care can ignore the field which specifies which mouse the event is.
- Use only one endianness rather than two in the protocol, for simplicity. The first byte is "X"; this also enables the possibility (but not the requirement) that a server implementation might support both X11 and X12 clients using the same socket, since you can distinguish between them.
- Some additional standard mouse cursor shapes (in addition to the ones in X11). The cursor font and "Fixed" font are the two "highly recommended" fonts to include in the system. (Some of my suggested new standard cursor shapes include: XC_arrow_plus, XC_arrow_minus, XC_magnify, XC_magnify_plus, XC_magnify_minus, XC_chaos, XC_invisible, XC_stop, XC_no_smoking, XC_xterm_lazy)
- The -retro option should be the default.
> - Timestamps. The way timestamps work in X11 is messy.
Well, yeah. Distributed timekeeping is messy. Clients can already retrieve the server's timestamp and keep a rough approximation of what's going on (I wrote a server time estimator for GNOME/mutter). Not sure how you'd fix it. Wayland replaced timestamps with serials.
> - Font path configuration.
Are you familiar with XSETTINGS? It was supported for many years in the toolkits, and got basically no traction.
> - Screen saver configuration. I would have the core protocol has only two things dealing with screen savers: the screen saver event, and the suppress screen saver flag in window attributes.
If you want to propose this as a specification, you're more than welcome to do so -- some sort of EWMH hint like _NET_WM_INHIBIT_SUSPEND or similar. Write up a spec and mail it to wm-spec-list. But you'll probably be told about to use the existing screensaver inhibit spec instead:
https://specifications.freedesktop.org/idle-inhibit-spec/lat...
> - Mouse cursor shapes
A client can already arbitrarily get and set the cursor image for a given cursor name with the XFixes extension, including setting RGBA32 cursor images.
> - Allow different screens to have their own keyboard, or to share.
XInput 2 supports multi-seat just fine.
> - The -retro option should be the default.
Not sure why this requires a whole new protocol version, just compile your X server with it on by default, or configure your display manager to set it.
> A client can already arbitrarily get and set the cursor image for a given cursor name...
That is not what I am suggesting at all. My suggestion is: The client only specifies a monochrome cursor, possibly from a font; the server MAY substitute a (possibly animated) RGBA32 (or other colour type) image (for a font-based cursor) IF the user has enabled that feature in the server configuration file.
> Not sure why this requires a whole new protocol version...
Indeed, that is independent of the protocol. I just think it is more useful, is all.
This is especially true for modern displays which have some limited support for variable refresh rates.
Whenever I find myself reading about X11's history my conclusion is always that you guys are heroes. A small group of people keeping an ancient behemoth alive, dealing with plenty of legacy of the kind that drives people to quit jobs.
And when you finally decide you've had enough and go for a rewrite... people shit on you and everyone suddenly knows better.
Again: thank you!