The Wayland Situation: Facts About X vs. Wayland

[cmr~]

I'll try to address the remoting issue as clearly as possible. Please correct me if I'm wrong at any point.

1. Saying "please draw this text here" is much more efficient than sending a rendered image of the text. Especially when scrolling.

2. Wayland (compositor)-level remoting can never do anything better than send images. Any optimizations still only work at rendered image level.

3. Having such efficient remoting built-in, thus available with all apps, is a great advantage for a platform.

4. X was originally designed like that, but due to limits ended up sending images.

Thus..

5. The proper course to keep this platform advantage would be to design a remotable protocol usable by modern apps.

6. Wayland people proposed remoting at a toolkit level, and image-level remoting at the Wayland level. As established above, image-level remoting is inefficient, and toolkit-level remoting would forgo the platform advantage, by only enabling efficient remoting for certain apps, not all.

--

This is the core issue.

What does "please draw this text here" mean. though? What font? Antialiasing? Kerning? It's not possible to have it display the same local and remote without embedding all of that information and using the same font rasterizers.

The only real option for fast and efficient remoting is toolkit level support, along the lines of the current web stack sending layout/presentation/behavior information and letting the client do all the heavy lifting, and just sending commands to the remote for processing.

But at that point, you've rearchitected the entire thing. "Image-level" remoting isn't bandwidth efficient, but it is the cleanest and easiest solution for a thin client. If you want a fat client, you have a lot more work to do to get bandwidth usage down.

[ultimA]

Ahh, since some of you are so caught up in the grammar, I'll add my own two cents to the topic (even if off-topic, sorry).

you don't put commas before "and" unless it's to end a subordinate clause or connect two different clauses.

That, when left alone, is false. Both having and not having a comma before "and" is valid, even in all the other cases. However, Europeans generally prefer the way you described it, while Americans tend to insert the comma every time. There are countless well-accepted style guides issued by a variety of societies and organizations, and they don't agree on the matter (not even on the same continent). For a more detailed discussion of the topic, plz google for "serial comma". Point is, whether a comma is unnecessary or not depends on whose recommendation you're following, so don't pick on them.

That aside, most suggested corrections to the original article are either obvious typos or just nitpicking based on frign's personal preference. IMHO only 4 are actual/real mistakes.

[curaga]

What does "please draw this text here" mean. though? What font? Antialiasing? Kerning? It's not possible to have it display the same local and remote without embedding all of that information and using the same font rasterizers.

To be defined in the hypothetical proper protocol. To provide for modern needs such as the ones you mentioned, it would need to include font info, yes.

However, displaying the same on both local and remote does not need to happen. The system the picture appears on is the one that matters, and the user sitting there should be able to override fonts, etc, as they wish.

The only real option for fast and efficient remoting is toolkit level support, along the lines of the current web stack sending layout/presentation/behavior information and letting the client do all the heavy lifting, and just sending commands to the remote for processing.

Points 3 and 6 - toolkit level does not suffice. I see no reason this couldn't be done on a level below the toolkit.

[daniels]

To be defined in the hypothetical proper protocol. To provide for modern needs such as the ones you mentioned, it would need to include font info, yes.

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.

However, displaying the same on both local and remote does not need to happen. The system the picture appears on is the one that matters, and the user sitting there should be able to override fonts, etc, as they wish.

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

Points 3 and 6 - toolkit level does not suffice. I see no reason this couldn't be done on a level below the toolkit.

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.

[cmr~]

To be defined in the hypothetical proper protocol. To provide for modern needs such as the ones you mentioned, it would need to include font info, yes.

However, displaying the same on both local and remote does not need to happen. The system the picture appears on is the one that matters, and the user sitting there should be able to override fonts, etc, as they wish.



Points 3 and 6 - toolkit level does not suffice. I see no reason this couldn't be done on a level below the toolkit.

This is how I imagine the heirarchy, maybe you're thinking something else:

Compositor
(Wayland protocol)
Toolkits
Application

You would insert a remoting thing that toolkits build upon for remotability, or something above toolkits that allows remoting?

The problem is that you need to know a lot of the semantics of an application for bandwidth-efficient remoting, and that is often known only by the application, and the toolkit to an extent. I agree that the solution isn't ideal, but I think that it isn't possible to have a nice, generic solution using anything but image-level remoting (be it VNC, RDP, or Spice)

[GreatEmerald]

That, when left alone, is false. Both having and not having a comma before "and" is valid, even in all the other cases. However, Europeans generally prefer the way you described it, while Americans tend to insert the comma every time. There are countless well-accepted style guides issued by a variety of societies and organizations, and they don't agree on the matter (not even on the same continent). For a more detailed discussion of the topic, plz google for "serial comma". Point is, whether a comma is unnecessary or not depends on whose recommendation you're following, so don't pick on them.

Yea, I thought it might be. I'm learning British English, though, so that's why my preference is no comma before and. But thanks for clearing that up.

To be defined in the hypothetical proper protocol. To provide for modern needs such as the ones you mentioned, it would need to include font info, yes.

Why? You are sending the rest of the window as an image, anyway. So sending one without any font, then sending the font, then sending all the information about how and what to do with the font, is much less efficient than to just send everything pre-rendered.

Now you could say that you should only send hints and no actual images, but then the receiving end might see something completely different from the sending end. Not to mention that the receiving end might not even have all the dependencies needed to show what the sending end is trying to tell it to show.

[GreatEmerald]

By the way, why is it called a "compositor", anyway, if it's actually a window manager? Aside from the fact that you require it to support compositing, that is.

[cmr~]

By the way, why is it called a "compositor", anyway, if it's actually a window manager? Aside from the fact that you require it to support compositing, that is.

It doesn't have to be a window manager, it could delegate that to something else. It also doesn't have to place windows on the screen. It composites multiple sources into one.

[dee.]

I think it's because "compositor" is a more generic term. A Wayland compositor doesn't have to be a window manager, it could also be a lower-level system compositor, or maybe a compositor in a system that doesn't have windowing at all (tablets/phones/etc).

(Also, guys, please stop with the comma fornication, we're here to talk about Wayland, not nitpick on grammar...)

[sireangelus]

...or harms performance/battery unless you really know what you are doing.
Have you by any chance kept your benchmark results for the various kernel configs?

no i didn't. but i assure you that my actual kernel config does a wonderful job on my laptop( once i disabled the infamous opengl stuff as compositor) both as a speed up and i gained some battery power surplus too.
Keep in mind that on battery the governor is swapped by tlp with powersave and 1,6ghz max(from 2,4ghz.)
this is the config in question: http://www.mediafire.com/download/fa...msungconfig394