[PATCH wayland 4/7] doc: Rename Overview.xml to Introduction.xml
Tiago Vignatti
tiago.vignatti at intel.com
Tue Nov 13 13:28:45 PST 2012
Rename Overview.xml to Introduction.xml, reflecting the previous commit.
Organize also Wayland.xml order of the includes.
Signed-off-by: Tiago Vignatti <tiago.vignatti at intel.com>
---
doc/Wayland/Makefile.am | 8 +--
doc/Wayland/en_US/Introduction.xml | 116 ++++++++++++++++++++++++++++++++++++
doc/Wayland/en_US/Overview.xml | 116 ------------------------------------
doc/Wayland/en_US/Wayland.xml | 2 +-
4 files changed, 121 insertions(+), 121 deletions(-)
create mode 100644 doc/Wayland/en_US/Introduction.xml
delete mode 100644 doc/Wayland/en_US/Overview.xml
diff --git a/doc/Wayland/Makefile.am b/doc/Wayland/Makefile.am
index 65b5b65..f919a89 100644
--- a/doc/Wayland/Makefile.am
+++ b/doc/Wayland/Makefile.am
@@ -1,15 +1,15 @@
publican_sources = \
$(srcdir)/en_US/Wayland.ent \
- $(srcdir)/en_US/Architecture.xml \
- $(srcdir)/en_US/Author_Group.xml \
+ $(srcdir)/en_US/Wayland.xml \
$(srcdir)/en_US/Book_Info.xml \
+ $(srcdir)/en_US/Author_Group.xml \
$(srcdir)/en_US/Foreword.xml \
$(srcdir)/en_US/Preface.xml \
- $(srcdir)/en_US/Wayland.xml \
+ $(srcdir)/en_US/Introduction.xml \
+ $(srcdir)/en_US/Architecture.xml \
$(srcdir)/en_US/Protocol.xml \
$(srcdir)/en_US/Library.xml \
$(srcdir)/en_US/Compositors.xml \
- $(srcdir)/en_US/Overview.xml \
$(srcdir)/en_US/images/icon.svg \
$(srcdir)/en_US/images/wayland-architecture.png \
$(srcdir)/en_US/images/wayland.png \
diff --git a/doc/Wayland/en_US/Introduction.xml b/doc/Wayland/en_US/Introduction.xml
new file mode 100644
index 0000000..51e451e
--- /dev/null
+++ b/doc/Wayland/en_US/Introduction.xml
@@ -0,0 +1,116 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Wayland.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Introduction">
+ <title>Introduction</title>
+ <section id="sect-Motivation">
+ <title>Motivation</title>
+ <para>
+ Most of Linux and Unix-based systems rely on the X Window System (or
+ simply <emphasis>X</emphasis>) as the low-level protocol for building
+ bitmap graphics interfaces. On these systems, the X stack has grown to
+ encompass functionality arguably belonging in client libraries,
+ helper libraries, or the host operating system kernel. Support for
+ things like PCI resource management, display configuration management,
+ direct rendering, and memory management has been integrated into the X
+ stack, imposing limitations like limited support for standalone
+ applications, duplication in other projects (e.g. the Linux fb layer
+ or the DirectFB project), and high levels of complexity for systems
+ combining multiple elements (for example radeon memory map handling
+ between the fb driver and X driver, or VT switching).
+ </para>
+ <para>
+ Moreover, X has grown to incorporate modern features like offscreen
+ rendering and scene composition, but subject to the limitations of the
+ X architecture. For example, the X implementation of composition adds
+ additional context switches and makes things like input redirection
+ difficult.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/x-architecture.png" format="PNG" />
+ </imageobject>
+ <textobject>
+ <phrase>
+ X architecture diagram
+ </phrase>
+ </textobject>
+ </mediaobject>
+ <para>
+ The diagram above illustrates the central role of the X server and
+ compositor in operations, and the steps required to get contents on to
+ the screen.
+ </para>
+ <para>
+ Over time, X developers came to understand the shortcomings of this
+ approach and worked to split things up. Over the past several years,
+ a lot of functionality has moved out of the X server and into
+ client-side libraries or kernel drivers. One of the first components
+ to move out was font rendering, with freetype and fontconfig providing
+ an alternative to the core X fonts. Direct rendering OpenGL as a
+ graphics driver in a client side library went through some iterations,
+ ending up as DRI2, which abstracted most of the direct rendering
+ buffer management from client code. Then cairo came along and provided
+ a modern 2D rendering library independent of X, and compositing
+ managers took over control of the rendering of the desktop as toolkits
+ like GTK+ and Qt moved away from using X APIs for rendering. Recently,
+ memory and display management have moved to the Linux kernel, further
+ reducing the scope of X and its driver stack. The end result is a
+ highly modular graphics stack.
+ </para>
+
+ </section>
+
+ <section id="sect-Compositing-manager-display-server">
+ <title>Compositing manager as the display server</title>
+ <para>
+ Wayland is a new display server and compositing protocol, and Weston
+ is the implementation of this protocol which builds on top of all the
+ components above. We are trying to distill out the functionality in
+ the X server that is still used by the modern Linux desktop. This
+ turns out to be not a whole lot. Applications can allocate their own
+ off-screen buffers and render their window contents directly, using
+ hardware accelerated libraries like libGL, or high quality software
+ implementations like those found in Cairo. In the end, what’s needed
+ is a way to present the resulting window surface for display, and a
+ way to receive and arbitrate input among multiple clients. This is
+ what Wayland provides, by piecing together the components already in
+ the eco-system in a slightly different way.
+ </para>
+ <para>
+ X will always be relevant, in the same way Fortran compilers and VRML
+ browsers are, but it’s time that we think about moving it out of the
+ critical path and provide it as an optional component for legacy
+ applications.
+ </para>
+ <para>
+ Overall, the philosophy of Wayland is to provide clients with a way to
+ manage windows and how their contents is displayed. Rendering is left
+ to clients, and system wide memory management interfaces are used to
+ pass buffer handles between clients and the compositing manager.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/wayland-architecture.png" format="PNG" />
+ </imageobject>
+ <textobject>
+ <phrase>
+ Wayland architecture diagram
+ </phrase>
+ </textobject>
+ </mediaobject>
+ <para>
+ The figure above illustrates how Wayland clients interact with a
+ Wayland server. Note that window management and composition are
+ handled entirely in the server, significantly reducing complexity
+ while marginally improving performance through reduced context
+ switching. The resulting system is easier to build and extend than a
+ similar X system, because often changes need only be made in one
+ place. Or in the case of protocol extensions, two (rather than 3 or 4
+ in the X case where window management and/or composition handling may
+ also need to be updated).
+ </para>
+ </section>
+</chapter>
diff --git a/doc/Wayland/en_US/Overview.xml b/doc/Wayland/en_US/Overview.xml
deleted file mode 100644
index 51e451e..0000000
--- a/doc/Wayland/en_US/Overview.xml
+++ /dev/null
@@ -1,116 +0,0 @@
-<?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Wayland.ent">
-%BOOK_ENTITIES;
-]>
-<chapter id="chap-Introduction">
- <title>Introduction</title>
- <section id="sect-Motivation">
- <title>Motivation</title>
- <para>
- Most of Linux and Unix-based systems rely on the X Window System (or
- simply <emphasis>X</emphasis>) as the low-level protocol for building
- bitmap graphics interfaces. On these systems, the X stack has grown to
- encompass functionality arguably belonging in client libraries,
- helper libraries, or the host operating system kernel. Support for
- things like PCI resource management, display configuration management,
- direct rendering, and memory management has been integrated into the X
- stack, imposing limitations like limited support for standalone
- applications, duplication in other projects (e.g. the Linux fb layer
- or the DirectFB project), and high levels of complexity for systems
- combining multiple elements (for example radeon memory map handling
- between the fb driver and X driver, or VT switching).
- </para>
- <para>
- Moreover, X has grown to incorporate modern features like offscreen
- rendering and scene composition, but subject to the limitations of the
- X architecture. For example, the X implementation of composition adds
- additional context switches and makes things like input redirection
- difficult.
- </para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/x-architecture.png" format="PNG" />
- </imageobject>
- <textobject>
- <phrase>
- X architecture diagram
- </phrase>
- </textobject>
- </mediaobject>
- <para>
- The diagram above illustrates the central role of the X server and
- compositor in operations, and the steps required to get contents on to
- the screen.
- </para>
- <para>
- Over time, X developers came to understand the shortcomings of this
- approach and worked to split things up. Over the past several years,
- a lot of functionality has moved out of the X server and into
- client-side libraries or kernel drivers. One of the first components
- to move out was font rendering, with freetype and fontconfig providing
- an alternative to the core X fonts. Direct rendering OpenGL as a
- graphics driver in a client side library went through some iterations,
- ending up as DRI2, which abstracted most of the direct rendering
- buffer management from client code. Then cairo came along and provided
- a modern 2D rendering library independent of X, and compositing
- managers took over control of the rendering of the desktop as toolkits
- like GTK+ and Qt moved away from using X APIs for rendering. Recently,
- memory and display management have moved to the Linux kernel, further
- reducing the scope of X and its driver stack. The end result is a
- highly modular graphics stack.
- </para>
-
- </section>
-
- <section id="sect-Compositing-manager-display-server">
- <title>Compositing manager as the display server</title>
- <para>
- Wayland is a new display server and compositing protocol, and Weston
- is the implementation of this protocol which builds on top of all the
- components above. We are trying to distill out the functionality in
- the X server that is still used by the modern Linux desktop. This
- turns out to be not a whole lot. Applications can allocate their own
- off-screen buffers and render their window contents directly, using
- hardware accelerated libraries like libGL, or high quality software
- implementations like those found in Cairo. In the end, what’s needed
- is a way to present the resulting window surface for display, and a
- way to receive and arbitrate input among multiple clients. This is
- what Wayland provides, by piecing together the components already in
- the eco-system in a slightly different way.
- </para>
- <para>
- X will always be relevant, in the same way Fortran compilers and VRML
- browsers are, but it’s time that we think about moving it out of the
- critical path and provide it as an optional component for legacy
- applications.
- </para>
- <para>
- Overall, the philosophy of Wayland is to provide clients with a way to
- manage windows and how their contents is displayed. Rendering is left
- to clients, and system wide memory management interfaces are used to
- pass buffer handles between clients and the compositing manager.
- </para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/wayland-architecture.png" format="PNG" />
- </imageobject>
- <textobject>
- <phrase>
- Wayland architecture diagram
- </phrase>
- </textobject>
- </mediaobject>
- <para>
- The figure above illustrates how Wayland clients interact with a
- Wayland server. Note that window management and composition are
- handled entirely in the server, significantly reducing complexity
- while marginally improving performance through reduced context
- switching. The resulting system is easier to build and extend than a
- similar X system, because often changes need only be made in one
- place. Or in the case of protocol extensions, two (rather than 3 or 4
- in the X case where window management and/or composition handling may
- also need to be updated).
- </para>
- </section>
-</chapter>
diff --git a/doc/Wayland/en_US/Wayland.xml b/doc/Wayland/en_US/Wayland.xml
index e72bb11..e240512 100644
--- a/doc/Wayland/en_US/Wayland.xml
+++ b/doc/Wayland/en_US/Wayland.xml
@@ -7,7 +7,7 @@
<xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Foreword.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Architecture.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Protocol.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Library.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
--
1.7.9.5
More information about the wayland-devel
mailing list