[cairo-commit] papers/opengl_freenix04 jaggies.png, 1.2, 1.3 opengl_freenix04.tex, 1.39, 1.40

[David Reveman]

Committed by: davidr

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

Modified Files:
	jaggies.png opengl_freenix04.tex 
Log Message:
jaggies and text

Index: jaggies.png
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/jaggies.png,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
Binary files /tmp/cvsmM8O0b and /tmp/cvsiWkqZd differ

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.39
retrieving revision 1.40
diff -C2 -d -r1.39 -r1.40
*** a/opengl_freenix04.tex	4 Apr 2004 11:47:20 -0000	1.39
--- b/opengl_freenix04.tex	4 Apr 2004 19:26:23 -0000	1.40
***************
*** 185,189 ****
    
    To sum up these ideas, \libname{} is created to act as an interface on 
!   top of OpenGL which provides the same consistent rendering model as 
    Render. This interface is implemented in such a way that it takes 
    advantage of the OpenGL hardware acceleration provided by modern graphics
--- 185,189 ----
    
    To sum up these ideas, \libname{} is created to act as an interface on 
!   top of OpenGL, which provides the same consistent rendering model as 
    Render. This interface is implemented in such a way that it takes 
    advantage of the OpenGL hardware acceleration provided by modern graphics
***************
*** 359,368 ****
      use a pbuffer directly as a texture.
  
!     The optional mask surface which can be provided to the general composite
      operation creates some additional complications. The source surfaces
      must first be composited onto the mask using the Porter-Duff in-operator
      and the result should then be composited onto the destination. The
      default method for handling this is to create an intermediate offscreen
!     surface which can be used for compositing using the in-operator.
      This surface can then be composited onto the destination with an 
      arbitrary operator for the correct result.
--- 359,368 ----
      use a pbuffer directly as a texture.
  
!     The optional mask surface that can be provided to the general composite
      operation creates some additional complications. The source surfaces
      must first be composited onto the mask using the Porter-Duff in-operator
      and the result should then be composited onto the destination. The
      default method for handling this is to create an intermediate offscreen
!     surface, which can be used for compositing using the in-operator.
      This surface can then be composited onto the destination with an 
      arbitrary operator for the correct result.
***************
*** 371,375 ****
      mask surface directly without the creation of an intermediate surface.
      Even though the fixed OpenGL pipeline doesn't seem to allow for such an 
!     operation, \libname{} is able to do this on hardware which supports
      fragment programs. Fragment programs allows for fragment level
      programmability in OpenGL and in combination with multi-texturing 
--- 371,375 ----
      mask surface directly without the creation of an intermediate surface.
      Even though the fixed OpenGL pipeline doesn't seem to allow for such an 
!     operation, \libname{} is able to do this on hardware that support
      fragment programs. Fragment programs allows for fragment level
      programmability in OpenGL and in combination with multi-texturing 
***************
*** 567,571 ****
      used. With external glyph management \libname{} renders text at 
      approximately 50000 glyphs/sec on the test setup described in section
!     \ref{Results}.
  
      Built in text handling is planned for future versions of the library and
--- 567,571 ----
      used. With external glyph management \libname{} renders text at 
      approximately 50000 glyphs/sec on the test setup described in section
!     \ref{section: Results}.
  
      Built in text handling is planned for future versions of the library and
***************
*** 676,680 ****
  
      \Libname{} also support programmatic surfaces that represent linear or
!     radial transition vector patterns. A linear pattern defines two points
      which form a transition vector. A radial gradient defines a center point
      and a radius, together they form a dynamic transition vector around the 
--- 676,680 ----
  
      \Libname{} also support programmatic surfaces that represent linear or
!     radial transition vector patterns. A linear pattern defines two points,
      which form a transition vector. A radial gradient defines a center point
      and a radius, together they form a dynamic transition vector around the 
***************
*** 714,718 ****
      
      In addition to the 2D drawing functions \libname{} also
!     provides a set of functions which makes it possible to use
      \libname{} as a cross-platform OpenGL layer. The following three 
      functions allow the application to use ordinary OpenGL calls
--- 714,718 ----
      
      In addition to the 2D drawing functions \libname{} also
!     provides a set of functions that makes it possible to use
      \libname{} as a cross-platform OpenGL layer. The following three 
      functions allow the application to use ordinary OpenGL calls
***************
*** 795,799 ****
    to an offscreen surface and then use it as a texture when drawing in 3D.
      
!   Applications, libraries and toolkits which use \libname{} as
    rendering backend will get both 2D and 3D support with the ability
    two use all 2D surfaces as textures for 3D rendering.
--- 795,799 ----
    to an offscreen surface and then use it as a texture when drawing in 3D.
      
!   Applications, libraries and toolkits that use \libname{} as
    rendering backend will get both 2D and 3D support with the ability
    two use all 2D surfaces as textures for 3D rendering.
***************
*** 816,822 ****
    Figures~\ref{Infinity Sign 1} and~\ref{Infinity Sign 2} illustrates the
    output inconsistencies for aliased rendering. The infinite sign is 
!   tessellated into 370 trapezoids by the cairo library which are then rendered 
!   using \libname{} and xrender. Both figures are magnified to better show
!   the output differences.
    
    \begin{figure}[h!tbp]
--- 816,822 ----
    Figures~\ref{Infinity Sign 1} and~\ref{Infinity Sign 2} illustrates the
    output inconsistencies for aliased rendering. The infinite sign is 
!   tessellated into 370 trapezoids by the cairo library, which are then
!   rendered using \libname{} and xrender. Both figures are magnified to
!   better show the output differences.
    
    \begin{figure}[h!tbp]
***************
*** 1001,1005 ****
      \item \emph{tri2.}
            Draws a set of triangles in one single rendering operation.
!           This type of operation is often used for rendering complex objects
            which have been tessellated into (in this case) triangles.
            Imlib2 skips this test as it lacks support for it.
--- 1001,1005 ----
      \item \emph{tri2.}
            Draws a set of triangles in one single rendering operation.
!           This type of operation is often used for rendering complex objects,
            which have been tessellated into (in this case) triangles.
            Imlib2 skips this test as it lacks support for it.
***************
*** 1081,1086 ****
    Table~\ref{rendermark5} shows that nvidia's driver performs well 
    compared to \libname{} except for the case were transformations
!   are used. \libname{} is then much faster than nvidia's driver which
!   seems unable to use acceleration with transformation.
  
    \section{Conclusion}
--- 1081,1086 ----
    Table~\ref{rendermark5} shows that nvidia's driver performs well 
    compared to \libname{} except for the case were transformations
!   are used. \libname{} is then much faster than nvidia's driver, which
!   seem unable to use acceleration with transformations.
  
    \section{Conclusion}
***************
*** 1135,1139 ****
  
    The X desktop seems to be going into a new era and cairo is definitely the
!   2D graphics API which will be used in tomorrow's X applications. The 
    support for hardware accelerated surfaces in cairo might then be of great
    importance. Plans for the creation of an X server that will use OpenGL for
--- 1135,1139 ----
  
    The X desktop seems to be going into a new era and cairo is definitely the
!   2D graphics API that will be used in tomorrow's X applications. The 
    support for hardware accelerated surfaces in cairo might then be of great
    importance. Plans for the creation of an X server that will use OpenGL for