[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex, 1.35, 1.36

[David Reveman]

Committed by: davidr

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

Modified Files:
	opengl_freenix04.tex 
Log Message:
text

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.35
retrieving revision 1.36
diff -C2 -d -r1.35 -r1.36
*** a/opengl_freenix04.tex	27 Mar 2004 13:12:43 -0000	1.35
--- b/opengl_freenix04.tex	31 Mar 2004 14:58:18 -0000	1.36
***************
*** 8,14 ****
  \usepackage{amsmath}
  
! \def\libname{libglc}
! \def\libnamespace{glc}
! \def\libnamespaceU{GLC}
  
  \begin{document}
--- 8,14 ----
  \usepackage{amsmath}
  
! \def\libname{glitz}
! \def\libnamespace{glitz}
! \def\libnamespaceU{GLITZ}
  
  \begin{document}
***************
*** 258,271 ****
      As OpenGL layers are available for various platforms and systems, the 
      library is designed to be usable with any of various OpenGL 
!     implementations. Different OpenGL implementations can be used by 
!     plugging them in to the core of the library through a virtualized 
!     backend. Each backend only needs to provide a few functions which 
!     will allow for the core of the library to perform its rendering 
!     operations unaware of the structure of the underlying OpenGL layer. 
  
!     Having a virtualized backend instead of just choosing code to compile
!     using preprocessor macros has the advantage of making the link between the
!     OpenGL implementation and the core of the library more flexible and 
!     allows for the library to be compiled for multiple backends.  
  
      As of now \libname{} has two backends, for GLX and AGL. GLX is the OpenGL 
--- 258,277 ----
      As OpenGL layers are available for various platforms and systems, the 
      library is designed to be usable with any of various OpenGL 
!     layers. Different OpenGL layers can be used by plugging them in to 
!     the core of \libname{} through a virtualized backend. Each backend
!     needs to provide a table of OpenGL function pointers and few additional
!     functions which will allow for the core to perform its rendering
!     operations unaware of the structure of the underlying OpenGL layer.
  
!     The core of \libname{} is built as a separate library with a minimum
!     set of dependencies. Each backend is built into its own library and
!     different applications can use different backend libraries with the same
!     core library.
! 
!     Having a virtualized backend and different backend libraries instead of
!     just choosing code to compile using preprocessor macros has the
!     advantage of making the link between the OpenGL implementation and the
!     core of the library more flexible and allows for the core of the library
!     to be compiled for multiple backends.
  
      As of now \libname{} has two backends, for GLX and AGL. GLX is the OpenGL 
***************
*** 425,463 ****
        \end{itemize}
  
-       \subsubsection{Direct Polygons}
- 
-       \libname{} is able to render polygons directly onto a destination
-       surface. Each polygon vertex has a specific color associated with it.
-       If the color differ between any of the vertices in a polygon, colors
-       will be blended between them. Direct polygons have the advantages
-       of not requiring an intermediate offscreen buffer and are therefor
-       faster and supported on hardware without offscreen drawing support.
-       Direct polygons might not produce the same results as indirect polygons
-       when alpha component differ from one and should as a result not be
-       used for complex objects with these properties. The more general
-       indirect polygons should be used in these cases instead.
- 
-       \subsubsection{Indirect Polygons}
- 
-       \libname{} has two different methods for rendering indirect polygons. 
-       Using an intermediate offscreen surface or using a stencil buffer.
- 
-       The first method creates an offscreen surface containing only an alpha
-       channel. The polygons are then rendered into this surface and this
-       intermediate surface is then used as mask when compositing the
-       supplied source surface onto the destination surface. This method
-       requires offscreen drawing support and anti-aliased polygon edges can
-       only be rendered if offscreen multi-sample support is available. 
-   
-       Whenever a stencil buffer is available, it will be used for drawing
-       indirect polygons. The polygons are then rendered into the stencil
-       buffer and the stencil buffer is then used for clipping when
-       compositing the supplied source surface onto the destination surface. 
-       This method for drawing indirect polygons is faster and doesn't require
-       offscreen drawing support. When rendering to onscreen surfaces only
-       onscreen mutli-sample support is needed for anti-aliased polygons.
- 
-       Indirect polygons can be used for pattern filling of complex objects.
- 
        \subsubsection{Anti-aliasing}
        
--- 431,434 ----
***************
*** 553,556 ****
--- 524,562 ----
        support, high memory consumption, bad performance or poor results.
  
+       \subsubsection{Direct Polygons}
+ 
+       \libname{} is able to render polygons directly onto a destination
+       surface. Each polygon vertex has a specific color associated with it.
+       If the color differ between any of the vertices in a polygon, colors
+       will be blended between them. Direct polygons have the advantages
+       of not requiring an intermediate offscreen buffer and are therefor
+       faster and supported on hardware without offscreen drawing support.
+       Direct polygons might not produce the same results as indirect polygons
+       when alpha component differ from one and should as a result not be
+       used for complex objects with these properties. The more general
+       indirect polygons should be used in these cases instead.
+ 
+       \subsubsection{Indirect Polygons}
+ 
+       \libname{} has two different methods for rendering indirect polygons. 
+       Using an intermediate offscreen surface or using a stencil buffer.
+ 
+       The first method creates an offscreen surface containing only an alpha
+       channel. The polygons are then rendered into this surface and this
+       intermediate surface is then used as mask when compositing the
+       supplied source surface onto the destination surface. This method
+       requires offscreen drawing support and anti-aliased polygon edges can
+       only be rendered if offscreen multi-sample support is available. 
+   
+       Whenever a stencil buffer is available, it will be used for drawing
+       indirect polygons. The polygons are then rendered into the stencil
+       buffer and the stencil buffer is then used for clipping when
+       compositing the supplied source surface onto the destination surface. 
+       This method for drawing indirect polygons is faster and doesn't require
+       offscreen drawing support. When rendering to onscreen surfaces only
+       onscreen mutli-sample support is needed for anti-aliased polygons.
+ 
+       Indirect polygons can be used for pattern filling of complex objects.
+ 
      \subsection{Text Rendering}
  
***************
*** 568,575 ****
      \subsection{Clipping}
  
!     Just as Render, \libname{} supports non-rectangular clipping. There is
!     one big difference, though. In \libname{} clipping only restricts
!     writing to a surface. \libname{}'s clipping interface cannot restrict
!     reading of a surface.
   
      \subsection{Convolution Filters}
--- 574,584 ----
      \subsection{Clipping}
  
!     Render can restrict read and writes to a drawable using a clip-mask. 
!     Clients can create this clip-mask on its own or implicitly generate it
!     using a set of rectangles. \libname{} has a similar clipping interface
!     but the clip-mask cannot be created by the application, it must always
!     be implicitly generated from a set of rectangles, triangles and trapezoids.
!     With \libname{} clipping only restricts writing to a surface.
!     \libname{}'s clipping interface cannot restrict reading of a surface.
   
      \subsection{Convolution Filters}