Surface Suspension Protocol Proposed For Wayland

[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

[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.

[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'.

[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).

[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.

[rastersoft]

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.

That's true and false at the same time: Linux has a lot of API calls unavailable in other UNIXes (like the BSD family), which means that software made to take advantage of those calls isn't portable into other UNIXes. In fact, that is one of the criticism for systemd (although systemd people is tired of noting that the interface in systemd is in DBus, but that's another history).

[dpeterc]

We did replace Unix. It is called Linux.

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.

[rastersoft]

You should not remove 80's style Bresenham style of paint primitives, they are part of core protocol, they are not extensions. So again, no toolkit baked in, it is just base protocol. And why would you want to remove them? They are small and efficiently coded. They come from the Donald Knuth era, when programmers actually could do math and develop a sane algorithm.

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.

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.

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!!!!

Bravo!

[oiaohm]

So I am supposed to use a fancy multiplatform Qt tooklit, so software will easily port to Windows, Mac, Linux with X11 backend rendering or Wayland rendering, but if I want to draw a mathematically correct line, I need to code my own version of Bresenham line, circle and curve algorithm. Thank you for simplifying my life.

Bad news
https://forum.qt.io/topic/101825/lin...aw-correctly/2
The lines here are mathematically correct.

https://en.wikipedia.org/wiki/Line_drawing_algorithm

Problem is they are not the algorithm you want. That effect with the lines is what happens when you use "naive algorithm" or "digital differential analyzer (DDA)" or "Gupta Sproull's algorithm" as all these are in fact directionally drawn.

Lot of cases you want Xiaolin Wu's line algorithm because it normally looks better than Bresenham line algorithm. Yes Xiaolin Wu is also directionally drawn but does not show the defect as much and looks generally due to how it works.

Its been a on going annoyance for me that toolkits give you a line draw command with no way to set the drawing algorithm. Yes there is 5 common ways to draw a line on the screen all giving slightly different results all technically mathematically correct lines. Its like the same way you have 3 different common averages in maths.

Sorry just because a toolkit is not using the algorithm for line you expect does not mean what it doing is mathematically incorrect.

There is a fun issue here off loading line drawing to the gpu is part of the problem here remember when gpus did not have any integer processing turns Bresenham is not designed to work in floating point. Also horrible is we don't have Xiaolin Wu's common used because it was created in 1991 and when a lot of toolkits started this was not 20 years old yet so they avoid it in case of patents.

There has been a need for a new Bresenham set of formulars that are properly floating point compatible.

Another fact there is a difference between a line drawing like Bresenham that is designed to remain balanced around the centre point and a line that designed that if you extend it that you don't have to move the prior placed pixels. Yes start one end go to the other is the second type and results 1 pixel by self at end of lines this is effect you want if you want to be able to extend line without moving points.

So depending on the line you are attempting to draw alters what line drawing algorithm you want.

[mppix]

Small correction, Wayland core was always functional like Vulkan, the issue you refer is not actually Wayland missed design or anything of the like but desktops environments wanting to make it behave like X11 so they can support both easier to avoid backlashes after the fact.

See it this way, Instead of going the Apple way and focus and redesign the desktops to use Wayland, everyone went the Linux way and suddenly decided Wayland had to support all of X11(as possible) as well because you know, we have to support everything forever.

It all comes down to application support. Apple provide XQuartz when they went Metal, Linux DEs implemented Xwayland when they went Wayland. I don't see the difference.
DEs that don't support wayland will slowly die because even X11 updates are now confined to Xwayland and Xorg is essentially done..

Same thing happens with compositors, instead of going full Modern C++/ Wayland / Vulkan and exploit thousand of new ways of handling desktop rendering, low latency, efficient hardware usage, etc. they are focused on OpenGL 3 still because some moron with a 20 year old GPU will cry murder in a forum because he is too cool to use a Centos derivative and too cheap to get even an used decent GPU. Hence we now have to deal with a Frankenstein that kinda works like on X11 but has bugs and kinda runs on Wayland but is not that much better than X11 but with different bugs because the 20+ years codebase they are using is full of hacks and half broken and was designed before threads were a thing but Hey, Linux support everything!!! so be happy

You are describing a interesting future direction. However, Vulkan was not an option when people started to implement Wayland compositors.
As of a year ago, it is possible in theory to implement a Wayland on Vulkan DE but there is not even a proof-of-concept out there. Also, I don't know how many Vulkan drivers implement the necessary Vulkan extensions. So it is essentially a research project.

Re: Linux supports everything, I don't actually understand the point. Yes, there is Xwayland but does not impact Wayland. Any app developer can switch to wayland as their apps get ready. So if an app does run in Xwayland, it is more on the app developers, not the compositor.
That being said, not having Xwayland would have killed Wayland altogether. No DE could make it the default because the apps did not support it and no apps would support it because it had no adoption.. Apple (and MS) always provides compatibility layers when they make big switches, e.g. XQuartz, rosetta, etc..