Surface Suspension Protocol Proposed For Wayland

[dpeterc]

And that's exactly all the point. Quoting your comment: "they are part of core protocol". THAT is the problem: there are a lot of elements of the core protocol that aren't used anymore and could have been discarded, except for the fact that they are in the core protocol. The fact that it happens that you use them still today doesn't make them more necessary or valuable.

If you don't use them, that does not mean that nobody uses them.
There is a lot of software, which would need to be modified in order to run without those drawing functions.
Anyone who proposes to remove them, should take on the burden of fixing the software.

https://searchcode.com/?q=XDrawLine

And what is the burden of having those functions? One megabyte? Two? The source is written, has been used for ages, and works fine.

If, as many on this forum claim, X11 is dead, so what is it to you? Just a shared library in XWayland which you will never load, since you don't need any of these obsolete X11 software.

And no, I didn't "googled that quickly". I wrote my own X11 window manager some time ago and worked with bare XCB several times. And I reaffirm that a lot of the core protocol in X11 is completely obsolete, and Wayland makes a lot of sense.

Lots of people try to make smart remarks about software design, but few have designed large systems, used by millions of people. Systems, which were apparently better than anything else at the time, so they were quickly adopted, and stood the test of time over several decades.

Of course Wayland it more modern, it would be tragic if it would not be. But it is obvious that it takes more time to get off the ground than X11. Simply because it does not offer much end user benefit, and breaks compatibility with everything.

And, BTW: first you state that you can manually check whether you can send a picture through shared memory and manually decide which path to use, and after that, you complain that removing bresenham lines makes your life more complex... when you have tons of libraries to paint bresenham lines, and choosing whether to use shared memory or the socket should be transparent to the programmer!!!!

Maybe you misunderstood my post. I was merely describing how plugins work in X11, and they are not baked in. I am not asking for a transparent shared memory to socket protocol, I am fine with it as it is.
What I am not fine with is removal of perfectly good core drawing functions from X11.
I have Qt toolkit which used X11 under Linux for drawing primitive, and it was working fine. Then they migrated to other rendering engines, which are much more advanced in many areas, but neglect the simple basics like drawing the line in the way the smart guys from the sixties figured it out. Qt is a monstrosity of which needs hundred megabytes of shared libraries for applications of medium complexity. And a couple of megabytes in X11 is a problem?
So we should rip out essential X11 functions in the name of efficiency (or lack of maintainer), but I should use a third library just to draw a line? S

Plus, if we return to design and complexity. X11 client calls the function XDrawLine, it gets stored in queue and sent to X Server. Total size? Maybe one Kb. X server even uses accelerated graphics, if available, so drawing it is very fast. This is what made X11 network transparency possible. If I draw a picture in client memory, using my own (or a library) line drawing functions, and then I have to transfer the buffer image to the graphics memory in X11 server. So I resort to software rendering. And I have to transfer tens of megaybtes from client to server on a high resolution screen. So removal of X11 drawing functions would force me to use slower and more memory intensive approaches.

[mppix]

For most practical purposes, Linux is a re-implemtation of Unix, it uses the same function calls with the same programming interface.
Application software can be "ported" with minimum changes, if any. And that is a good thing.
So it is hard to call Linux a replacement of Unix from the design point of view.

Well, unless you can show that Unix=Linux, Linux replaced Unix for all intends and purposes. If you don't believe me, you can just ask Sun, IBM, or just google it.

Second, afaik the UNIX certification bodies are defunct by now (or irrelevant). Even if you tried (and nobody even wants this), you cannot make Linux the new/updated 'Unix'. If you could and wanted, you would probably end up with BSD being the new 'Unix'.
So even if Linux started as a Unix-like, we are way past compatibility. For example, it is not realistic to port systemd to BSD (unless BSD adopts every single Linux 'dialect' needed to run it).

[mppix]

If, as many on this forum claim, X11 is dead, so what is it to you? Just a shared library in XWayland which you will never load, since you don't need any of these obsolete X11 software.

I'm not the poster, read this and think there is just a bunch of misunderstanding going on.
When people say 'X11' is dead, they mean that Xorg (the server) is dead. X11 will live on for foreseeable future as a compatibility layer. This is important for Linux because we already don't have that big of a software ecosystem. Realistically, the compatibility layer does not even need to be that high performance. As long as it does not crash all the time..
Separately as software and X11 expert, I am sure you understand that a display protocol can be obsolete while a software is not.

Lots of people try to make smart remarks about software design, but few have designed large systems, used by millions of people. Systems, which were apparently better than anything else at the time, so they were quickly adopted, and stood the test of time over several decades.

Yes and no. Good software can be adopted quickly if they are somewhat revolutionary or fill an obvious gap: Win95 for example. Arguably better software can be adopted much slower and through lots of non-obvious niches: Linux for example. So speed is not a good metric.
I would even argue that this point is mood because the success of wayland depends on the entire ecosystem to change: DE, software, and user adoption.

Of course Wayland it more modern, it would be tragic if it would not be. But it is obvious that it takes more time to get off the ground than X11. Simply because it does not offer much end user benefit, and breaks compatibility with everything.

Win, Apple, Linux introduced new display servers because the old ones were obsolete. All introduce compatibility layers that work well. From a user perspective nothing 'breaks'.

[oiaohm]

If you don't use them, that does not mean that nobody uses them.
There is a lot of software, which would need to be modified in order to run without those drawing functions.
Anyone who proposes to remove them, should take on the burden of fixing the software.

Long list possible future and historic broken programs in fact you have just made.
https://www.x.org/releases/X11R7.5/d...Segment.3.html

It does not perform joining at coincident endpoints

This is important. XDrawLine does not define an algorithm as long as X11 server draw a line. In fact its valid to be a pixel short at each end of a X11 XDrawLine so when you draw a box using the XDrawLine that none of the corners join up as this is valid to X11 standard. Or the line to be drawn with a directional algorithm and this is still valid,

If I draw a picture in client memory, using my own (or a library) line drawing functions, and then I have to transfer the buffer image to the graphics memory in X11 server.

This is true but you should know what line drawing algorithm you are dealing with.

So I resort to software rendering. And I have to transfer tens of megaybtes from client to server on a high resolution screen. So removal of X11 drawing functions would force me to use slower and more memory intensive approaches.

The reality here is the X11 2d drawing is bad because you really do have no control. Remote if you are need to do detailed correct drawing and attempting to save bandwidth you are better off using html and javascript controlled canvas at least this way you can control the drawing algorithm.
.
The reality is using XDrawLine is no safer than using gtk or qt built in draw line functions. Most people would not dream it so hard to draw the correct 2d line on the screen and the reason why it so hard is there is more than 1 method and each method is not 100 percent equal.

[rastersoft]

Lots of people try to make smart remarks about software design, but few have designed large systems, used by millions of people. Systems, which were apparently better than anything else at the time, so they were quickly adopted, and stood the test of time over several decades.

Of course Wayland it more modern, it would be tragic if it would not be. But it is obvious that it takes more time to get off the ground than X11. Simply because it does not offer much end user benefit, and breaks compatibility with everything.

In my opinion, the reason is that people expects Wayland to do everything what X11 does... and they want it NOW, when X11 needed 34 years to have all those things. (and don't get me wrong: it makes sense that people want everything that they already have).

Maybe you misunderstood my post. I was merely describing how plugins work in X11, and they are not baked in. I am not asking for a transparent shared memory to socket protocol, I am fine with it as it is.
What I am not fine with is removal of perfectly good core drawing functions from X11.

And I agree in that it is not possible to just "remove them", because, being part of the core protocol (like server-side font rendering and much more elements) that would mean a completely different protocol, not X11. What I mean is that having all those elements (and, again, I'm talking of more things than just "drawing primitives") in the core protocol, seeing it with "2021 eyes", was a design flaw in X11. But don't get me wrong: it is an understandable one, of course. In 1987 it made sense to do things that way (yes, I know that in those days some Unixes still lacked dynamic linking libraries, and it is important to also remember that X11 development started in 1984), so it is perfectly understandable to implement a lot of things in the core protocol. Even more: originally, the X server managed even a lot of hardware details, not only for graphics, but also for keyboards, mices and more. Over time, a lot of those functionalities were moved outside (like DRM/DRI, evdev and more), and even the rendering was moved outside, when compositing window managers were added to the list. The net result is that the X server is today, in words of the Wayland creators "just an IPC system, and a not very good one" (I can't find now the original site where I read it).

Anyway, as I already said, there are more things than "rendering lines". But I think that it's better if you just read (in case you haven't, of course) the reasons given by the Wayland developers; I think that they describe the reasons much better than me:

https://wayland.freedesktop.org/docs/html/ch01.html

and, if you have extra time:

https://wayland.freedesktop.org/faq.html

https://wayland.freedesktop.org/architecture.html