If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

There's probably a good argument to be made that Wayland can be(going forward) smaller and leaner than X is including the same features, or even adding in new features. But we aren't there yet.

Right now, it's simply a matter of Wayland does less, so it's smaller. X does more, so it's bigger.

How big is Xwayland, anyways?(I would assume it's not very large, but that misses the point) Wayland doesn't have the backward compatibility layer, its X which has the 'forward compatibility' layer, so to say. So by definition, X would have to be bigger.

Comment

Nor has it encountered the real world, yet. Right now it's a "battle plan", and battle plans seldom survive encounter with the enemy. That's not to say that it's not worthwhile, and can be an improvement over X. It's just that a year or two down the road, Wayland will have its ugly warts and bits of bloat, though it will no doubt still be smaller than X.

Comment

PART of Wayland being smaller is that while yes it has less features, it also has less things it has to support.

Straight from the Wayland FAQ:

What is wrong with X?

The problem with X is that... it's X. When you're an X server there's a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. For example, core fonts; this is the original font model that was how your got text on the screen for the many first years of X11. This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!). Also, the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the X.org server modern by adding extensions such as XRandR, XRender and COMPOSITE and to some extent phase out less useful extensions. But we can't ever get rid of the core rendering API and much other complexity that is rarely used in a modern desktop. With Wayland we can move the X server and all its legacy technology to a optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if don't plan for it.

Comment

Simply because Wayland lacks some features compared to X does not in any way imply that it has less features. Instead I would say that Wayland has more features than X due to it having exactly the capabilities which X lacks. The sections of X that will not be implemented in Wayland should be counted as a positive feature of Wayland.

Comment

wrong, wayland protocol support most of the actually used features of Xorg already and it has some that are not possible with X11 protocol without a barbaric amount of hacks[like fps accurate animations].

about missing features in 1.0 protocol will be network rendering but i agree this support should move client side, after all Kde/Qt --Gnome/GTK[etc] know better than anyone how they specific render code works
for example:

* Kde can reuse the local icons theme if present[or ask the user to install it] so it doesn't have to send images just pix identifiers to instruct the target wayland/kde to use those in your HDD

* another example could be Qt/gtk introducing a meta renderer plugin that just instruct the remote Qt/wayland draw a Qcombobox with this properties at this position using X font, etc. so the actual local QT/gtk in the remote host do the rendering making the bandwith use extremely fast/easy to compress and encrypt, in fact this can allow you to use remote apps as any of your local apps, without worry about resolution or any other setting in your origin desktop/server,etc (many possibilities left to think about )

about both project size, wayland will always be smaller than X11 since wayland is not a renderer, wayland is just a police that route commands to KMS/DRM/DRI/EGL/OPENGL/MESA/EVDEV/V4L/Overlays[<-- those one do the actual rendering] in a standard way so everyone can be on the same page.

weston is just an example toy of how to do composite using wayland protocol instead of X11 that will make life easier for desktops devs to make the transition and well is a test client that wayland devs use to put some pressure in their code and iron bugs/errors