[cairo-commit] papers/opengl_freenix04 ChangeLog,1.9,1.10 opengl_freenix04.bib,1.3,1.4 opengl_freenix04.tex,1.11,1.12

Wed Dec 17 17:09:23 PST 2003

Committed by: peter

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

Modified Files:
	ChangeLog opengl_freenix04.bib opengl_freenix04.tex 
Log Message:
Submitted version

Index: ChangeLog
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/ChangeLog,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** ChangeLog	17 Dec 2003 01:17:10 -0000	1.9
--- ChangeLog	18 Dec 2003 01:09:20 -0000	1.10
***************
*** 1,2 ****
--- 1,7 ----
+ 2003-12-17  Peter Nilsson  <c99pnn at cs.umu.se>
+ 	* opengl_freenix04.tex: Fixed some of Carls notes and submitted 
+ 	the paper.
+ 	* opengl_freenix04.bib: Changed reference to Cairo (Xr)
+ 
  2003-12-16  Peter Nilsson  <c99pnn at cs.umu.se>
  	* opengl_freenix04.tex: Fixes all around the paper	

Index: opengl_freenix04.bib
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.bib,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** opengl_freenix04.bib	16 Dec 2003 15:23:26 -0000	1.3
--- opengl_freenix04.bib	18 Dec 2003 01:09:20 -0000	1.4
***************
*** 1,4 ****
--- 1,11 ----
  % Lifted from Keiths BiBTeX database

+ @techreport{xr,
+  title		= "{Xr: Cross-device Rendering for Vector Graphics}",
+  author		= "Carl D. Worth and Keith Packard",
+  type		= "2003 Ottawa Linux Symposium",
+  month          = "July",
+  year		= 2003,			}
+ 
  @misc{cairo,
   title		= "Cairo: A Vector Graphics Library",

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** opengl_freenix04.tex	17 Dec 2003 16:52:01 -0000	1.11
--- opengl_freenix04.tex	18 Dec 2003 01:09:20 -0000	1.12
***************
*** 28,47 ****
    \section{Abstract}
    In recent years 2D graphics applications and window systems tend to 
!   use more demanding graphics features such as alpha blending, image transformations
!   and anti-aliasing. These features contribute to the user interfaces by making 
!   it possible to create more eye candy \edannote{``eye candy'' seems a bit too informal to me} as well as new usable functionalities.
!   All together it can make the graphical interface a more hospitable as well as
!   efficient environment for the user.

    In order to use these features, powerful 2D graphics engines have been 
    developed to carry out these tasks by utilizing the acceleration capabilities 
!   in modern graphics hardware. Unfortunately the X Window System~\cite{x} and 
!   the open source community doesn't quite seem to keep up with the competition 
!   in this area of development. \edannote{The authors are part of this community. Don't disparage yourselves here. This paper actually demonstrates to me that the community \textbf{can} keep up just fine.}

!   This project aims to investigate the possibilities for creating an open source
!   2D graphics library that can be used to render hardware accelerated graphics.
!   The library should also provide an attractive environment for graphical 
!   application development.

    The current implementation of this library shows speedups of 8X to 240X 
--- 28,50 ----
    \section{Abstract}
    In recent years 2D graphics applications and window systems tend to 
!   use more demanding graphics features such as alpha blending, image 
!   transformations and anti-aliasing. These features contribute to the user 
!   interfaces by making it possible to add more visual effects as well as 
!   new usable functionalities. All together it can make the graphical 
!   interface a more hospitable as well as efficient environment for the user.

    In order to use these features, powerful 2D graphics engines have been 
    developed to carry out these tasks by utilizing the acceleration capabilities 
!   in modern graphics hardware. 

!   This project aims to investigate the possibilities the for creation of an 
!   open source 2D graphics library that can be used to render hardware 
!   accelerated graphics. An analysis will also be made to tell wether the level 
!   of hardware acceleration provided by the X Window System~\cite{x} can be 
!   improved by using this library for rendering.
! 
!   Hopefully the work presented in this paper will be useful in the design of
!   a new generation of hardware accelerated graphic applications in the X 
!   Window System and the open source community in general.

    The current implementation of this library shows speedups of 8X to 240X 
***************
*** 58,63 ****
    One major improvement was made with the introduction of the X Render Extension
    (Render)~\cite{render:2000}. Render has widely been accepted as the new 
!   rendering model for the X Window System. It brought a significant performance 
!   enhancement to graphical applications. \edannote{I don't think ``performance enhancement'' is the right word here. Render provides the desired graphics operations, but the performance of the software fallback and current driver offerings is still lacking. The work of this paper is what provides a significant performance enhancement.} Some of the features that Render
    supports are alpha compositing, anti-aliasing, sub-pixel positioning, polygon 
    rendering, text rendering and image transformations. The core of Render is its
--- 61,67 ----
    One major improvement was made with the introduction of the X Render Extension
    (Render)~\cite{render:2000}. Render has widely been accepted as the new 
!   rendering model for the X Window System. It brought the desired graphics 
!   operations to the applications and thereby filled in the gaps of the 
!   core protocol. Some of the features that Render
    supports are alpha compositing, anti-aliasing, sub-pixel positioning, polygon 
    rendering, text rendering and image transformations. The core of Render is its
***************
*** 78,139 ****
    between different drivers and hardware.

!   From the benchmarks made in the context of this project (see table 1, section 
!   5) \edannote{The table is too far away to be referenced specifically. You might summarize the results of the table and just refer to the section for more details. Or you might consider bringing the table to the first page. That could increase the impact of the paper.} the amount of accelerated rendering achieved by Render doesn't seem to be 
!   enough for the complex visual effects addressed by this project. This 
!   particular benchmark is run on a Nvidia system but similar results were 
    attained with Matrox drivers, which have been known for having the best 
    acceleration support for Render in the past.

    There was also another benchmark application called Renderbench released not 
!   too long ago by the people behind \edannote{``the people behind'' is informal and vague. Use their actual names.} imlib2~\cite{imlib2} that compared the 
!   performance of Imlib2 to that of Render. Imlib2 is an image processing library 
!   that uses MMX among other things to accelerate render operations. This 
!   benchmark attracted a lot of attention as it clearly shows the superior 
!   rendering performance of imlib2 compared to Render. A detailed comparison 
!   between Imlib2 and the software developed in this project will be presented in
!   the full paper.

    The performance of Render has been quite sufficient for some time now, but in 
    the past years graphical user interfaces seem to have gone into a new era with
!   the presence of much more demanding visual effects like alpha blending, image 
    transformations and anti-aliasing.

!   \edannote{The remainder of the introduction is longer than it needs to be. There is some redundant text here. In general it could be cleaned up, (but perhaps you'll just want to wait for the final paper).}
    Even with today's powerful computers these tasks constitute a heavy burden on 
    the CPU. To relieve the CPU, modern window systems have developed 2D-graphics
    engines which utilize the high performance rendering capabilities inherent in 
!   today's graphics hardware. In fact, much of the eye candy that can be seen in 
!   these systems wouldn't even be feasible without hardware accelerated 
!   rendering. 

!   The fact that this is a field in which the X Window System and the 
!   open source community doesn't quite seem to keep up is what originally led up 
!   to the ideas behind this project. The main idea is to investigate the 
!   potential usefulness of a 2D graphics library that can be 
!   accelerated by graphics hardware to create a high performance rendering 
!   environment similar to those used in some of the competing window systems. 
!   The challenge is to realize these ideas in the simplest and most efficient manner.

    These ideas require a complete 2D graphics API that is accelerated by graphics
    hardware. Fortunately, one big step in this direction has already been taken 
!   with the cairo library~\cite{cairo}. Cairo is a modern, open source, 
!   cross-platform 2D graphics API designed for multiple output devices. The backend interface of cairo has the same semantics as Render
!   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 accelerate the rendering 
    process with today's high performance graphics hardware. So the library 
    developed in this project is designed to act as an additional 
!   backend for cairo providing this hardware accelerated output. Figure 1 
!   illustrates these ideas by showing the the layers of software involved when an
!   application uses cairo to draw accelerated output with GLX. These layers 
!   are more described in subsequent sections.

    \begin{figure}[htbp]
      \begin{centering}
!       \epsfig{file=layers.eps, width=2.0in, height=2.5in}
        \small\itshape
        \caption{\small\itshape Different software layers involved when an
          application uses cairo to render to a GLX surface.}
!       \label{fig1}
      \end{centering}
    \end{figure}
--- 82,149 ----
    between different drivers and hardware.

!   From the benchmarks made in the context of this project the conclusion can 
!   be drawn that the amount of accelerated rendering achieved by Render doesn't 
!   seem to be enough for the complex visual effects addressed by this project. 
!   See section 5 Results and Conclusions for a documented benchmark test.
!   This particular benchmark is run on a Nvidia system but similar results were 
    attained with Matrox drivers, which have been known for having the best 
    acceleration support for Render in the past.

    There was also another benchmark application called Renderbench released not 
!   too long ago by Carsten Haitzler (a.k.a Rasterman) that compared the 
!   performance of Imlib2~\cite{Imlib2} to that of Render. Imlib2 is an image 
!   processing library that uses MMX among other things to accelerate render 
!   operations. This benchmark attracted a lot of attention as it clearly shows 
!   the superior rendering performance of Imlib2 compared to Render. A detailed 
!   comparison between Imlib2 and the software developed in this project will 
!   be presented in the full paper.

    The performance of Render has been quite sufficient for some time now, but in 
    the past years graphical user interfaces seem to have gone into a new era with
!   the presence of more demanding visual effects like alpha blending, image 
    transformations and anti-aliasing.

!   \edannote{The remainder of the introduction is longer than it needs to be. 
!     There is some redundant text here. In general it could be cleaned up, 
!     (but perhaps you'll just want to wait for the final paper).}
! 
    Even with today's powerful computers these tasks constitute a heavy burden on 
    the CPU. To relieve the CPU, modern window systems have developed 2D-graphics
    engines which utilize the high performance rendering capabilities inherent in 
!   today's graphics hardware. In fact, much of the visual effects and advanced 
!   graphics that can be seen in these systems wouldn't even be feasible without 
!   hardware accelerated rendering. 

!   The main idea behind this project is to investigate the potential usefulness 
!   of a 2D graphics library that can be accelerated by graphics hardware to 
!   create a high performance rendering environment. Furthermore these ideas
!   will be applied to The X Window System to see if they can be used to improve
!   hardware acceleration of graphical applications in that context. 
!  
!   The challenge is to realize these ideas in the simplest and most efficient 
!   manner.

    These ideas require a complete 2D graphics API that is accelerated by graphics
    hardware. 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. The backend interface of cairo has the same semantics
!   as Render. 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 accelerate the rendering 
    process with today's high performance graphics hardware. So the library 
    developed in this project is designed to act as an additional 
!   backend for cairo providing this hardware accelerated output. 
!   Figure~\ref{layers} illustrates these ideas by showing the the layers of 
!   software involved when an application uses cairo to draw accelerated output 
!   with GLX. These layers are more described in subsequent sections.

    \begin{figure}[htbp]
      \begin{centering}
!       \epsfig{file=layers.eps, width=2.5in, height=3.0in}
        \small\itshape
        \caption{\small\itshape Different software layers involved when an
          application uses cairo to render to a GLX surface.}
!       \label{layers}
      \end{centering}
    \end{figure}
***************
*** 170,179 ****
    \section{Related Work}
    Some of the commercially developed window systems have created their own 3D 
!   graphic engines that can perform hardware accelerated rendering in a similar manner to 
!   the model discussed here. The one that has probably attracted the most 
!   attention is Apple's Quartz Extreme~\cite{quartzextreme} compositing engine 
!   used in Mac OS X. The user interface in Max OS X is loaded with advanced 
!   graphics effects of the nature discussed in this paper. They all seem to run 
!   smoothly without bringing too much load on the CPU.

    The final paper will contain a study of these competing systems as well as a 
--- 180,189 ----
    \section{Related Work}
    Some of the commercially developed window systems have created their own 3D 
!   graphic engines that can perform hardware accelerated rendering in a similar 
!   manner to the model discussed here. The one that has probably attracted the 
!   most attention is Apple's Quartz Extreme~\cite{quartzextreme} compositing 
!   engine used in Mac OS X. The user interface in Max OS X is loaded with 
!   advanced graphics effects of the nature discussed in this paper. They all seem
!   to run smoothly without bringing too much load on the CPU.

    The final paper will contain a study of these competing systems as well as a 
***************
*** 194,199 ****

    As of now the the only implemented backend is for GLX, which is a GL layer 
!   used on Unix like systems to provide a glue layer between OpenGL and the X Window 
!   System. Backends for other GL layers will be added on request.

    For any usable 2D graphics API, offscreen drawing is required. This is 
--- 204,209 ----

    As of now the the only implemented backend is for GLX, which is a GL layer 
!   used on Unix like systems to provide a glue layer between OpenGL and the X 
!   Window System. Backends for other GL layers will be added on request.

    For any usable 2D graphics API, offscreen drawing is required. This is 
***************
*** 213,219 ****
    are most likely to be used, which is the case for the GLX backend.

!   The general composite operation is the fundamental rendering part of the 
!   library \\edannote{which library?}. It takes two source surfaces and one destination surface, where the 
!   second of the two source surfaces is the optional mask surface. \edannote{This description of the render operator is hard to follow. One thing that might help is a mathematical description: dst = src IN mask OP dst. Even better would be a nice figure using small images to graphically depict the operation. Again, this can wait for the final paper.}  If a mask 
    surface is supplied, an intermediate surface is created and the first source 
    is rendered on it using the SRC operator. In the next step the mask surface is
--- 223,233 ----
    are most likely to be used, which is the case for the GLX backend.

!   The general composite operation is the fundamental part of the rendering 
!   model. It takes two source surfaces and one destination surface, where the 
!   second of the two source surfaces is the optional mask surface. 
!   \edannote{This description of the render operator is hard to follow. 
!     One thing that might help is a mathematical description: dst = src IN mask 
!     OP dst. Even better would be a nice figure using small images to graphically
!     depict the operation. Again, this can wait for the final paper.} If a mask 
    surface is supplied, an intermediate surface is created and the first source 
    is rendered on it using the SRC operator. In the next step the mask surface is
***************
*** 227,239 ****
    Most parts of the Render specification have been implemented but there are
    still some issues that need to be addressed. The most obvious one being the 
!   implementation of an anti-aliasing model. There are several different approaches, some 
!   of which require specific hardware support. Part of the problem
!   is that when used with cairo, primitives are drawn in immediate mode, which 
!   means that they are drawn in the order which the end application wishes. This 
!   means some complications when drawing correctly anti-aliased polygons with 
!   OpenGL in the old-fashioned way. \edannote{I have no idea what the ``old-fashioned'' approach is. Describe what it actually does instead.} The final paper will have a detailed 
    description of the chosen model along with a motivation.

- 
    \section{Results and Conclusion}
    Right now the library hasn't really been tested that much in real applications
--- 241,255 ----
    Most parts of the Render specification have been implemented but there are
    still some issues that need to be addressed. The most obvious one being the 
!   implementation of an anti-aliasing model. There are several different 
!   approaches, some of which require specific hardware support. Part of the 
!   problem is that when used with cairo, primitives are drawn in immediate mode, 
!   which means that they are drawn in the order which the end application wishes.
!   This means some complications when drawing correctly anti-aliased polygons 
!   with OpenGL in the traditional way, enabling the built in polygon smooth 
!   option. Problems occur because it requires that polygons are drawn 
!   in front to back order for correct results. This model is also poorly 
!   supported by older graphics hardware. The final paper will have a detailed 
    description of the chosen model along with a motivation.

    \section{Results and Conclusion}
    Right now the library hasn't really been tested that much in real applications
***************
*** 241,247 ****
    utilities for cairo have been ported to use the new GL backend though. The 
    results have been satisfying both with respect to performance and accuracy. 
!   Figures~\ref{cairo-demo-xrender} and \ref{cairo-demo-glc} show a part of the output from the cairo-demo application.
!   Figure~\ref{cairo-demo-xrender} shows output from cairo-demo using xrender and Figure~\ref{cairo-demo-glc} shows the 
!   corresponding output using the GL backend for rendering.

    \begin{figure}[htbp]
--- 257,264 ----
    utilities for cairo have been ported to use the new GL backend though. The 
    results have been satisfying both with respect to performance and accuracy. 
!   Figures~\ref{cairo-demo-xrender} and \ref{cairo-demo-glc} show a part of the 
!   output from the cairo-demo application. Figure~\ref{cairo-demo-xrender} shows 
!   output from cairo-demo using xrender and Figure~\ref{cairo-demo-glc} shows 
!   the corresponding output using the GL backend for rendering.

    \begin{figure}[htbp]
***************
*** 276,288 ****

    A simple benchmark application was also written to compare the rendering 
!   performance with cairo, using the different rendering backend including xrender, 
!   images (pure software) and the GL backend developed in this project. 
    This benchmark application, called cairobench, currently contains two 
    separate tests. 

!   The first 
!   test animates a semi-transparent, stroked and filled cairo path made up of 
!   several bezier curves that moves randomly over a simple background image. 
!   This test shows the speed at which transparent trapezoids can be 
    drawn using cairo paths. 

--- 293,304 ----

    A simple benchmark application was also written to compare the rendering 
!   performance with cairo, using the different rendering backends including 
!   xrender, images (pure software) and the GL backend developed in this project. 
    This benchmark application, called cairobench, currently contains two 
    separate tests. 

!   The first test animates a semi-transparent, stroked and filled cairo path 
!   made up of several bezier curves that moves randomly over a simple background 
!   image. This test shows the speed at which transparent trapezoids can be 
    drawn using cairo paths. 

***************
*** 292,298 ****

    On all the systems on which the tests have currently been run, performance has
!   increased multiple times when rendering with the new GL backend. Table~\ref{tab:cairobench}
!   shows test results from a tested system. More tests will be presented in the
!   full report.

    \begin{table}[htbp]
--- 308,314 ----

    On all the systems on which the tests have currently been run, performance has
!   increased multiple times when rendering with the new GL backend. 
!   Table~\ref{tab:cairobench} shows test results from a tested system. More tests
!   will be presented in the full report.

    \begin{table}[htbp]
***************
*** 316,325 ****
      in the speedup?}

!   There has also been some benchmarking of imlib2 compared to the software
    developed here. A benchmark utility called Renderbench was recently 
!   released that points out the superior rendering performance of imlib2
    compared to that of Render. Renderbench has been ported to instead test 
!   the performance of imlib2 compared to the library developed here. 
!   Although imlib2 is very fast at some tasks, still in most cases it can't 
    compare to the rendering capabilities of OpenGL. This paper currently lacks 
    concrete results from these tests but a more detailed comparison will
--- 332,345 ----
      in the speedup?}

!   These results suggest a speedup of about 4X to 240X when using OpenGL
!   for rendering compared to Render. It seems that graphical applications have
!   a lot to gain from using a 2D API with OpenGL accelerated rendering. 
! 
!   There has also been some benchmarking of Imlib2 compared to the software
    developed here. A benchmark utility called Renderbench was recently 
!   released that points out the superior rendering performance of Imlib2
    compared to that of Render. Renderbench has been ported to instead test 
!   the performance of Imlib2 compared to the library developed here. 
!   Although Imlib2 is very fast at some tasks, still in most cases it can't 
    compare to the rendering capabilities of OpenGL. This paper currently lacks 
    concrete results from these tests but a more detailed comparison will
***************
*** 378,381 ****
--- 398,402 ----
    funding in terms of study allowances. 

+   \newpage

    \section{Availability}