The Wayland Situation: Facts About X vs. Wayland

[TheBlackCat]

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.

You still haven't explained why sending the fonts and the image is better than sending just the image. Sending the fonts and the image requires more data than just sending the image. Plus it has a lot of additional problems.

And you also haven't explained why a feature that isn't actually used anymore is so important.

[b3nn0]

That looks a BIT like apple's automator. IMHO, automator might be the very best feature on osx, and is something I've long wanted to see on linux.

AFAIK, Automator is quite different. Automator is a lot more 'contex aware', i.e. you can tell automator to "rename those files" or something like that.
Robotux is only a simple keyboard/mouse input recorder and can then replay the recorded input (with a few simple customizations such as replay speed, etc). It is not context-aware at all.

[GreatEmerald]

No, a window manager manages windows. A compositor manages images. Windows are not images, and images are not windows. Traditional window managers are not compositors and have none of what is needed to be a compositor, since they have no capability to combine different images. The actual rendering of the completed windows and the full desktop was handled by X11, the window manager just made sure the windows were in the right place and handled their decorations.

kwin, for example, includes separate window management and compositor components, and the two can be run independently (for example you can run kwin with compiz as its compositor).

A specific example may be helpful: Let's say you have firefox open. What size is the firefox window? What is its shape? Is it minimized? These are all things that are decided by the window manager. This information is then handed firefox, which uses it to decide what sort of image it will render (if any). This image is then handed to the compositor, which combines it with other images provided by other windows. The compositor then combines these images together to create one big image. This is then handed to the hardware to display. As you can see, these are completely different tasks, and there is no reason one program needs to, or even should, handle both.

Ah, I see. It makes sense, then.

[valeriodean]

A specific example may be helpful: Let's say you have firefox open. What size is the firefox window? What is its shape? Is it minimized? These are all things that are decided by the window manager. This information is then handed firefox, which uses it to decide what sort of image it will render (if any). This image is then handed to the compositor, which combines it with other images provided by other windows. The compositor then combines these images together to create one big image. This is then handed to the hardware to display. As you can see, these are completely different tasks, and there is no reason one program needs to, or even should, handle both.

Why?
The kernel handle a lot of different things.
There is a lot of reason why one program should to handle both these task, those days.
If the tasks that you try to manage are strictly correlated then can be a better idea put all under the same umbrella.

[TheBlackCat]

Why?
The kernel handle a lot of different things.
There is a lot of reason why one program should to handle both these task, those days.
If the tasks that you try to manage are strictly correlated then can be a better idea put all under the same umbrella.

It may be more efficient in some ways. But the question wasn't whether it is possible, the question was what the difference between the two is.

[curaga]

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?

The overhead of sending text vs image. Also, rendering on the server scales badly when you want to have 20+ users at the same time.

[curaga]

You still haven't explained why sending the fonts and the image is better than sending just the image. Sending the fonts and the image requires more data than just sending the image. Plus it has a lot of additional problems.

And you also haven't explained why a feature that isn't actually used anymore is so important.

Please read my original post: http://phoronix.com/forums/showthrea...448#post335448
It explains why the feature is important. And yes, it's still used.

I'm not here to propose any implementation. I'm here to explain the issue. I'm not the right person to design such a network protocol, software engineer yes, but without such experience.


I mentioned that you could not send fonts by expecting each machine to have their own fonts, just as it is currently. But that is an implementation detail, which is not what I'm here to discuss.

Do you agree with the points of my original post?

[curaga]

@TheBlackCat

Seems you misread me, I'm advocating for sending *text*, not images. Especially not both fonts and images.

[plonoma]

Regarding point II) The input system in Wayland

looks a lot like Xinput 2.2, minus all the legacy cruft and minus the Master/Slave relationship between inputs. Everything gets one virtual keyboard, one virtual mouse, and one non-virtual tablet interface. The nightmare called multitouch will finally be sorted out. Note from Daniel: As one of the authors of multitouch, I feel pretty qualified to say that it's shit.

What if I want to write an application to use more than one keyboard and mouse?
Games with support for multiplayer on the same machine, split-screen with multiple keyboard+mouse or gamepads. Being able to have slots and being able to pair mouse+keyboard+ other input devices as I wish would be very interesting. (working while runningne reason would be plug and play)

[TheCycoONE]

The overhead of sending text vs image. Also, rendering on the server scales badly when you want to have 20+ users at the same time.

If I understand where you're coming from you would like a light server / heavy client like the web where minimal descriptions are sent over the wire and interpreted on the client. What I don't see is how this could/should be implemented in a display server - I think the only way to maintain long term generality in the display server is to handle everything as images, otherwise you'd want to maintain backwards compatibility with all your old font formats, drawing api, etc. like ancient X.

I would think that the toolkit, which specifies it's drawing API and has the best understanding of what is intentional vs accidental about the look & feel of an application is the best place to implement the kind of transparency you're talking about.

In the mean time I feel that the union of web applications and RDP (or Citrix) fills most peoples requirements. (In my experience VNC is particularly inefficient)