Announcement

Collapse
No announcement yet.

Surface Suspension Protocol Proposed For Wayland

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mppix
    replied
    Originally posted by dpeterc View Post
    FYI, X11 was released in October 1987, gained popularity in the nineties, so it is hardly a 70s design. Unix is 70s design. Now replace that, just because it is old design.
    We did replace Unix. It is called Linux.

    Leave a comment:


  • dpeterc
    replied
    Originally posted by rastersoft View Post
    You can have SHM extension to choose passing a picture using shared memory, but you can't remove passing a picture over the socket, even if today it's rarely used.
    Maybe you quickly googled some stuff, but since I specifically use those in my software, I know what I am talking about.
    Suppose you have rendered your image buffer in XImage, which you want to display in drawable (Window or Pixmap).
    If you don't have MIT-SHM extension you use XPutImage() instead of XShmPutImage(). So it goes over socket (if X server and client are on different machines) or over pipe, if on the same computer. That is the whole point of network transparency. Application does not deal with it. Low overhead and efficient.
    Application only uses MIT-SHM for faster display, if X client and server are on same computer and extension is present.
    Originally posted by rastersoft View Post
    You can work with Cairo or AAG or OpenGL to paint elements and paste pictures from client side, but you can't remove from the server the 80's style paint primitives like bresenham lines and circles...
    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.
    Modern toolkits have deteriorated to the level, where Line(x1,y1,x2,y2) is no longer equal to Line(x2,y2,x1,y1). Or drawing a line will miss a first point in some quadrants, but that is OK and not a bug worth fixing.

    https://forum.qt.io/topic/101825/lin...aw-correctly/2
    All effort goes into antialiased line drawing, but basic Bresenham from 1965 is beyond reach of today's programmers.
    https://en.wikipedia.org/wiki/Bresen...line_algorithm
    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.


    Leave a comment:


  • rastersoft
    replied
    Originally posted by dpeterc View Post
    You have never programmed an X11 program, did you?
    Nothing is baked in the base system. There is this function called XQueryExtension

    and the software can adapt to using the extension or not.
    There are a lot of things baked in the base system, like "a visible window is painted directly in the buffer". You can have the Composite and the Damage extensions that add a new way of painting windows, but you can't remove the original painting system because it is baked inside. Also, by default, you work without transparency/alpha channel. You can have XRender for adding alpha channel support, but you can't remove the old non-alpha channel painting. You can have SHM extension to choose passing a picture using shared memory, but you can't remove passing a picture over the socket, even if today it's rarely used. You can use your own font renderer to paint letters from the client side, but if you claim to support X11 you can't remove the server-side font support. You can work with Cairo or AAG or OpenGL to paint elements and paste pictures from client side, but you can't remove from the server the 80's style paint primitives like bresenham lines and circles...

    All those elements are barely, if ever, used today, but if you claim to speak X11, you must implement them.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by kiffmet View Post
    I.e. the protocol mandates that information going from one wl client to another has to go through the wl server and use a defined protocol. Just hacking around it by using dbus or something else is violating the spec. Hence you need a wayland clipboard copy and paste protocol extension… You want to place a tooltip in a non-awkward position on the screen? new protocol it is! Previewing minimized windows for things like alt+tab? New protocol! Non GLES OpenGL or Vulkan on Wayland? New protocol… Taking screenshots and screen capture… new protocol…
    Screenshots/screencapture being a new protocol is required to fix the security without implementing a full authentication system in Wayland what would basically be duplicating what dbus and polkit does anyhow. This would be duplication risking more faults.

    Originally posted by kiffmet View Post
    It is so anemic that It can't even properly account for physical monitor sizes (DPI) in single and multi monitor setups. Got a 1080p and a 1440p monitor, both at 24''? The 1440p is "larger" because it has more pixels. Good luck having the user hack around the protocol for fixing scaling while avoiding a net loss of usable screen surface and blurry Xwayland instances, which only fixes single monitor HiDPI use btw.
    Just mandate from GUI toolkits that window sizes have to be specified in mm or in multiples of some predefined physical length and let users set a per-screen DPI. Boom, problem solved, perfect multimonitor DPI scaling, w/o artifacts and it wouldn't even need a new protocol or refactoring, had it been thought of in the beginning.
    This is you have not read wayland. Wayland support the compositor asking the application to change the scale of what it providing. https://wayland-book.com/surfaces-in-depth/hidpi.html

    Xwayland due to being X11 you screwed you cannot ask a X11 application on the fly to change the scale its output at all. Even if you specified in mm the window side you still need the application to be able to provide different scaled versions of output to match the DPI of the screen not to be blury because like it or not screens are made up if pixels.

    DPI/scale factor means there is already a form of windows sizes in mm in place its inches but hey its in place.

    Real issue here with wayland how to handle window split between two or more screens. It was decide that you could not ask a application window for two or more copies of its output at the same time mostly because if it was a complex game or something you could run straight out of GPU time doing this so one monitor will be right and the other monitors will be scaled giving a percentage of blur in this case. This is in fact a trade off because of the limited processing power of GPUs. Yes the only way to correctly solve the 1080p and 1440p on the same size monitors at the same time with zero blur requires application to generate output twice and we just don't have the GPU power to reliably do this. The reality is no matter how good the compositor scales if its not a integer scale it will always add a percentage of higher blur then asking the application to reproduce the frame and the required scale the fact you cannot do that with X11 is a major weakness of X11. Yes wayland application can refuse to scale when asked as well this could be claimed as a weakness of wayland but again this can be that the game/application output rendering is already exceeding the GPU processing on hand at it current scale. Wayland limitations here really do align to how limited GPUs really are and we cannot have everything due to this limitation but wayland is less limiting than X11 in this department.

    Leave a comment:


  • dpeterc
    replied
    Originally posted by murraytony View Post
    Wayland was designed to be extended to add desired features to be implemented by compositors. This way extensions can be deprecated and removed when they are no longer needed and are only added when needed. The reason we are still seeing extensions added regularly is because Wayland compositors are still maturing. Baking functionality into the base system was a mistake X11 made, the designers chose not to repeat it.
    You have never programmed an X11 program, did you?
    Nothing is baked in the base system. There is this function called XQueryExtension

    and the software can adapt to using the extension or not. If you type
    xdpyinfo
    you get the list of extensions that the X11 server supports. It is quite normal for some extensions to be missing on older X11 servers. Software should work without it, providing its own functionality or suffer some performance/functionality penalty. But it should still work.
    If that is not the case, it is the fault of application programmer, not the bad design of X11.

    Extensions become "baked in" simply by being used. So people expect them for completeness of the implementation. Same thing, which happened on X11 will also happen on Wayland. If it will ever become as popular as X11.

    Leave a comment:


  • dpeterc
    replied
    Originally posted by Alexmitter View Post
    For Wayland, those were tings that extended it beyond the lean display protocol it was designed as.
    For X11, that were the dozens of extensions over the year making this 70s design train-wrack doing things you expect in the 2010s
    So you are saying X11 is a 70s design train-wrack, because it planned for extensions by design and has grown by extensions for 30+ years. In my book, that is good design.
    And Wayland is lean design, which had extensions forced onto it, because people expected the same functionality which they had on X11?
    Which is basic UI stuff like drag and drop, cut and paste, popups opening at the correct place, network transparency, multi-monitor support, screen recording...
    I wonder which other miracles will the fresh and lean 2020 design will bring us.

    FYI, X11 was released in October 1987, gained popularity in the nineties, so it is hardly a 70s design. Unix is 70s design. Now replace that, just because it is old design.

    Leave a comment:


  • Weasel
    replied
    LMFAO so what happened with the pseudo security bullshit? What happened with the privacy concerns?!?? Oh noes, knowing when a window/surface is completely occluded can be a privacy leak!!! Tragic!!!!

    Nuke this suggestion, it's against Wayland's idiocy.

    If this suggestion goes through, might as well allow absolute positioning to be a thing, so it can finally start looking like a semi-decent protocol. The bullshit reasons made up around Wayland's arbitrary limitations are laughable at this point. That's what happens when people value their ego more than logic I guess.

    Originally posted by kiffmet View Post
    Tl;dr core wayland is shit
    Amen.

    Leave a comment:


  • murraytony
    replied
    Wayland was designed to be extended to add desired features to be implemented by compositors. This way extensions can be deprecated and removed when they are no longer needed and are only added when needed. The reason we are still seeing extensions added regularly is because Wayland compositors are still maturing. Baking functionality into the base system was a mistake X11 made, the designers chose not to repeat it.
    Last edited by murraytony; 20 June 2021, 01:47 PM.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by timofonic View Post
    I think Vulkan evolves considerably faster than Wayland these days, but not in enough pace IMHO.

    Wayland needs a core implementation, massive but coherent and intelligent code sharing. I think something based on wlroots and keep progressing would be interesting to have, then remove code duplication between at least major WMs and DEs. Of course, maybe a better alternative may happen. But this madness of code duplications is a total and utter technological suicide.

    Vulkan should absorb OpenCL and other APIs, being the sane and best alternative to DirectX. SDL is just a ducktape and buggy alternative, not so serious. And evolve FAST too, a lot more than now.

    I agree modern desktop should kill OpenGL and go the Vulkan route, then contribute to make Vulkan the best and stronger standard.

    Current situation is a bad joke. A bunch of brave developers must propose alternatives and start a strong discussion about this.
    I agree that vulkan should absorb OpenCL functionality with caveats(like new syntax for example) but Wayland is fine as it is, the problem lie on the compositors and toolkits not Wayland and as long as they insist on supporting both X11 and Wayland forever, Wayland will get more and more extension and more and more libraries and more and more compositor because they are not migrating to Wayland but converting Wayland into X11 so they can keep using the old codebase as much as possible which is where the real issue is.

    Remember when you have to support several implementation you have to put a ceiling that matches the lowest common denominator that in this case is what little X11 supports compared to Wayland, so basically what you have now is not missing Wayland features(except very few extensions) but a layer to make Wayland into WX11 as much as possible

    Leave a comment:


  • timofonic
    replied
    I think Vulkan evolves considerably faster than Wayland these days, but not in enough pace IMHO.

    Wayland needs a core implementation, massive but coherent and intelligent code sharing. I think something based on wlroots and keep progressing would be interesting to have, then remove code duplication between at least major WMs and DEs. Of course, maybe a better alternative may happen. But this madness of code duplications is a total and utter technological suicide.

    Vulkan should absorb OpenCL and other APIs, being the sane and best alternative to DirectX. SDL is just a ducktape and buggy alternative, not so serious. And evolve FAST too, a lot more than now.

    I agree modern desktop should kill OpenGL and go the Vulkan route, then contribute to make Vulkan the best and stronger standard.

    Current situation is a bad joke. A bunch of brave developers must propose alternatives and start a strong discussion about this.

    Leave a comment:

Working...
X