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

101–110 of 131 posts

Re: Facts about Wayland vs X

#101

Post by ralph »

rg3 wrote: post #91
colanderman wrote: post #74

What a load of bollocks. Let's tear this apart: > Versioning is handled per client, not per bind. So if your app supports one version of a given extension but your toolkit supports another, you can't predict which version of that extension you will get. Easy solution: open multiple connections. Resources can be shared between connections. (You missed the actual problem with X11 here, which is its current limit of 256…

Also, I don't understand the claim "between all of your displays you can only have 32,768 pixels". A 1920x1080 screen has over 2 million pixels (2073600 to be precise). Can anybody explain that part?

Coordinates in the X protocol are signed 16-bit so a screen can run from 0 to 32,767 along an edge. I agree though, the initial complaint is unclear and may be about something else.

Re: Facts about Wayland vs X

#102

Post by exDM69 »

jmhain wrote: post #65
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...

This is a bit misleading because the RPi X drivers aren't very good and the performance is awful.

This is not to say that Wayland isn't an improvement, but with the RPi drivers it doesn't take much.

Re: Facts about Wayland vs X

#103

Post by iso8859-1 »

SimHacker wrote: post #98
iso8859-1 wrote: post #93

Earlier quoted context omitted.

Why paste the link content here? Most people already read it, it's nothing new. I can go find 10 X quotes too, but a link should suffice. Quote pasting is no discussion.

I pasted just the part about ICCCM, because it directly addressed the point I was trying to make, and it doesn't have link anchors. I didn't assume everyone would want to wade through the entire document to get to the part about ICCCM. If most people already read all of that Unix-Haters chapter which I wrote in 1993, then that's news to me. Obviously the guy who repeatedly parroted the 20-some-year-old discredited "M…

No need to apologize, I was just genuinely curious. Considering you wrote it yourself, that makes it more of a discussion in my eyes. Bandwidth was never the issue. No hard feelings :)

Re: Facts about Wayland vs X

#104

Post by rg3 »

ralph wrote: post #101
rg3 wrote: post #91

Earlier quoted context omitted.

Also, I don't understand the claim "between all of your displays you can only have 32,768 pixels". A 1920x1080 screen has over 2 million pixels (2073600 to be precise). Can anybody explain that part?

Coordinates in the X protocol are signed 16-bit so a screen can run from 0 to 32,767 along an edge. I agree though, the initial complaint is unclear and may be about something else.

Thanks for clarifying. So the following complaint about DPI does not make sense, given that a 50 inches wide screen with a resolution of 600 pixels per inch has 32000 pixels.

Re: Facts about Wayland vs X

#105

Post by lazyjones »

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…

The X way of doing window updates became impractical with common graphics-heavy applications like web browsers. I could already feel this in the mid-90's when opening a browser window on a 19" NCD X-Terminal took several seconds over 10mbit/s Ethernet (noticeable because most other X client applications at that time used drawing primitives and appeared instantly).

For modern applications (graphics- and video-heavy), VNC/RFB seems like a much more suitable protocol, although I haven't really kept up with the latest X extensions that probably cover some of these applications.

Personally, I liked the X architecture more (despite X's inherent complexity) and expected it to become more popular with cloud-hosted applications etc., but as applications and GUI toolkits evolved in an unsuitable way (i.e. not using X's primitives), it's probably time to let go. Or to build a proper GUI toolkit first...

Re: Facts about Wayland vs X

#106

Post by makomk »

stass wrote: post #97

> “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. This is not true. X11 is network transparent, poorly designed toolkits like GTK are not. So essentially they are writing a new graphics server for Gnome/KDE. But those have never been good X11 citizens anyway.

Does anyone even use DRI-2 directly, rather than through Mesa/OpenGL (which can, as far as I can tell, fall back to AIGLX even if you're using DRI-2)?

Re: Facts about Wayland vs X

#107

Post by sp332 »

dietrichepp wrote: post #75
sp332 wrote: post #70

Earlier quoted context omitted.

Lossless encoding is important for text, especially sub-pixel antialiased test.

Can you back that up? In my experience, when I replay an H.264 screen capture, I can't tell the difference. I'd be happy to post PNG screenshots. Keep in mind that H.264 does not have to be 4:2:0, it can easily be 4:4:4.

It sounds cool, I would be very curious to try it!

Edit: If you're offering, I would like to see some screenshots. Also, what settings do you use for it?

Re: Facts about Wayland vs X

#108

Post by sp332 »

SimHacker wrote: post #85
colanderman wrote: post #74

What a load of bollocks. Let's tear this apart: > Versioning is handled per client, not per bind. So if your app supports one version of a given extension but your toolkit supports another, you can't predict which version of that extension you will get. Easy solution: open multiple connections. Resources can be shared between connections. (You missed the actual problem with X11 here, which is its current limit of 256…

""Mechanism, not policy" means the X11 core protocol leaves things like window managers and clipboard selection unspecified. (The ICCCM spec takes care of this.) This is sound design." XRotateProperties() XCirculateWindow() XRotateBuffers() XStoreBytes() XStoreBuffer() XFetchBytes() XFetchBuffer() and everything to do about window borders, including how they metastasized into the Shapes extension. http://www.art.net/…

Maybe moving away from X is really just a cover for moving away from ICCCM? :)

Re: Facts about Wayland vs X

#109

Post by colanderman »

SimHacker wrote: post #86
colanderman wrote: post #76

Earlier quoted context omitted.

And this is my primary issue with Wayland. I cannot fathom why anyone would think it's a sound design decision to bundle a hardware-independent component (the window manager) with a hardware-dependent component (the compositor). This hearkens back to the days of DOS video games – what fun it was to implement support for everyone's sound card! Instead now we'll get to support KMS, Quartz, whatever-the-heck *BSD uses,…

Just put a JavaScript (or whatever) interpreter in the window server, and program the window manager locally in that. Then you aren't fucked by synchronization issues. James Gosling did something like that with PostScript many years ago, an alternative to X11, which was then merged with X11, and it was called NeWS (and later X11/NeWS or OpenWindows): http://en.wikipedia.org/wiki/NeWS I've written several window manag…

I do like the idea of NeWS, but,

Then you aren't fucked by synchronization issues.

I don't know what you mean by this. The EWMH specifies policy for using the Sync extension to synchronize updates between the window manager and the clients.

Re: Facts about Wayland vs X

#110

Post by moomin »

SimHacker wrote: post #98
iso8859-1 wrote: post #93

Earlier quoted context omitted.

Why paste the link content here? Most people already read it, it's nothing new. I can go find 10 X quotes too, but a link should suffice. Quote pasting is no discussion.

I pasted just the part about ICCCM, because it directly addressed the point I was trying to make, and it doesn't have link anchors. I didn't assume everyone would want to wade through the entire document to get to the part about ICCCM. If most people already read all of that Unix-Haters chapter which I wrote in 1993, then that's news to me. Obviously the guy who repeatedly parroted the 20-some-year-old discredited "M…

I loved the Unix Hater's Handbook. Still have the book, still have the barf bag. Still think it's one of the best books on operating systems design ever written.

At least no-one tries to use csh anymore...

Post reply on HN