[cairo-commit] papers/opengl_freenix04 ChangeLog,1.12,1.13 opengl_freenix04.tex,1.21,1.22

[David Reveman]

Committed by: davidr

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

Modified Files:
	ChangeLog opengl_freenix04.tex 
Log Message:
Update convolution filter section and programmetic surface section

Index: ChangeLog
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/ChangeLog,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** a/ChangeLog	18 Feb 2004 17:01:23 -0000	1.12
--- b/ChangeLog	23 Feb 2004 03:50:01 -0000	1.13
***************
*** 1,2 ****
--- 1,7 ----
+ 2004-02-23    <c99drn at cs.umu.se>
+ 
+ 	* opengl_freenix04.tex: Update convolution filter section and
+ 	programmetic surface section.
+ 
  2004-02-18    <c99drn at cs.umu.se>
  

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.21
retrieving revision 1.22
diff -C2 -d -r1.21 -r1.22
*** a/opengl_freenix04.tex	22 Feb 2004 15:48:43 -0000	1.21
--- b/opengl_freenix04.tex	23 Feb 2004 03:50:01 -0000	1.22
***************
*** 255,266 ****
      library handles this gracefully using image buffers.
  
!     \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
!     functions, one for transmitting pixel data from user memory to a
!     surface and one for retrieving pixel data from a surface to user
!     memory.
  
      \subsection{Image Compositing}
--- 255,265 ----
      library handles this gracefully using image buffers.
  
!     \subsection{User-Provided Immediate Data}
  
!     As all representation of pixel data within \libname{} are in the graphics
!     hardware's memory, application generated images must be transmitted to the
!     hardware in some way. For this purpose \libname{} provides two
!     functions, one for transmitting pixel data to graphics hardware and one 
!     for retrieving pixel data from graphics hardware.
  
      \subsection{Image Compositing}
***************
*** 404,409 ****
        discrete pixel positions. With the currently available display 
        devices it is simply not feasible to sample a non aliased signal
!       according to Nyquists Theorem. Figure~\ref{jaggies} illustrates an aliased
!       graphical image suffering from a jagged edge.
  
        \begin{figure}[htbp]
--- 403,408 ----
        discrete pixel positions. With the currently available display 
        devices it is simply not feasible to sample a non aliased signal
!       according to Nyquists Theorem. Figure~\ref{jaggies} illustrates an 
!       aliased graphical image suffering from a jagged edge.
  
        \begin{figure}[htbp]
***************
*** 411,417 ****
  	  \epsfig{file=jaggies.eps}
  	  \small\itshape
! 	  \caption{\small\itshape (1) The mathematical representation of an edge
! 	  (2) The aliased signal point sampled to screen pixels (3) Anti-aliased
! 	  signal}
  	  \label{jaggies}
  	\end{centering}
--- 410,416 ----
  	  \epsfig{file=jaggies.eps}
  	  \small\itshape
! 	  \caption{\small\itshape (1) The mathematical representation of an 
!                                   edge (2) The aliased signal point sampled 
!                                   to screen pixels (3) Anti-aliased signal}
  	  \label{jaggies}
  	\end{centering}
***************
*** 481,486 ****
        systems this technique has potential for generating extremely high
        quality results with a relatively low cost. Not always supported to
!       offscreens (pbuffers). This means problems with indirect polygon rendering
!       as polygons are then drawn to intermediate offscreen surfaces.
        This technique will be used on all rendering operations if available, 
        direct as well as indirect.
--- 480,485 ----
        systems this technique has potential for generating extremely high
        quality results with a relatively low cost. Not always supported to
!       offscreens (pbuffers). This means problems with indirect polygon
!       rendering as polygons are then drawn to intermediate offscreen surfaces.
        This technique will be used on all rendering operations if available, 
        direct as well as indirect.
***************
*** 510,524 ****
      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.
  
!     To increase text rendering performance multiple glyphs can be
!     composited in one OpenGL operation using a fragment program.
!     Performance could be increased by the maximum number of texture 
!     units supported by hardware. This requires some sort of built in
!     text rendering support in \libname.
  
      \subsection{Convolution Filters}
--- 509,524 ----
      application or a higher level library. For efficient text rendering, 
      glyph sets with offscreen surfaces containing alpha masks should be 
!     used.
  
!     Right now \libname{} renders text at around 50000 glyphs/sec.
!     But major part of the rendering time is CPU time in the library and
!     we are confident that after some profiling and optimization glyph
!     rendering speed could be at least doubled.
  
!     For optimal glyph rendering speed, built in text rendering support
!     needs to be added \libname{}.
!  
!     \edannote{Built in text support or not? We'll see after we've done
!               some profiling and optimizations.}
  
      \subsection{Convolution Filters}
***************
*** 533,545 ****
      matrix is called the convolution kernel.
  
!     \libname{} supports user defined 3x3 convolution kernels. If a
      convolution kernel has been set for a surface, the convolution filter
      will be applied when the surface is used as a source in a compositing
      operation without modifying the original source surface.
  
!     \edannote{Convolution filter support is actually under development and
!               not yet a part of \libname.}
  
!     Convolution filtering is implemented using fragment programs. 
  
      \subsubsection{Useful Convolution kernels}
--- 533,551 ----
      matrix is called the convolution kernel.
  
!     \libname{} supports user defined convolution kernels. If a
      convolution kernel has been set for a surface, the convolution filter
      will be applied when the surface is used as a source in a compositing
      operation without modifying the original source surface.
  
!     In \libname{} convolution filtering is implemented using fragment
!     programs and is only available on hardware that have fragment program
!     support with at least 5 texture indirection instructions. The alternative 
!     would be to use OpenGL's imaging extension and would require a transfer
!     of all pixels through OpenGL's pixel pipeline to an intermediate
!     texture. Eventhough the alternative method would be supported by older
!     hardware, \libname{} uses fragment programs in favor of peformance.
  
!     \edannote{The number of required texture indirection instructions
!               is probably uninteresting.}
  
      \subsubsection{Useful Convolution kernels}
***************
*** 576,586 ****
      \end{table}
  
!     \subsection{Gradients}
  
!     Gradients can be created through drawing of direct polygons with
!     different vertex colors.
  
!     Future version of the library might include support for implicit
!     gradient source surfaces, implemented using fragment programs.
  
      \subsection{Still Under Construction}
--- 582,608 ----
      \end{table}
  
!     \edannote{Original image and image after 3x3 gaussian filtering}
  
!     \subsection{Programmetic Surfaces}
  
!     \libname{} allow you to create programmetic surfaces, a
!     programmetic surface doesn't contain any actual image data only
!     a minimum subset of attributes which describe how to calculate
!     the color for each pixel in the surface. 
! 
!     Programmetic surfaces can be used for wide range of effects,
!     maybe the most usable are linear and radial gradients.
! 
!     \edannote{Some info about linear and radial gradients here.}
! 
!     Programmetic surfaces requires fragment program support.
! 
!     \edannote{Maybe a picture showing results form composite with 
!               a programmatic surface}
!     
!     \edannote{Programmatic surfaces are not implemented yet but I've
!               written working fragment programs for linear and radial
!               gradients and that should be a good start so I'll
!               probably implement it soon.}
  
      \subsection{Still Under Construction}
***************
*** 588,591 ****
--- 610,617 ----
      Most parts of the Render specification have been implemented but there are
      still some issues that need to be addressed.
+ 
+     Disjoint and Conjoint operators.
+ 
+     Sub-pixel ordering.
    
    \section{Results}