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

Sun Mar 21 16:51:22 PST 2004

Committed by: davidr

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

Modified Files:
	opengl_freenix04.tex 
Log Message:
cairo, evas and color ranges

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.33
retrieving revision 1.34
diff -C2 -d -r1.33 -r1.34
*** a/opengl_freenix04.tex	18 Mar 2004 15:50:14 -0000	1.33
--- b/opengl_freenix04.tex	22 Mar 2004 00:51:20 -0000	1.34
***************
*** 1,4 ****
! \documentclass[workingdraft]{usetex-v1}
! %\documentclass[finalversion]{usetex-v1}

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

  \usepackage{url}        
***************
*** 51,55 ****

    Part of the project is to investigate whether the level of hardware 
!   acceleration provided by the X Window System (X)~\ref{x} can be 
    improved by using \libname{} to carry out its fundamental drawing operations.

--- 51,55 ----

    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.

***************
*** 132,157 ****
    \subsection{\libname{} Fundamentals}

-   In order for \libname{} to be useful it will have to fit well into a complete
-   environment suitable for 2D graphic application developers. 
-   The challenge is to realize these ideas in the simplest and most efficient 
-   manner.
- 
    Render seems to be the ideal model to build \libname{} upon. It provides
    the necessary operations needed to carry out the rendering for 
!   modern 2D graphics applications. Hence \libname{} should be designed
    to exactly match the Render model semantics, adding an efficient
    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
!   supported graphics API available today, it is widely supported in hardware
!   and is very portable. OpenGL operates on image data as well as geometric 
!   primitives and offers the necessary operations needed for the creation of 
!   \libname{}. For these reasons the choice has been made to use OpenGL to 
!   realize the rendering in the library.

!   To fully utilize the hardware acceleration provided by OpenGL, you
!   will have to be familiar with the order of operations used in most OpenGL 
!   implementations. This is often visualized as a series of processing
    stages called the OpenGL rendering pipeline. This ordering, is not a
    strict rule of how OpenGL is implemented but provides a reliable guide
--- 132,202 ----
    \subsection{\libname{} Fundamentals}

    Render seems to be the ideal model to build \libname{} upon. It provides
    the necessary operations needed to carry out the rendering for 
!   modern 2D graphics applications. Hence \libname{} is designed
    to exactly match the Render model semantics, adding an efficient
    and more consistent hardware acceleration of the rendering process.

!   The Render model provides only low level fundamental graphics 
!   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 
!   \libname{}. 
!   
!   \begin{figure}[htbp]
!     \begin{centering}
!       \epsfig{file=layers.eps}
!       \small\itshape
!       \caption{\small\itshape Different layers involved when an application
!                               uses cairo to render to a GL surface.}
!       \label{layers}
!     \end{centering}
!   \end{figure}
!   
!   OpenGL is the obvious way to accelerate graphics output, in 2D as well as 
!   3D. Surely most pople think of OpenGL as a 3D graphics API, which is 
!   understandable because it was used primarilly for 3D applications like
!   visualizations and games in the past. However it is just as well suited for
!   the kind of 2D graphics discussed in this paper, where transformations and
!   other visual effects play a central part, much like in traditional 
!   3D applications. OpenGL is the most widely used and supported graphics 
!   API available today, it's well supported in hardware and very portable.
!   It operates on image data as well as geometric primitives and offers 
!   the necessary operations needed for the creation of \libname{}. 
!   
!   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
!   cards. The semantics of the library are designed to precisely match the
!   specification of Render. Having the same semantics as Render allows for
!   a seamless integration with the cairo library that then provides an
!   attractive environment for developing new high performance graphical
!   applications. 
! 
!   Hopefully the work presented in this paper will be useful in the design of
!   a new generation of hardware accelerated 2D graphics applications for X and 
!   the open source community in general.
! 
!   \subsection{The OpenGL Rendering Pipeline}
!   
!   To fully utilize the hardware acceleration provided by OpenGL, familiarity 
!   with the order of internal operations used in OpenGL implementations is of 
!   great importance. This is often visualized as a series of processing
    stages called the OpenGL rendering pipeline. This ordering, is not a
    strict rule of how OpenGL is implemented but provides a reliable guide
***************
*** 175,231 ****
    development of \libname{}. The vertex operations can be replaced by
    vertex programs and the fragment operations can replaced by fragment
!   programs.
! 
!   The Render model provides only low level fundamental graphics 
!   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. Together these layers would create
!   a powerful hardware accelerated 2D graphics development environment that 
!   fits well into the current X rendering model. 
! 
!   Fortunately, one big step in this direction has already been taken with 
!   the cairo library (formerly known as Xr~\cite{xr}). 
!   Cairo 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. One
!   thing missing thus far in cairo is the ability to efficiently accelerate the 
!   rendering process with today's high performance graphics hardware. 
!   The backend interface of cairo has the same semantics as Render. 
!   So \libname{} is designed to act as an additional backend for cairo 
!   providing this hardware accelerated output. Figure~\ref{layers} illustrates 
!   these ideas by showing the layers of software involved when an application 
!   uses cairo to draw accelerated output with OpenGL. 
! 
! \begin{figure}[htbp]
!     \begin{centering}
!       \epsfig{file=layers.eps}
!       \small\itshape
!       \caption{\small\itshape Different layers involved when an application
!                               uses cairo to render to a GL surface.}
!       \label{layers}
!     \end{centering}
!   \end{figure}
! 
!   To sum up these ideas, the goal was to create an interface on top of 
!   OpenGL which provides the same consistent rendering model as Render. This 
!   interface should be implemented in such a way that it can take advantage of 
!   the OpenGL hardware acceleration provided by modern graphics cards. The 
!   semantics of the library are designed to precisely match the specification 
!   of Render. Having the same semantics as Render allows for seamless 
!   integration with the cairo library that then will provide an attractive  
!   environment for developing new high performance graphical applications. 
! 
!   Hopefully the work presented in this paper will be useful in the design of
!   a new generation of hardware accelerated 2D graphics applications for X and 
!   the open source community in general.
! 
!   The reminder of this paper discusses \libname{}, which is the actual 
!   implementation of these ideas.

    \section{Related Work}

-   \edannote{Mention other 2D API's that have been layered on top of 
-             OpenGL and point out differences?}
- 
    Some of the proprietary window systems have created their own  
    graphic engines that can perform hardware accelerated rendering in a similar 
--- 220,228 ----
    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}

    Some of the proprietary window systems have created their own  
    graphic engines that can perform hardware accelerated rendering in a similar 
***************
*** 241,244 ****
--- 238,249 ----
    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
+   rendering model designed for the latest hardware extensions. Immediate
+   data is resident in graphics hardware and offscreen drawing is a 
+   native part of the rendering model.
+ 
    \section{Implementation and Design}

***************
*** 529,535 ****
        affect the choice in this case however, as anti-aliasing of text will 
        preferably be handled by the external font rendering library.
!       On high end systems this technique has potential for generating extremely 
!       high quality results with a relatively low cost. Unfortunately it is not 
!       always available for offscreens (pbuffers). 
        This means problems with indirect polygon rendering as polygons are then 
        drawn to intermediate offscreen surfaces. This technique will be used on 
--- 534,540 ----
        affect the choice in this case however, as anti-aliasing of text will 
        preferably be handled by the external font rendering library.
!       On high end systems this technique has potential for generating 
!       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 
***************
*** 591,597 ****
      hardware, \libname{} uses fragment programs in favor of performance.

-     \edannote{The number of required texture indirection instructions
-               is probably uninteresting.}
- 
      \subsubsection{Useful Convolution Kernels}

--- 596,599 ----
***************
*** 656,667 ****
      makes them ideal for representing solid colors.

!     \libname{} also support programmatic surfaces that represent color
!     gradients. Color gradients consist 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 transition vector around the 
!     center point.

      Most programmatic surfaces are implemented using fragment programs and
--- 658,678 ----
      makes them ideal for representing solid colors.

!     \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 
!     center point. The color of each fragment in these programmatic surfaces
!     is fetched from a color range, using the fragments offset along the
!     transition vector.
! 
!     A color range is a one dimensional surface. The color range data is
!     generated by the application and then transfered to graphics hardware
!     where it can be used with linear and radial patterns. This allows
!     applications to use linear and radial patterns for wide range of 
!     shading effects. e.g. linear color gradients and gaussian shading. 
!     By setting the \emph{extend} attribute of a color range to one of 
!     \emph{pad, repeat} or \emph{reflect}, the application can also control
!     what should happend when patterns try to fetch color values outside 
!     of the color range.

      Most programmatic surfaces are implemented using fragment programs and
***************
*** 674,678 ****
          \small\itshape
          \caption{\small\itshape Programmatic surfaces used for linear 
!                                 gradients}
          \label{filtered}
        \end{centering}
--- 685,689 ----
          \small\itshape
          \caption{\small\itshape Programmatic surfaces used for linear 
!                                 color gradients}
          \label{filtered}
        \end{centering}