Wayland performance [LWN.net]

Wayland performance

Posted Apr 17, 2012 17:15 UTC (Tue) by rvfh (subscriber, #31018)
In reply to: Wayland performance by renox
Parent article: LFCS 2012: X and Wayland

> Where in the article?

Third paragraph:
> From an application's perspective, there aren't that many changes. It still talks to the server for geometry handling and still talks to the kernel or server to create its graphics. But the protocol is different, which will save a bunch of time, system complexity, and memory, Packard said.

> Not with the DRI2 extension AFAIK: X allocates a buffer in the GPU video memory which can be used by a client without copying like Wayland (not 100% sure: DRI2's documentation is hard to read).

I think you're right, though I am no expert in DRI (only coming these days on SoCs, after years of re-inventing the wheel.)

(Log in to post comments)

Wayland performance

Posted Apr 17, 2012 19:56 UTC (Tue) by renox (subscriber, #23785) [Link]

Thanks for the indication of the paragraph, I think what he's talking about is that Weston integrates the window manager (well a part), the display server and the compositor so there will be less IPC so it's more efficient from this point of view, AFAIK nothing prevents an X server to be implemented in the same way if this is really a big performance improvement..

Wayland performance

Posted Apr 17, 2012 20:28 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

It means getting rid of X window manager as a separate entity and embedding it into the X-server process.

At which point you might start thinking that it's easier to throw away X-server completely out of your core and instead relegate it to the status of ordinary application. That's what Wayland does.