[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex,1.24,1.25

[David Reveman]

Committed by: davidr

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

Modified Files:
	opengl_freenix04.tex 
Log Message:
More text

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.24
retrieving revision 1.25
diff -C2 -d -r1.24 -r1.25
*** a/opengl_freenix04.tex	23 Feb 2004 13:49:09 -0000	1.24
--- b/opengl_freenix04.tex	23 Feb 2004 15:12:08 -0000	1.25
***************
*** 129,133 ****
    and more consistent hardware acceleration of the rendering process.
  
- 
    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
--- 129,132 ----
***************
*** 528,551 ****
        surfaces when rendering indirect polygons.
  
- 
      \subsection{Text Rendering}
  
      Current versions of \libname{} has no built in text support. 
!     Glyph rasterization and glyph management should be handled by the
!     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}
  
--- 527,543 ----
        surfaces when rendering indirect polygons.
  
      \subsection{Text Rendering}
  
      Current versions of \libname{} has no built in text support. 
!     Glyph rasterization and glyph management could however be handled by 
!     the application or a higher level library. For efficient text rendering, 
      glyph sets with offscreen surfaces containing alpha masks should be 
!     used. With external glyph management \libname{} renders text at around 
!     50000 glyphs/sec.
  
!     Built in text handling is planned for future version of the library and
!     tests have proven that this will increase glyph rendering speed to
!     at least 200000 glyphs/sec.
   
      \subsection{Convolution Filters}
  
***************
*** 617,629 ****
      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
--- 609,627 ----
      the color for each pixel in the surface. 
  
!     Programmetic surfaces can be used for wide range of effects, however the
!     most useful seems to be gradients. Gradients consistz of a continuously 
!     smooth color transition along a vector from one color to another. 
!     \libname{} provides for at least two types of gradients, linear and 
!     radial. A linear gradient defines two points which form the color 
!     transition vector. A radial gradient defines a center point and a 
!     radius, together they form a dynamic transisiton vector around the 
!     center point.
  
!     As all programmetic surfaces are implemented using fragment programs
!     they will only be available on hardware supporting the fragment program
!     extension.
  
!     \edannote{A picture showing results form composite with 
!               a programmatic surface (linear gradient should be fine)}
      
      \edannote{Programmatic surfaces are not implemented yet but I've
***************
*** 653,675 ****
      Allowing for the applications to perform ordinary OpenGL calls in this 
      way enables \libname to also act as an easy to use toolkit on top of 
!     OpenGL. The initialization process then becomes much simplified and it takes
!     only a few lines of code to set up a powerful OpenGL drawing environment
!     for on- and offscreeen rendering.
  
      An example of usage is application that implements a visual effect 
      like a 3D transformation on a 2D surface created with \libname{}. 
      Something like the well known cube effect in Mac OS X's user switching 
!     procedure could easily be implemented with a \libname{} application in this 
!     fashion.
! 
!     \subsection{Still Under Construction}
! 
!     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}
  
--- 651,664 ----
      Allowing for the applications to perform ordinary OpenGL calls in this 
      way enables \libname to also act as an easy to use toolkit on top of 
!     OpenGL. The initialization process then becomes much simplified and it
!     takes only a few lines of code to set up a powerful OpenGL drawing
!     environment for on- and offscreeen rendering.
  
      An example of usage is application that implements a visual effect 
      like a 3D transformation on a 2D surface created with \libname{}. 
      Something like the well known cube effect in Mac OS X's user switching 
!     procedure could easily be implemented with a \libname{} application in
!     this fashion.
  
    \section{Results}
  
***************
*** 778,814 ****
    \section{Conclusion}
  
!   \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 in an early stage of development and lots of work remains for
!   making it stable and optimized with regards to performance and accuracy.
!   A deadline for the project has been set for March 2004. The aim is to have
!   a useful library by that time as well as complete documentation of the
!   project. A presentation of the work will be held at Umeå University at 
!   that time but development and maintenance of the software will certainly
!   stretch beyond that date. 
  
!   Of course the future will demand new features from the library as it is an 
!   area of continuous development. For example in the near future new functions
!   for the creation and compositing of glyph sets probably need to be added for
!   more efficient rendering of text. 
  
!   Special functions for more efficient rendering of gradients could also be
!   added at some level.
  
!   These additional functionalities will probably be added soon and documented
!   in the full paper.
  
!   \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
!   that OpenGL creates an intermediate surface and perform the compositing 
!   in two steps.
  
    The X desktop seems to be going into a new era and cairo is definitely the
--- 767,817 ----
    \section{Conclusion}
  
!   During the development of \libname{} we've found that with the OpenGL 
!   extensions available today and the wide range of hardware supporting them,
!   it's not only possible create an Render-like interface on top of OpenGL
!   it's actually very efficient. We're not all the way there yet but with 
!   the current version of \libname{} we've taken a big step.
  
!   \section{Future Work}
  
    As of today the existing implementation of the library supports all 
!   the basic functionality initially set up for the project. But there are
!   still some important features missing and the software is in an early
!   stage of development and lots of work remains for making it stable and 
!   optimized with regards to performance and accuracy.
  
!   The following list contains those features that most importantly need to 
!   be addressed in future versions of the library.
  
!   \begin{itemize}
!     \item \bf{Text rendering}
!           Built in text rendering will allow much better glyph rendering
!           speeds and remove complex glyph management from the application.
!     \item \bf{Sub-pixel rendering}
!           Sub-pixel rendering can be used to effectively increase the 
!           horizontal resolution of LCD displays. This will require
!           support for compositing each color component with different
!           masks.
!     \item \bf{Conjoint operators}
!           For incremental scene updates.
!     \item \bf{Disjoint operators}
!           For tesselating figures with anti-aliased edges. 
!   \end{itemize}
  
!   \edannote{Thought maybe sub-pixel rendering could be possible
!             by masking color component output using glColorMask but
!             maybe I'm way off here. I'll do some testing soon and we'll
!             see what we can do.}
  
!   \edannote{Conjoint and Disjoint operators, this might
!             be done with one of the many blending extensions that exists. 
!             If not, we can always have both the source and destinations as 
!             textures and do all blending using fragment programs, slow and
!             complex though.}
  
!   Of course the future will demand new features from the library as it is an 
!   area of continuous development.
  
!   \section{Visions}
  
    The X desktop seems to be going into a new era and cairo is definitely the
***************
*** 817,824 ****
    importance. Plans for the creation of an X server that will use OpenGL for
    all rendering are currently being made and this library, or the work behind 
!   the library, can hopefully be usable for this purpose. 
! 
  
    \section{Acknowledgments}
    We would like to thank Carl Worth, Keith Packard, and all of the 
    people involved in the development of cairo for being helpful and
--- 820,827 ----
    importance. Plans for the creation of an X server that will use OpenGL for
    all rendering are currently being made and this library, or the work behind 
!   the library, can hopefully be usable for this purpose.
  
    \section{Acknowledgments}
+ 
    We would like to thank Carl Worth, Keith Packard, and all of the 
    people involved in the development of cairo for being helpful and