[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex,1.19,1.20

Peter Nilsson commit at pdx.freedesktop.org
Mon Aug 15 11:12:59 PDT 2005


Committed by: peter

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

Modified Files:
	opengl_freenix04.tex 
Log Message:
Corrected minor spelling errors

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.19
retrieving revision 1.20
diff -C2 -d -r1.19 -r1.20
*** a/opengl_freenix04.tex	18 Feb 2004 17:01:23 -0000	1.19
--- b/opengl_freenix04.tex	18 Feb 2004 18:39:48 -0000	1.20
***************
*** 245,249 ****
      allows for the library to be compiled for multiple backends.  
  
!     As of now libglc has two backends, GLX and AGL. GLX is the OpenGL 
      implementation used on Unix like systems to provide a glue layer between 
      OpenGL and the X Window System. AGL is Apple's OpenGL implementation 
--- 245,249 ----
      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 
      implementation used on Unix like systems to provide a glue layer between 
      OpenGL and the X Window System. AGL is Apple's OpenGL implementation 
***************
*** 256,260 ****
      means that the application itself maintains the data that describe the
      model. For example, with Xrender you draw objects by completely
!     specifying what to be drawn. Xrender simply takes the data provided
      by the application and immediately draws the appropriate objects.
  
--- 256,260 ----
      means that the application itself maintains the data that describe the
      model. For example, with Xrender you draw objects by completely
!     specifying what should be drawn. Xrender simply takes the data provided
      by the application and immediately draws the appropriate objects.
  
***************
*** 274,279 ****
  
      For any usable immediate mode graphics API, offscreen drawing is required. 
!     Even though support for this have actually been around for a long time on
!     IRIX systems and other workstations, it's not until recently that it have
      become a standard feature on the regular home desktop computer.
      Pixel buffers or so called pbuffers are what makes offscreen rendering
--- 274,279 ----
  
      For any usable immediate mode graphics API, offscreen drawing is required. 
!     Even though support for this has actually been around for a long time on
!     IRIX systems and other workstations, it's not until recently that it has
      become a standard feature on the regular home desktop computer.
      Pixel buffers or so called pbuffers are what makes offscreen rendering
***************
*** 282,288 ****
      However, as pbuffers are a relatively new feature in the OpenGL world,
      it is not yet supported by all hardware and all drivers. When support for
!     offscreen drawing is missing the application using \libname{} will 
      have to handle this on its own. Even though \libname{} is primarily
!     designed for the tomorrows graphics hardware it's important to be able
      to fall back to software rendering in cases where \libname{} is not
      able to carry out offscreen drawing operations. For example, the cairo
--- 282,288 ----
      However, as pbuffers are a relatively new feature in the OpenGL world,
      it is not yet supported by all hardware and all drivers. When support for
!     offscreen drawing is missing, the application using \libname{} will 
      have to handle this on its own. Even though \libname{} is primarily
!     designed for modern graphics hardware it's important to be able
      to fall back to software rendering in cases where \libname{} is not
      able to carry out offscreen drawing operations. For example, the cairo
***************
*** 291,295 ****
      \subsection{Client-Provided Immediate Data}
  
!     As surfaces provide the only representation for pixel data within
      \libname{}, application generated images must be transmitted to
      video memory in some way. For this purpose \libname{} provides two
--- 291,295 ----
      \subsection{Client-Provided Immediate Data}
  
!     As surfaces provide the only representation of pixel data within
      \libname{}, application generated images must be transmitted to
      video memory in some way. For this purpose \libname{} provides two
***************
*** 311,320 ****
      be available as textures. The default method for making an offscreen
      or onscreen surface available as a texture is to have the graphics
!     hardware copy the pixel data into a texture image, but as this is
      relatively slow operation, \libname{} does its best to minimize the
      area and the occasions for this copy operation. On some hardware a 
!     feature called render-texture is available, this feature allows 
!     \libname{} to totally eliminate the above mentioned copy operation and
!     use a pbuffer directly as a texture.
  
      The optional mask surface which can be provide to the general composite
--- 311,320 ----
      be available as textures. The default method for making an offscreen
      or onscreen surface available as a texture is to have the graphics
!     hardware copy the pixel data into a texture image. As this is a
      relatively slow operation, \libname{} does its best to minimize the
      area and the occasions for this copy operation. On some hardware a 
!     feature called render-texture is available that allows \libname{} to 
!     eliminate the above mentioned copy operation and use a pbuffer directly 
!     as a texture.
  
      The optional mask surface which can be provide to the general composite
***************
*** 343,347 ****
  
      When using fragment programs for direct compositing with mask
!     surfaces some transformation cannot be done as both the source
      surface and the mask surfaces share vertex coordinates.
  
--- 343,347 ----
  
      When using fragment programs for direct compositing with mask
!     surfaces some transformations cannot be done as both the source
      surface and the mask surfaces share vertex coordinates.
  
***************
*** 349,360 ****
  
      To provide for solid colors and repeating patterns, surfaces have a 
!     `repeat' attribute, when set, the surface is treated as if its width 
      and height were infinite by tiling the contents of the surface along 
      both axes.
  
!     Normally OpenGL supports tiling of textures that have dimensions that
!     are of power of two size. If surface dimensions are of this size
      \libname{} can let OpenGL handle the tiling for maximum efficiency.
!     For surfaces that doesn't have power of two sized dimensions
      \libname{} will repeat the surfaces manually by performing multiple
      texturing operations.
--- 349,360 ----
  
      To provide for solid colors and repeating patterns, surfaces have a 
!     `repeat' attribute. When set, the surface is treated as if it's width 
      and height were infinite by tiling the contents of the surface along 
      both axes.
  
!     Normally OpenGL supports tiling of textures with dimensions that
!     are power of two sized. If surface dimensions are of this size
      \libname{} can let OpenGL handle the tiling for maximum efficiency.
!     For surfaces that don't have power of two sized dimensions
      \libname{} will repeat the surfaces manually by performing multiple
      texturing operations.
***************
*** 370,379 ****
        Trapezoids are represented by two horizontal lines delimiting the top
        and bottom of the trapezoid and two additional lines specified by
!       arbitrary points. These primitives are design to be used for
        rendering complex objects tessellated by higher level applications.
  
        \libname only supports imprecise pixelization. Precise pixelization
        is not supported as OpenGL has relatively weak invariant 
!       requirements of pixelization because of the desire for 
        high-performance mixed software and hardware implementations.
        \libname matches the following of set of invariants
--- 370,379 ----
        Trapezoids are represented by two horizontal lines delimiting the top
        and bottom of the trapezoid and two additional lines specified by
!       arbitrary points. These primitives are designed to be used for
        rendering complex objects tessellated by higher level applications.
  
        \libname only supports imprecise pixelization. Precise pixelization
        is not supported as OpenGL has relatively weak invariant 
!       requirements of pixelization. This is because of the desire for 
        high-performance mixed software and hardware implementations.
        \libname matches the following of set of invariants
***************
*** 392,398 ****
        \libname is able to render polygons direct to a destination
        surface. Each polygon vertex have a specific color associated with it
!       and if color differ between any of the vertices in a polygon colors
        will be blended between vertices. Direct polygons have the advantages
!       of not requiring an intermediate offscreen buffer and is therefor
        faster and supported on hardware without offscreen drawing support.
        Direct polygons might not produce the same results as indirect polygons
--- 392,398 ----
        \libname is able to render polygons direct to a destination
        surface. Each polygon vertex have a specific color associated with it
!       and if the color differ between any of the vertices in a polygon, colors
        will be blended between vertices. 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
***************
*** 525,532 ****
      application or a higher level library. For efficient text rendering, 
      glyph sets with offscreen surfaces containing alpha masks should be 
!     used. Benchmark tests have proven that performance decrement from 
      having the glyph management outside \libname{} are insignificant.
  
!     With the latest hardware \libname{} renders text at around 50000 
      glyphs/sec.
  
--- 525,532 ----
      application or a higher level library. For efficient text rendering, 
      glyph sets with offscreen surfaces containing alpha masks should be 
!     used. Benchmark tests have proven that the performance decrement from 
      having the glyph management outside \libname{} are insignificant.
  
!     With the latest hardware, \libname{} renders text at around 50000 
      glyphs/sec.
  
***************
*** 539,543 ****
      \subsection{Convolution Filters}
  
!     Convolutions are used to perform many common image processing operations
      including sharpening, blurring, noise reduction, embossing, and 
      edge enhancement.
--- 539,543 ----
      \subsection{Convolution Filters}
  
!     Convolutions can be used to perform many common image processing operations
      including sharpening, blurring, noise reduction, embossing, and 
      edge enhancement.





More information about the cairo-commit mailing list