[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex,1.14,1.15

[Peter Nilsson]

Committed by: peter

Update of /cvs/cairo/papers/opengl_freenix04
In directory pdx:/tmp/cvs-serv4933

Modified Files:
	opengl_freenix04.tex 
Log Message:
Playing around with introduction

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.14
retrieving revision 1.15
diff -C2 -d -r1.14 -r1.15
*** opengl_freenix04.tex	17 Feb 2004 00:39:16 -0000	1.14
--- opengl_freenix04.tex	17 Feb 2004 10:52:25 -0000	1.15
***************
*** 29,32 ****
--- 29,35 ----
  
    \section{Abstract}
+ 
+   \edannote {To long? To fuzzy?}
+ 
    In recent years 2D graphics applications and window systems tend to 
    use more demanding graphics features such as alpha blending, image 
***************
*** 36,43 ****
    interface a more hospitable as well as efficient environment for the user.
    
!   Unfortunately these features demand a lot of computation time from the CPU. 
!   In the past this has meant a slowdown throughout the entire system as well as 
!   a significant limitation in the kind of visual effects that can be used.
! 
    This is why many proprietary window systems have developed
    powerful 2D graphics engines to carry out these tasks by utilizing the 
--- 39,44 ----
    interface a more hospitable as well as efficient environment for the user.
    
!   Even with today's powerful computers these tasks constitute a heavy burden on 
!   the CPU. 
    This is why many proprietary window systems have developed
    powerful 2D graphics engines to carry out these tasks by utilizing the 
***************
*** 50,71 ****
  
    A special analysis has been made to investigate wether the level of 
!   hardware acceleration provided by the X Window System~\cite{x} can be 
!   improved by using \libname to carry out its fundamental drawing operations.
  
-   Hopefully the work presented in this paper will be useful in the design of
-   a new generation of hardware accelerated graphic applications in the X 
-   Window System and the open source community in general.
-   
    
    \section{Introduction}
!   The X Window System wasn't originally designed for the advanced graphics that 
    can be seen on modern desktops. The main reason is that graphics 
    hardware available at the time was not fast enough. Application 
    developers soon found the core graphics routines inadequate and the trend 
!   became to use client-side software rendering instead.
  
    One major improvement was made with the introduction of the X Render Extension
    (Render)~\cite{render:2000}. Render has widely been accepted as the new 
!   rendering model for the X Window System. It brought the desired graphics 
    operations to the applications and thereby filled in the gaps of the 
    core protocol. Some of the features that Render
--- 51,112 ----
  
    A special analysis has been made to investigate wether the level of 
!   hardware acceleration provided by the X Window System (X)~\cite{x} can be 
!   improved by using \libname{} to carry out its fundamental drawing operations.
  
    
    \section{Introduction}
!   This introduction is divided into three subsections. First a  background 
!   section introduces the ideas that first lead up to the project.
!   Next follows a brief describtion of how graphics are rendered in X today, and 
!   how \libname{} has been designed to fit this model. Last a section is
!   given that sums up the high level design choices made for \libname.  
! 
!   \edannote {Dunno about this disposition of the introduction, just playing 
!     around with it at this point}
!   
! 
!   \subsection {Background}
!   There's an obvious trend visible in the appearence of modern window systems
!   and 2D graphics in general these days. 
!   They all become more and more loaded with graphical features and visual 
!   effects for each available product generation. 
!   
!   Unfortunately these features demand a lot of computation time from the CPU.
!   In the past this has meant a slowdown throughout the entire system as
!   well as a significant limitation in the kind of visual effects that could be 
!   used. To relieve the CPU, modern window systems have developed 2D-graphics
!   engines which utilize the high performance rendering capabilities inherent in 
!   today's graphics hardware. In fact, much of the visual effects and advanced 
!   graphics that can be seen in these systems wouldn't even be feasible without 
!   hardware accelerated rendering. 
!   
!   The main idea behind this project is to investigate the potential usefulness 
!   of an open source 2D graphics library that can be accelerated to create a high
!   performance rendering environment. 
! 
!   Furthermore these ideas have been applied to X to see if 
!   they could be used to improve hardware acceleration of graphical applications 
!   in that context. 
! 
!   \edannote {Applied to X?? More like developed for X or something. Rethink.}
! 
! 
!   \subsection {Traditional X Rendering}
!   The X Window System wasn't originally designed for the advanced 
!   graphics that 
    can be seen on modern desktops. The main reason is that graphics 
    hardware available at the time was not fast enough. Application 
    developers soon found the core graphics routines inadequate and the trend 
!   became to use client-side software rendering instead. 
!   Several steps have been taken to rectify this since then.
  
+   \edannote {How to make this section feel like it fits in better... and 
+   perhaps try to reduce section depth}
+ 
+ 
+   \subsubsection {X Render Extension}
    One major improvement was made with the introduction of the X Render Extension
    (Render)~\cite{render:2000}. Render has widely been accepted as the new 
!   rendering model for X. It brought the desired graphics 
    operations to the applications and thereby filled in the gaps of the 
    core protocol. Some of the features that Render
***************
*** 79,90 ****
    system. 
  
    Render uses the XFree86 Acceleration Architecture (XAA)~\cite{xaa} to achieve
!   hardware accelerated rendering. This requires graphics driver developers to 
!   add their own XAA Render hooks in each driver to support it, which results in 
!   duplicated effort. XAA breaks down complex Render operations into simpler 
!   ones and accelerates them if support is provided by the driver, otherwise it 
!   falls back on software. Unfortunately not many drivers have much support for 
!   XAA Render hooks at this point, which results in inconsistent acceleration 
!   between different drivers and hardware.
  
    From the benchmarks made in the context of this project the conclusion can 
--- 120,139 ----
    system. 
  
+ 
+   \subsubsection {XFree86 Acceleration Architecture}
    Render uses the XFree86 Acceleration Architecture (XAA)~\cite{xaa} to achieve
!   hardware accelerated rendering. XAA breaks down complex Render operations into
!   simpler ones and accelerates them if support is provided by the driver, 
!   otherwise it falls back on software. 
!   This requires graphics driver developers to add their own XAA Render hooks in 
!   each driver to support it, which results in a duplicated effort.  
!   Unfortunately not many drivers have much support for XAA Render hooks at this 
!   point, which results in inconsistent acceleration between different drivers 
!   and hardware.
! 
! 
!   \subsubsection {X Rendering Performance}
! 
!   \edannote {This section is outdated right now. Stay tuned for updates}
  
    From the benchmarks made in the context of this project the conclusion can 
***************
*** 110,136 ****
    transformations and anti-aliasing.
  
-   \edannote{The remainder of the introduction is longer than it needs to be. 
-     There is some redundant text here. In general it could be cleaned up, 
-     (but perhaps you'll just want to wait for the final paper).}
- 
-   Even with today's powerful computers these tasks constitute a heavy burden on 
-   the CPU. To relieve the CPU, modern window systems have developed 2D-graphics
-   engines which utilize the high performance rendering capabilities inherent in 
-   today's graphics hardware. In fact, much of the visual effects and advanced 
-   graphics that can be seen in these systems wouldn't even be feasible without 
-   hardware accelerated rendering. 
  
!   The main idea behind this project is to investigate the potential usefulness 
!   of a 2D graphics library that can be accelerated by graphics hardware to 
!   create a high performance rendering environment. Furthermore these ideas
!   will be applied to The X Window System to see if they can be used to improve
!   hardware acceleration of graphical applications in that context. 
!  
    The challenge is to realize these ideas in the simplest and most efficient 
    manner.
  
!   These ideas require a complete 2D graphics API that is accelerated by graphics
!   hardware. Fortunately, one big step in this direction has already been taken 
    with the cairo library (formerly known as Xr~\cite{xr}). 
    Cairo is a modern, open source, cross-platform 2D graphics API designed for 
    multiple output devices. The backend interface of cairo has the same semantics
--- 159,176 ----
    transformations and anti-aliasing.
  
  
!   \subsection {The \libname{} model}
!   The main objective  of this project is to create a powerful hardware 
!   accelerated 2D graphics library that fits well into the current X rendering 
!   model. These ideas require a complete 2D graphics API that is accelerated by 
!   graphics hardware. 
    The challenge is to realize these ideas in the simplest and most efficient 
    manner.
  
! 
!   \subsection {A layer under Cairo}
!   Fortunately, one big step in this direction has already been taken 
    with the cairo library (formerly known as Xr~\cite{xr}). 
+ 
    Cairo is a modern, open source, cross-platform 2D graphics API designed for 
    multiple output devices. The backend interface of cairo has the same semantics
***************
*** 138,148 ****
    an attractive and powerful vector based drawing environment. One thing missing
    thus far in cairo is the ability to accelerate the rendering 
!   process with today's high performance graphics hardware. So the library 
!   developed in this project is designed to act as an additional 
!   backend for cairo providing this hardware accelerated output. 
!   Figure~\ref{layers} illustrates these ideas by showing the the layers of 
    software involved when an application uses cairo to draw accelerated output 
    with GLX. These layers are more described in subsequent sections.
  
    \begin{figure}[htbp]
      \begin{centering}
--- 178,190 ----
    an attractive and powerful vector based drawing environment. One thing missing
    thus far in cairo is the ability to accelerate the rendering 
!   process with today's high performance graphics hardware. So \libname{} is 
!   designed to act as an additional backend for cairo providing this hardware 
!   accelerated output. 
!   Figure~\ref{layers} illustrates these ideas by showing the layers of 
    software involved when an application uses cairo to draw accelerated output 
    with GLX. These layers are more described in subsequent sections.
  
+   \edannote {Need new image}
+ 
    \begin{figure}[htbp]
      \begin{centering}
***************
*** 155,158 ****
--- 197,202 ----
    \end{figure}
  
+ 
+   \subsection {A layer on top of OpenGL}
    Still the question remains about how to actually render all the graphics with 
    hardware support. OpenGL~\cite{gl:1.2.1} is the most widely used and supported
***************
*** 161,181 ****
    to realize the rendering in the library.
  
    Hence, the goal is to create an interface on top of OpenGL which provides the 
    same consistent rendering model as Render. This interface should be  
    implemented in such a way that it can take advantage of the OpenGL hardware 
    acceleration provided by modern graphics cards. The semantics of the library 
!   are designed to precisely match the specification of the X Render extension. 
    Having the same semantics as Render allows for seamless integration with the 
    cairo library that then will provide an attractive  environment for developing
    new high performance graphical applications. 
    
!   The complete paper will present results from extensive research to find and 
!   evaluate the possibilities of OpenGL hardware acceleration of operations 
!   needed for the creation of a Render-like interface on top of OpenGL. This 
!   research is concluded with the implementation of an OpenGL 2D compositing 
!   library. The paper will describe the problems encountered in the development 
!   process as well as the chosen solutions. Furthermore the paper will also 
!   include test and benchmarking results that points out the performance and 
!   accuracy of the library on various hardware. 
  
    The development of the 2D compositing library and the other implementation
--- 205,224 ----
    to realize the rendering in the library.
  
+   
+   \subsection {\libname{} design Summary}
    Hence, the goal is to create an interface on top of OpenGL which provides the 
    same consistent rendering model as Render. This interface should be  
    implemented in such a way that it can take advantage of the OpenGL hardware 
    acceleration provided by modern graphics cards. The semantics of the library 
!   are designed to precisely match the specification of Render. 
    Having the same semantics as Render allows for seamless integration with the 
    cairo library that then will provide an attractive  environment for developing
    new high performance graphical applications. 
    
!   Hopefully the work presented in this paper will be useful in the design of
!   a new generation of hardware accelerated graphic applications for X and 
!   the open source community in general.
! 
!   \edannote {The right spot for this?}
  
    The development of the 2D compositing library and the other implementation
***************
*** 185,189 ****
  
    \section{Related Work}
!   Some of the commercially developed window systems have created their own 3D 
    graphic engines that can perform hardware accelerated rendering in a similar 
    manner to the model discussed here. The one that has probably attracted the 
--- 228,232 ----
  
    \section{Related Work}
!   Some of the proprietary window systems have created their own 3D 
    graphic engines that can perform hardware accelerated rendering in a similar 
    manner to the model discussed here. The one that has probably attracted the 
***************
*** 193,202 ****
    to run smoothly without bringing too much load on the CPU.
    
!   The final paper will contain a study of these competing systems as well as a 
!   discussion about their performance compared to the software developed in this 
!   project.
  
  
    \section{Implementation Issues}
    As OpenGL layers are available for various platforms and systems, the library 
    is designed to be usable with any of various OpenGL implementations. Different
--- 236,244 ----
    to run smoothly without bringing too much load on the CPU.
    
!   \edannote {Add more material here}
  
  
    \section{Implementation Issues}
+   \edannote {Totally outdated}
    As OpenGL layers are available for various platforms and systems, the library 
    is designed to be usable with any of various OpenGL implementations. Different
***************
*** 259,262 ****
--- 301,307 ----
  
    \section{Results and Conclusion}
+ 
+   \edannote {To be updated}
+ 
    Right now the library hasn't really been tested that much in real applications
    as it is relatively early in the development process. Some small test 
***************
*** 359,362 ****
--- 404,408 ----
  
    \section{Future Work}
+   \edannote {To be updated}
    As of today the existing implementation of the library supports all the basic 
    functionality initially set up for the project. But still the software is 
***************
*** 381,384 ****
--- 427,431 ----
  
    \section{Visions}
+   \edannote {To be updated}
    The Render compositing model has one major weakness when used with OpenGL, and
    that is that all compositing operations that use a mask surface require