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

Sat Mar 27 05:12:46 PST 2004

Committed by: davidr

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

Modified Files:
	opengl_freenix04.tex 
Log Message:
clipping, polygons...

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.34
retrieving revision 1.35
diff -C2 -d -r1.34 -r1.35
*** a/opengl_freenix04.tex	22 Mar 2004 00:51:20 -0000	1.34
--- b/opengl_freenix04.tex	27 Mar 2004 13:12:43 -0000	1.35
***************
*** 1,4 ****
! %\documentclass[workingdraft]{usetex-v1}
! \documentclass[finalversion]{usetex-v1}

  \usepackage{url}        
--- 1,4 ----
! \documentclass[workingdraft]{usetex-v1}
! %\documentclass[finalversion]{usetex-v1}

  \usepackage{url}        
***************
*** 47,54 ****
    This project investigates the potential usefulness of an open source
    implementation of such a graphics engine. We present \libname, 
!   a portable open source 2D graphics library that can 
!   be used to render hardware accelerated graphics.

!   Part of the project is to investigate whether the level of hardware 
    acceleration provided by the X Window System (X)~\cite{x} can be 
    improved by using \libname{} to carry out its fundamental drawing operations.
--- 47,58 ----
    This project investigates the potential usefulness of an open source
    implementation of such a graphics engine. We present \libname, 
!   a portable open source 2D graphics library that can be used to render 
!   hardware accelerated graphics.

!   \libname{} is layered on top of OpenGL~\cite{gl:1.2.1} and is designed 
!   to act as an additional backend for cairo (formerly known as Xr~\cite{xr}), 
!   providing it with hardware accelerated output.
! 
!   Part of the project is to investigate how the level of hardware 
    acceleration provided by the X Window System (X)~\cite{x} can be 
    improved by using \libname{} to carry out its fundamental drawing operations.
***************
*** 82,87 ****

    The main idea behind this project is to investigate the potential usefulness 
!   of an open source 2D graphics library that can use this acceleration to 
!   create a high performance rendering environment. 

    Furthermore these ideas have been applied to X to see if they could
--- 86,91 ----

    The main idea behind this project is to investigate the potential usefulness 
!   of \libname{}, an open source 2D graphics library that can use this 
!   acceleration to create a high performance rendering environment. 

    Furthermore these ideas have been applied to X to see if they could
***************
*** 141,158 ****
    operations, not always suitable for direct use by application developers.  
    A higher level graphics API is needed on top of the Render model to make 
!   it useful for this purpose. The cairo library (formerly known 
!   as Xr~\cite{xr}) is a modern, open source, cross-platform 2D graphics
!   API designed for multiple output devices. With its PDF~\cite{pdf14}-like 
!   2D graphics API it provides an attractive and powerful vector based 
!   drawing environment. Cairo uses a backend system to realize it's 
!   multiple output formats. One thing missing thus far in cairo though, 
!   is a backend that efficiently accelerates the rendering process 
!   with today's high performance graphics hardware. 
!   The backend interface of cairo has the same semantics as Render. 
    Thus \libname{} is designed to act as an additional backend for cairo 
    providing this hardware accelerated output. 

    The output of \libname{} is accelerated in hardware by using 
!   OpenGL~\cite{gl:1.2.1} for all rendering operations. Figure~\ref{layers} 
    illustrates these ideas by showing the layers of software involved when an 
    application uses cairo to draw hardware accelerated graphics through 
--- 145,161 ----
    operations, not always suitable for direct use by application developers.  
    A higher level graphics API is needed on top of the Render model to make 
!   it useful for this purpose. The cairo library is a modern, open source, 
!   cross-platform 2D graphics API designed for multiple output devices. 
!   With its PDF~\cite{pdf14}-like 2D graphics API it provides an attractive 
!   and powerful vector based drawing environment. 
!   Cairo uses a backend system to realize it's multiple output formats. 
!   One thing missing thus far in cairo though, is a backend that efficiently 
!   accelerates the rendering process with today's high performance graphics 
!   hardware. The backend interface of cairo has the same semantics as Render. 
    Thus \libname{} is designed to act as an additional backend for cairo 
    providing this hardware accelerated output. 

    The output of \libname{} is accelerated in hardware by using 
!   OpenGL for all rendering operations. Figure~\ref{layers} 
    illustrates these ideas by showing the layers of software involved when an 
    application uses cairo to draw hardware accelerated graphics through 
***************
*** 208,225 ****
        \small\itshape
        \caption{\small\itshape The OpenGL Rendering Pipeline}
!       \label{layers}
      \end{centering}
    \end{figure}

    The latest generation of graphics hardware allow the application to 
!   replace the vertex operations and fragment operations processing stages
!   shown in figure~\ref{layers} with application defined computations.
!   These computations are defined with assembler-like languages and can be sent
!   to graphics hardware where they are compiled and run. They provide an
!   attractive feature that has been proven very useful in the 
!   development of \libname{}. The vertex operations can be replaced by
!   vertex programs and the fragment operations can replaced by fragment
!   programs. These features add a flexibility to OpenGL that makes it ideal 
!   for this type of experimental development.

    \section{Related Work}
--- 211,227 ----
        \small\itshape
        \caption{\small\itshape The OpenGL Rendering Pipeline}
!       \label{pipe}
      \end{centering}
    \end{figure}

    The latest generation of graphics hardware allow the application to 
!   replace the conventional per-vertex calculations and per-fragment
!   calculations done in the vertex operations and fragment operations 
!   processing stages shown in figure~\ref{pipe} with application defined
!   computations. These computations are defined with assembler-like
!   languages that an OpenGL implementation compiles into vertex and
!   fragment programs. The vertex and fragment programs provides an
!   interface for directly accessing hardware and has been proven very
!   useful in the development of \libname{}.

    \section{Related Work}
***************
*** 238,243 ****
    being developed under the name Windows Longhorn~\cite{longhorn}.

!   The Open Source world has also a set of graphics libraries that 
!   have been layered on top of OpenGL. e.g. Evas; a hardware accelerated 
    canvas API which is part the Enlightenment Foundation Libraries. 
    \libname{} is unique regards to these libraries by using an immediate
--- 240,245 ----
    being developed under the name Windows Longhorn~\cite{longhorn}.

!   \libname{} isn't the first Open Source graphics libraries that 
!   has been layered on top of OpenGL. e.g. Evas; a hardware accelerated 
    canvas API which is part the Enlightenment Foundation Libraries. 
    \libname{} is unique regards to these libraries by using an immediate
***************
*** 438,447 ****
        \subsubsection{Indirect Polygons}

!       When \libname{} renders indirect polygons an intermediate offscreen
!       surface containing only an alpha channel is created. The polygons are 
!       then rendered onto this surface. The intermediate surface
!       is then used as mask when compositing the supplied source surface
!       onto the destination surface. Indirect polygons can be used for
!       pattern filling of complex objects.

        \subsubsection{Anti-aliasing}
--- 440,462 ----
        \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}
***************
*** 450,454 ****
        occur whenever an analog signal is point sampled to convert it into
        a digital signal, and the sample rate is to low.
!       The number of samples don' contain enough information to represent the 
        actual source signal. Instead the samples seem to represent a different 
        signal of lower frequency, called an aliased signal.
--- 465,469 ----
        occur whenever an analog signal is point sampled to convert it into
        a digital signal, and the sample rate is to low.
!       The number of samples don't contain enough information to represent the 
        actual source signal. Instead the samples seem to represent a different 
        signal of lower frequency, called an aliased signal.
***************
*** 508,527 ****
        immediate rendering model used in \libname.

!       The anti-aliasing model chosen for \libname{} is a combination of
!       full-scene anti-aliasing using hardware assist and using OpenGL's 
!       built in polygon smooth hint. 

!       These techniques have been found suitable because they are easy to use 
!       without complicating the structure of the rendering model, they are
!       relatively fast and produce adequate results in real-time rendering. 
!       The other techniques have been discarded mainly due to poor hardware 
!       support, high memory consumption, bad performance or poor results.
!   
!       The chosen techniques are supported in most consumer level graphics 
!       hardware since at least three graphic card generations back. 
!       As \libname{} already needs other relatively new features e.g 
!       pbuffer support to provide full functionality these latest generations 
!       of graphics hardware belong to the group of users already targeted. 
!   
        Full-scene anti-aliasing using hardware assist is typically
        implemented as multi-sampling, sometimes super-sampling. This is a 
--- 523,539 ----
        immediate rendering model used in \libname.

!       The anti-aliasing model chosen for \libname{} is very flexible
!       and other techniques can easily be added for special cases later on.
!       The current implementation uses hardware assisted full-scene 
!       anti-aliasing. 

!       This technique has been found suitable because it has a functional
!       easy to use interface in OpenGL (through the multisampling extension) 
!       and it fits well into \libname{} without complicating the structure 
!       of the rendering model. It is relatively fast on current hardware and 
!       it produces adequate results in real-time rendering. The trend among 
!       graphics hardware manufacturers seems to be to support multisampling 
!       more in new products. 
!      
        Full-scene anti-aliasing using hardware assist is typically
        implemented as multi-sampling, sometimes super-sampling. This is a 
***************
*** 537,561 ****
        extremely high quality results with a relatively low cost. Unfortunately 
        it is not always available for offscreen buffers (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.
! 
!       OpenGL's built in polygon smooth hint is perhaps the most common
!       and naive way to draw anti-aliased polygons with OpenGL.
!       This technique is normally used for drawing geometric primitives
!       with pixel coverage information (`smooth' points, lines and 
!       polygons in OpenGL terminology). In order for this to work correctly
!       one needs to draw primitives in front to back order using the 
!       saturate blending operator. This means some problems in the rendering
!       model used by \libname{} as all primitives are drawn in 
!       immediate mode, meaning that they are drawn in the order which the end 
!       application wishes. If drawing is done with some other blending 
!       operator artifacts may appear where primitives intersect. This is 
!       known as the abutting edges problem. However when this technique is
!       used the right way it produces good-quality results for silhouette
!       edges and shared edges. This technique can only be used for indirect
!       polygons, as it will cause artifacts when used on direct drawing. It 
!       acts as a fallback when multi-sampling isn't available for offscreen
!       surfaces when rendering indirect polygons.

      \subsection{Text Rendering}
--- 549,555 ----
        extremely high quality results with a relatively low cost. Unfortunately 
        it is not always available for offscreen buffers (pbuffers). 
!  
!       The other techniques have been discarded mainly due to poor hardware
!       support, high memory consumption, bad performance or poor results.

      \subsection{Text Rendering}
***************
*** 571,574 ****
--- 565,575 ----
      tests have proven that this will increase glyph rendering speed to
      at least 200000 glyphs/sec.
+ 
+     \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}
***************
*** 1014,1018 ****
        	      & im-on  & im-off & xr-on  & xr-off & gl-on & gl-off \\
        	\hline \hline
!         grad  & 23.553 & 6.139  & -      & -      & 1.463 & 1.448  \\
          \end{tabular}   
        \end{footnotesize}
--- 1015,1019 ----
        	      & im-on  & im-off & xr-on  & xr-off & gl-on & gl-off \\
        	\hline \hline
!         grad  & 23.553 & 6.139  & -      & -      & 1.013 & 1.009  \\
          \end{tabular}   
        \end{footnotesize}
***************
*** 1050,1054 ****
           tri2  & 1.584      & 1.671    &   0.055 & 0.074  \\
           \hline
!          grad  & -          & -        &   1.463 & 1.448  \\
           \hline
          \end{tabular}   
--- 1051,1055 ----
           tri2  & 1.584      & 1.671    &   0.055 & 0.074  \\
           \hline
!          grad  & -          & -        &   1.013 & 1.009  \\
           \hline
          \end{tabular}   