The Wayland Situation: Facts About X vs. Wayland

[plonoma]

Unlike X which had everything as its own window at first, Wayland supports 2 types of windows.
Top-level windows, which are essentially wrappers around multiple buffers.
And sub-surface windows, which is mainly targeted at video playback.

This sounds a bit strange.
Isn't it mean to say that sub-surface windows contain one buffer? Can't see that video playback is the only thing that has one buffer.
Also is it possible to nest Top-level windows?
In this case the name is misleading since it suggests you can't nest them.
(Composite or wrapper window would say better what it does)

Can somebody give a bit clearer explanation for what these two windows are and do?

[Ericg]

Yes, and I believe many of us also know that it stops the CPU from cooking itself (and the table. And our laps. and our groins...) till extra crispy when doing anything that lasts more than a couple of seconds

Yes, but thats where thermald steps in. Really this conversation is pointless anyway because thermald + the new intel P-State driver is the future for intel CPU clockspeed management. AMD needs their own solution though.

[xnor]

Why is there no info about the current state of wayland? How ready is it?

[sireangelus]

Yes, but thats where thermald steps in. Really this conversation is pointless anyway because thermald + the new intel P-State driver is the future for intel CPU clockspeed management. AMD needs their own solution though.

ok.. so let's say can i tell thermald to have a target temp? like, if i want a target temp of 48?max??

[renox]

Thanks Eric

Thanks Eric it is quite informative but 1) you're conflating both X protocol issues and X's implementation issues (and you listed many obsolete issues what's the point?), plus many X criticisms are in fact caused by the toolkits, for example their slowness to adapt XCB.
While showing X's many issues is interesting, what is more interesting is its main differences: X is (in theory) a server side rendering protocol with optionnal client-side renderng (DRI2, SHM extension), Wayland being pure client-side rendering can never be considered X12.
From what I remember the pure client side design of Wayland has only a few potential drawbacks:
- in remote rendering, scrolling text inside a window will be slower as Wayland doesn't have the equivalent of XRender font cache.
- given that it shift complexity to toolkits, there could be interoperability issue (especially at the beginning)
- and it will use drivers in new ways so same thing it could have drivers issue at the beginning

[curaga]

x11 tried this, it was called stsf. turned out that sending the information the client required to do layout to it, was more expensive than just sending the entire font. ouch.

So have fonts on the rendering client machine too. Nothing to send over beyond font name then.

yeah, clients don't ever need to know what they've rendered, and who needs pixel accuracy anyway. just make all your text-containing elements really really huge and hope that the text fits in. it probably will ...

Of course the system should only substitute compatible fonts if the one is not available. If the user insists on an incompatible font, then text not fitting is reasonable.

i don't think you've looked. it's a long way from 'this is literally possible i don't know why people didn't do this tsk tsk what fools' forum bravado, to actually making it happen. once you start on the latter, you generally realise that these same fools tried to make it happen and ran into various insurmountable problems.

nothing in wayland precludes a generic remote rendering protocol, and judging from the armchair developer crowd, it's both so trivial to implement and has such massive advantages, that i expect we'll see an implementation very shortly. unless all the hot air is just that.

You see, your crowd is the one trying to replace X. So it should be you covering the use cases. I'm perfectly happy with X, and moving to an inferior system has no appeal to me. So with this in mind, why should I waste my time fixing such a system?

It is not hot air. It is voicing concerns that the proposed replacement does not fully replace the system it's trying to.

The danger to me is that it actually gains traction, and as apps move to it, then I will lose the remotability of all apps. But right now, that danger is still 5y in the future.

PS: I noticed you didn't reply to any of the original points. Do I take this as you agree with the premise?

[curaga]

(Can't edit posts in Opera still)

Regarding the text not fitting argument, this already happens in native apps in all platforms. If you specify the font as something weird and do not ship it with your app, the font the system substitutes on the actual user's machine might have different characteristics.

[dan3]

Fewer spellnig mistakes would make the article more credible

Please fix the "its" vs. "it's" usage and other egregious spelling errors. It really makes the author looks like an amateurish teen and makes the article harder to follow.

(If you think I have a spelling problem in the title, you have another problem)

[GreatEmerald]

And that is really what a compositor does at its lowest level, it create a composite image out of a bunch of smaller images. It takes various images (the windows), manipulates them appropriately (for instance removing bits that are hidden below other bits), then combines them to form a larger image. This larger image is then displayed on the screen.

Sounds like a window manager to me. I suppose it could do less than a full window manager, and then a full window manager could plug into a compositor... but it also sounds quite roundabout. From what I can tell, window managers should already have the capabilities needed to be a compositor.

Of course the system should only substitute compatible fonts if the one is not available. If the user insists on an incompatible font, then text not fitting is reasonable.

And that's precisely what Wayland is trying to avoid. Again, why would you request a font without any guarantees that the other end has it available, if you could just render the text locally, with very minimal overhead?

[mjrauhal]

Multihead practicalities

Okay, so multiple displays are a client problem.

How's that work in practice; the client needs to know which parts to render on which screen and tell the compositor? Could a naive (and inefficient) client just render its window in its entirety anyway and tell the compositor to render the same buffer onto either display on the border area of the display and rely on clipping to get rid of the redundant parts? One presumes the problem would usually be mostly handled on toolkit/graphics library level? Is there yet any coordination specs or plans for such for the clients to agree on how the displays should be oriented so that the user can tell the system how they want their displays and expect most clients to act appropriately while dragging stuff over the border (if any) and all?

Thanks (and Wayland does look promising, so hope it works out).