Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facts about Wayland vs X

phoronix.com

Post reply on HN
Print view View original

61–70 of 131 posts

Re: Facts about Wayland vs X

#61

Post by belorn »

cbs wrote: post #37
belorn wrote: post #32

One key feature of X that Wayland refuses to implement is the concept of remote access. Everything is intended to be local only. For those "strange" users out there who want remote access, the developers replies has so far been to use VNC. Its kind of odd that remote access has been shoved to the side in this age of cloudiness and always connectedness. One would think that there existed better methods to remote acces…

From what I understand, modern X applications run remotely are just painting a region of bytes to be shot over the wire anyway. I'll borrow X terminology for a second here, what functional difference is there between these two approaches: X client -> (network) -> X server Wayland "client" -> wayland intermediary "server" -> (network) -> wayland intermediary "client" - wayland server I get the feeling that the pushbac…

> From what I understand, modern X applications run remotely are just painting a region of bytes to be shot over the wire anyway.

No, that's incorrect. X server sends high level commands over the network and let the client render the requests. VNC on other hand work exactly as you describe, by simply copying the servers image buffer (a region of bytes), compresses it, and sends it over to be painted on the client's screen.

My general approval of X method rather then the VNC approach mostly comes down to performance (less traffic, smother rendering) and style. Its the same reason why I like the concepts of vector graphic over pixel formats.

But if Wayland is designed to not have any high level commands (like "create a window"), and thus only push buffers of pixels between server and client, I guess that is that then. Anything beyond copying the image buffer would then be in conflict with Waylands core design.

Re: Facts about Wayland vs X

#62

Post by derleth »

smalltalk wrote: post #43
tome wrote: post #33

Earlier quoted context omitted.

Cool link, thanks! What do you mean "regret it"? It didn't work properly/performantly?

Performant is not an adjective. Performantly is not an adverb. Niether is a word. Use real words when you write. Maybe write, "It didn't work properly / perform adequately," instead of writing nonsense.

> Niether is a word. Use real words when you write.

Aside from the glaring spelling error, this betrays a complete linguistic ignorance coupled with utter historical illiteracy. In short: Every new word, or semantic shift applied to an existing word, was railed against, often by people with no knowledge of linguistics, and many have since become productive parts of our language down to the present day. Some haven't, admittedly, but not because of the people who ranted against them.

For example, is 'television' a word? Can 'nice' be used to mean 'pleasant'? Can 'actor' be applied to a woman? Can a house made of wood ever become 'dilapidated'? (Seriously.)

If you're seriously opposed to 'non-words', the answer to all of those questions is NO.

Re: Facts about Wayland vs X

#63

Post by Tuna-Fish »

wmf wrote: post #58
Tuna-Fish wrote: post #54

Earlier quoted context omitted.

In Wayland architecture, the window manager is the display server. To provide wayland-XMonad, you don't need Haskell bindings, you need an implementation of the protocol in Haskell. This isn't as horrible as it sounds, because unlike X, the display server in Wayland is pretty tiny. The current implementation is like ~10k lines. I expect it to fit in sub 3k lines of Haskell. :)

Realistically I would expect people to reuse as much Weston code as they can.

The only part that's big enough and self-contained enough to be worth reusing in a Haskell project would probably be the cursor handling. For all the rest, writing the wrappers necessary to deal with them from Haskell would probably be a bigger job than just re-implementing.

The whole point of Wayland/Weston is that the display server is miniscule. All the complex parts are reimplemented in other parts of the stack already, so just let them deal with them and hand over pointers. It's so small that if there ever is a Haskell version of it, I expect it to be formally proven to be bug-free.

Re: Facts about Wayland vs X

#64

Post by bbanyc »

vardump wrote: post #19

Wayland is a critical technology for Linux desktop community. X11 has been a reliable workhorse, but its time is up - simply too much cruft accumulated over the years that's not even used anymore. Yet all of it needs to be continually supported, adding to complexity. No one uses X11 primitives for drawing apart from bitmap functionality - even repainting dirty regions (expose events) often involves sending over a new…

Can't toolkits use XRender over a network instead of sending huge bitmaps around? Or was XRender support dropped altogether when DRI2 proved so much better?

Re: Facts about Wayland vs X

#65

Post by jmhain »

toyg wrote: post #51

My issue with Wayland is that it risks being another KDE 4.0 (or another PulseAudio): the hype-machine was started too early in its development cycle and this is creating expectations that are then frustrated in practice. If you're trying to switch people en masse from such an entrenched technology, you must have a killer app ready from day 1. Is there an app that directly benefits from Wayland so much that it will e…

Check out this video of what Wayland can do with the Raspberry Pi GPU. People have tried and failed to get the same performance with X.

https://www.youtube.com/watch?feature=player_embedded&v=0UkU...

Re: Facts about Wayland vs X

#66

Post by andolanra »

belorn wrote: post #32

One key feature of X that Wayland refuses to implement is the concept of remote access. Everything is intended to be local only. For those "strange" users out there who want remote access, the developers replies has so far been to use VNC. Its kind of odd that remote access has been shoved to the side in this age of cloudiness and always connectedness. One would think that there existed better methods to remote acces…

From page 3, "Some Misconceptions about X and Wayland":

    II) “X is Network Transparent.” Wrong. Its not. Core X and DRI-1 were
    network transparent. No one uses either one. Shared-Memory, DRI-2 and
    DRI-3000 are NOT network transparent, they do NOT work over the
    network. Modern day X comes down to synchronous, poorly done VNC. If
    it was poorly done, async, VNC then maybe we could make it work. But
    its not. Xlib is synchronous (and the movement to XCB is a slow one)
    which makes networking a NIGHTMARE.
And later:

    V) “Wayland can't do remoting.” Wrong. Wayland should be BETTER than X
    at remoting, partially do  its [sic] asynchronous-by-design nature. Wayland
    remoting will probably look a like a higher-performance version of
    VNC, a prototype already exists. And this is without us even giving it
    serious thought about how to make it better. We could probably do
    better if we tried.
So, Wayland will implement remoting in a way similar to VNC, which will be an improvement over the current state of things in X anyway.

Re: Facts about Wayland vs X

#67

Post by fmoralesc »

belorn wrote: post #61
cbs wrote: post #37

Earlier quoted context omitted.

From what I understand, modern X applications run remotely are just painting a region of bytes to be shot over the wire anyway. I'll borrow X terminology for a second here, what functional difference is there between these two approaches: X client -> (network) -> X server Wayland "client" -> wayland intermediary "server" -> (network) -> wayland intermediary "client" - wayland server I get the feeling that the pushbac…

> From what I understand, modern X applications run remotely are just painting a region of bytes to be shot over the wire anyway. No, that's incorrect. X server sends high level commands over the network and let the client render the requests. VNC on other hand work exactly as you describe, by simply copying the servers image buffer (a region of bytes), compresses it, and sends it over to be painted on the client's s…

> X server sends high level commands over the network and let the client render the requests.

AFAIK, that's not true most of the time nowadays, since most toolkits don't use X drawing primitives.

Re: Facts about Wayland vs X

#68

Post by thristian »

dlitz wrote: post #9

Some more facts about Wayland and client-side window decorations, quoted from here: http://blog.martin-graesslin.com/blog/2013/02/client-side-wi... - Nothing in Wayland requires them - QtWayland allows Clients to turn them off - KWin as a Wayland compositor will use server side decorations

Huzzah! That was pretty much my single biggest disappointment with Wayland. Although I like the visual consistency of server-side decorations, one of my favourite things about X11 is that when an app hangs or otherwise does something weird, the close button in the title-bar still gives me control over the app, I don't have to hope that it's still processing its event loop or bust out some arcane interface like Task Manager and guess what the application's executable is named.

Re: Facts about Wayland vs X

#69

Post by nitrogen »

jlgreco wrote: post #11
dlitz wrote: post #9

Some more facts about Wayland and client-side window decorations, quoted from here: http://blog.martin-graesslin.com/blog/2013/02/client-side-wi... - Nothing in Wayland requires them - QtWayland allows Clients to turn them off - KWin as a Wayland compositor will use server side decorations

> "No aliasing when rotating/wobbling windows" Has anyone ever used those things for more than a single day? I honestly thought the current compositing window managers don't even support that novelty stuff anymore.

I use wobbling windows because it makes my interaction with the system seem more transparent. Rigid windows feel unnatural, but wobbly windows let me become absorbed by my task.

Re: Facts about Wayland vs X

#70

Post by sp332 »

dietrichepp wrote: post #48
wmf wrote: post #25

Earlier quoted context omitted.

krh is working on a lossless "codec" that uses a rsync-like rolling hash that should provide good compression with no artifacts (as long as the app isn't too skeuy). http://people.freedesktop.org/~krh/rolling-hash&#x2F ;

...but why? In my experience, using H.264 to encode screen captures gives you extremely high quality video for reasonable CPU and network expenditures. Is the last 1% of video quality really worth it? For a demo, you can try using FFmpeg + x264 using the x11grab input. It's very easy to adjust the amount of CPU used (by changing the preset) and the bandwidth (by changing the CRF, or by setting the bit rate).

Lossless encoding is important for text, especially sub-pixel antialiased test.
Post reply on HN