It was attempted as a Google Summer of Code project in 2011, but was not successful. Initial versions of Wayland have not provided network transparency, though Høgsberg noted in 2010 that network transparency is possible. Most applications are expected to gain support for Wayland through one of these libraries without modification to the application. The project is also developing versions of GTK and Qt that render to Wayland instead of to X. Wayland consists of a protocol and a reference implementation named Weston. 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. With Wayland we can move the X server and all its legacy technology to an optional code path. For many things we've been able to keep the X.org server modern by adding extension such as XRandR, XRender and COMPOSITE. This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!), and the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. What’s different now is that a lot of infrastructure has moved from the X server into the kernel (memory management, command scheduling, mode setting) or libraries ( cairo, pixman, freetype, fontconfig, pango, etc.), and there is very little left that has to happen in a central server process. Høgsberg could have added an extension to X as many recent projects have done, but preferred to " X out of the hotpath between clients and the hardware" for reasons explained in the project's FAQ: This will be "a much-simplified graphics system offering more flexibility and better performance". Direct Rendering Infrastructure (DRI), Direct Rendering Manager (DRM)) "in the middle", with "window systems like X and Wayland. all talking to the X server, which is at the center of the universe" towards putting the Linux kernel and its components (i.e. īeginning around 2010, Linux desktop graphics have moved from having "a pile of rendering interfaces.
The Wayland Display Server project was started by Red Hat developer Kristian Høgsberg in 2008. The compositor can then directly issue an ioctl to schedule a pageflip with KMS. The Wayland compositor collects damage requests from its clients and then re-composites the screen.But in the Wayland case, the rendering happens by the client via EGL, and the client just sends a request to the compositor to indicate the region that was updated. As in the X case, when the client receives the event, it updates the UI in response.The types of transformation that can be applied to a window is only restricted to what the compositor can do, as long as it can compute the inverse transformation for the input events.
Thus, the Wayland compositor can pick the right window and transform the screen coordinates to window local coordinates, by applying the inverse transformations. The scenegraph corresponds to what is on screen and the Wayland compositor understands the transformations that it may have applied to the elements in the scenegraph.
0 kommentar(er)
