[cairo-commit] papers/opengl_freenix04 layers.eps,NONE,1.1 layers.png,NONE,1.1 ChangeLog,1.6,1.7 opengl_freenix04.tex,1.5,1.6

Mon Dec 15 17:23:11 PST 2003

Committed by: peter

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

Modified Files:
	ChangeLog opengl_freenix04.tex 
Added Files:
	layers.eps layers.png 
Log Message:
Some notes addressed

--- NEW FILE: layers.eps ---
%!PS-Adobe-2.0 EPSF-2.0
%%Creator: pnmtops
%%Title: noname.ps
%%Pages: 1
%%BoundingBox: 5 251 211 511
%%EndComments
/readstring {
  currentfile exch readhexstring pop
} bind def
/rpicstr 300 string def
/gpicstr 300 string def
/bpicstr 300 string def
%%EndProlog
%%Page: 1 1
gsave
5.4 251.382 translate
205.2 259.236 scale
300 379 8
[ 300 0 0 -379 0 379 ]
[...11358 lines suppressed...]
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000009faffffffffffffffffffffffffffffff
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000009faffffffffffffffffffffffffffffff
grestore
showpage
%%Trailer

--- NEW FILE: layers.png ---
(This appears to be a binary file; contents omitted.)

Index: ChangeLog
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/ChangeLog,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** ChangeLog	15 Dec 2003 16:33:20 -0000	1.6
--- ChangeLog	16 Dec 2003 01:23:09 -0000	1.7
***************
*** 1,2 ****
--- 1,7 ----
+ 2003-12-16  Peter Nilsson  <c99pnn at cs.umu.se>
+          * layers.png:
+          * layers.eps: Added a sketch diagram
+          * opengl_freenix04.tex: Restructured and rewrote a lot
+ 
  2003-12-15  Peter Nilsson  <c99pnn at cs.umu.se>
  	 * cairo-demo-glc.png:

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** opengl_freenix04.tex	15 Dec 2003 16:33:20 -0000	1.5
--- opengl_freenix04.tex	16 Dec 2003 01:23:09 -0000	1.6
***************
*** 5,9 ****
  \usepackage{url}        
  \usepackage{isolatin1}  
- 
  \usepackage{epsfig}
  \usepackage{url}        % \url{} command with good linebreaks
--- 5,8 ----
***************
*** 30,106 ****

    \section{Abstract}
!   \edannote{A short abstract here could do a lot to help the reader understand the main points of the paper.}

    \section{Introduction}
!   The X Render Extension (Render)~\cite{render:2000} has now been around for a 
!   few years and has widely been accepted as the new rendering model for the X 
!   Window System~\cite{x}. \edannote{The phrase ``been around for a few years'' is unnecessarily vague. Either be more specific, or just drop this phrase, (which would work fine too).}  Some of the features that Render today supports are 
!   alpha compositing, anti-aliasing, sub-pixel positioning, polygon rendering, 
!   text rendering and image transformations. The core of Render is its image 
!   compositing model which borrows fundamental notions from the Plan 9 window 
!   system~\cite{pike:draw}. Render provides a unified rendering operation which 
!   supports the Porter-Duff~\cite{porterduff:1984} style compositiing operators.
!   All pixel manipulations are done through this operation. This provides for 
!   a simple and consistent model throughout the rendering system. 

    Although Render can be accelerated by graphics hardware using XAA~\cite{xaa} 
!   to some extent, \edannote{To what extent? Can you be more specific here? Are there identifiable limitations in the XAA hooks for Render?} it requires graphics driver developers to add support for this
!   in each driver. \edannote{Point out the problem here. Specifically that there is duplicated effort and that acceleration support for Render is inconsistent between drivers.} It's probably fair to say that so far, the few drivers which 
!   do support this only do so with modest results. \edannote{As written, this is vague and unsubstantiated. Can you point to some specific benchmark? For example, didn't the rasterman run some Render benchmark not too long ago?}

-   \edannote{As mentioned below, the ideas of this paragraph should be moved to a Related Work section.}
-   In the past years modern 2D graphics applications like window systems 
-   tend to use more demanding graphic features like alpha blending, image 
-   transformations and anti-aliasing.
    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 we have seen in these
!   systems wouldn't even be feasible without hardware accelerated rendering.
!   The one that has probably attracted the most attention is Apple's Quartz 
!   Extreme~\cite{quartzextreme} compositing engine used in Mac OS X. Rumor also 
!   says that Microsoft will add something similar to their upcoming product, at 
!   this time called Longhorn~\cite{longhorn}. \edannote{A technical paper shouldn't cite rumours. Either find a documentable source for your information or leave it out. And if there isn't published information about a related system, then you aren't obligated to compare your work to it.}

!   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 rendering environment similar 
!   to those used in the other window systems mentioned above. How would one 
!   go about realizing these ideas in the simplest and most efficient manner? \edannote{I don't like the use of a rhetorical question here. Maybe something like, ``The challenge is to realize these ideas\ldots''}

!   \edannote{The introduction moves between discussion of the complete graphics system and two of its compoenent parts (cairo and Render) in a way that would be difficult to follow for a reader that is unfamiliar with the system. Perhaps one way to improve this is to first discuss the entire system, then discuss how it is composed of separate layers. A diagram or two would also be quite helpful.}
!   What we need is a complete 2D graphics API that is accelerated by
!   graphics hardware. \edannote{This should be rewrittend to avoid use of the first-person pronoun ``we''.} Much of the work has already been done as we are very 
!   fortunate to have the Cairo library~\cite{cairo}, an open source 
!   library which provides a PDF-like 2D graphics API. One 
!   thing missing thus far in Cairo is the ability to accelerate the rendering 
!   process  with today's high performance graphics hardware. 
!   The Cairo library is a modern cross-platform 2D graphics API designed 
!   for multiple output formats with Render semantics and provides a powerful 
!   vector based drawing environment. So what we need is an output format for 
!   Cairo that can be fully hardware accelerated. OpenGL is the most widely used 
!   and supported graphics API available today, it has great support for hardware 
!   acceleration and is very portable. 

!   Is it possible to create an interface on top of OpenGL which would provide 
!   the same consistent rendering model as Render? And can the interface be 
!   implemented in such a way that it can take advantage of the OpenGL hardware 
!   acceleration provided by modern graphics cards? \edannote{Again, rewrite to eliminate rhetorical questions.}

!   The complete paper will present results from
!   extensive research to find and evaluate the possibilities of OpenGL
!   hardware acceleration of operations needed for the creation of a 
!   Render-like interface on top of OpenGL. This research is concluded with 
!   the implementation of an OpenGL 2D compositing library. The semantics of the
    library are designed to precisely match the specification of the 
    X Render extension. Having the same semantics as Render allows for seamless 
    integration with the Cairo library that then will provide an attractive
!   environment for developing new graphical applications. The paper will 
!   describe the solutions we have chosen for the library and the problems that
!   we have encountered in the development process. Furthermore the paper will 
!   also include test and benchmarking results that points out the performance and
!   accuracy of the library on various hardware. 

    The development of the 2D compositing library and the other implementation
--- 29,151 ----

    \section{Abstract}
!   In the past years modern 2D graphics applications like window systems tend 
!   to use more demanding graphic features like alpha blending, image 
!   transformations and anti-aliasing. These features contribute to the user interfaces
!   by making it possible to create more eye candy 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. 
+ 
+   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.
+   
+   
    \section{Introduction}
!   \edannote{Is this introduction easier to follow now?}
!   Originally the X Window System wasn't designed for any of the advanced graphics
!   that can bee seen on modern desktops today. For a long time it suffered from 
!   very poor graphics performance.
! 
!   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. Some of the features
!   that Render today supports are alpha compositing, anti-aliasing, sub-pixel 
!   positioning, polygon rendering, text rendering and image transformations. The 
!   core of Render is its image compositing model which borrows fundamental 
!   notions from the Plan 9 window system~\cite{pike:draw}. Render provides a 
!   unified rendering operation which supports the 
!   Porter-Duff~\cite{porterduff:1984} style compositing operators. All pixel 
!   manipulations are carried out through this operation. This provides for a simple and 
!   consistent model throughout the rendering system. 

    Although Render can be accelerated by graphics hardware using XAA~\cite{xaa} 
!   to some extent, 
!   \edannote{To what extent? Can you be more specific here? Are 
!     there identifiable limitations in the XAA hooks for Render?} 
!   it requires graphics driver developers to add support for this it requires graphics 
!   driver developers to add support for this
!   in each driver. 
!   \edannote{Point out the problem here. Specifically that there is duplicated 
!     effort and that acceleration support for Render is inconsistent between drivers.}
!   It's probably fair to say that so far, the 
!   few drivers which do support this only do so with modest results. 
!   \edannote{As written, this is vague and unsubstantiated. Can you point to some specific 
!     benchmark? For example, didn't the rasterman run some Render benchmark not too long ago?}
!   Even though this has been sufficient for some time now, the graphical user 
!   interfaces seem to have gone into a new era with the presence of demanding 
!   visual effects like alpha blending, image transformations and anti-aliasing.

    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 formats with Render semantics.
!   With it's 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 should clearly be designed to act as an 
!   additional backend for Cairo providing this hardware accelerated output. 

!   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 has great support for hardware acceleration and is 
!   very portable. For these reasons the choice has been made to use OpenGL 
!   to realize the rendering in the library.

!   Hence, the goal is 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 the 
    X Render extension. 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. 
!   
!   \begin{figure}[htbp]
!     \begin{centering}
!       \epsfig{file=layers.eps, width=3.0in, height=3.5in}
!       \small\itshape
!       \caption{\small\itshape A ruff sketch of the different layers used when an
! 	application uses Cairo to render to a GLX surface.}
!       \label{fig1}
!     \end{centering}
!   \end{figure}
! 
!   \edannote{I really dont know about this huge block diagram :)}
! 
!   The complete paper will present results from extensive research to find 
!   and evaluate the possibilities of OpenGL hardware acceleration of operations 
!   needed for the creation of a Render-like interface on top of OpenGL. 
!   This research is concluded with the implementation of an OpenGL 2D compositing 
!   library. The paper will describe the problems encountered in the development 
!   process as well as the chosen solutions. 
!   Furthermore the paper will also include test and benchmarking results that 
!   points out the performance and accuracy of the library on various hardware. 

    The development of the 2D compositing library and the other implementation
***************
*** 108,116 ****
    community is regarded.

    \section{Related Work}
!   \edannote{I think the introduction would be more clear if it focused
!     exclusively on your own work. Then, you can move the discussion of
!     related systems such as QuartzExtreme and Longhorn to this related
!     work section.}

--- 153,167 ----
    community is regarded.

+ 
    \section{Related Work}
!   Some of the commercially developed window systems have developed 3D graphic engines 
!   that can render hardware accelerated in a similar manner to the model that is 
!   developed 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 final paper will contain a study of these competing systems as well as 
!   a discussion about their performance compared to the software developed 
!   in this project.

***************
*** 126,132 ****
    multiple GL layers.

!   As of now the GLX backend is the only backend implemented but on request,
!   backends for other GL layers will be added. \edannote{The term GLX is introduced here without any explanation. Describe what it is, on what platforms it is available, etc.}
! 
    For any usable 2D graphics API, offscreen drawing is required. This is 
    something GL has lacked efficient support for until recently. However, as this 
--- 177,184 ----
    multiple GL layers.

!   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 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 
    something GL has lacked efficient support for until recently. However, as this 
***************
*** 168,172 ****
    means some complications when drawing correctly anti-aliased polygons with 
    OpenGL in the old-fashioned way. The final paper will have a detailed 
!   description of the model we have chosen and why we choose that model.

--- 220,224 ----
    means some complications when drawing correctly anti-aliased polygons with 
    OpenGL in the old-fashioned way. The final paper will have a detailed 
!   description of the chosen model along with a motivation.

***************
*** 180,188 ****
    Figure 1 shows output from cairo-demo using xrender and figure 2 shows the 
    corresponding output using the GL backend for rendering.
!   Of course these pictures cannot be expected to show any great details of the 
!   result but it might give a rough idea about the accuracy of the output. 
!   Note that no anti-aliasing is applied to the image rendered by GL as it is not
!   yet implemented in a stable fashion. Yet you can see that the image rendered by
!   GL compares rather well to that rendered by xrender. 

    \begin{figure}[htbp]
--- 232,236 ----
    Figure 1 shows output from cairo-demo using xrender and figure 2 shows the 
    corresponding output using the GL backend for rendering.
!   \edannote{Should probably add more detailed pictures here}

    \begin{figure}[htbp]
***************
*** 192,196 ****
        \caption{\small\itshape Output from cairo-demo when run with anti-aliased 
          xrender output.}
!       \label{fig1}
      \end{centering}
    \end{figure}
--- 240,244 ----
        \caption{\small\itshape Output from cairo-demo when run with anti-aliased 
          xrender output.}
!       \label{fig2}
      \end{centering}
    \end{figure}
***************
*** 202,216 ****
        \caption{\small\itshape Output from cairo-demo when run with aliased GL 
          output.}
!       \label{fig2}
      \end{centering}
    \end{figure}

    A simple benchmark application was also written to compare the rendering 
!   performance with Cairo, using the different output formats including the new 
!   GL backend developed in this project. The benchmark application currently 
!   contains two separate tests. The first one animates a semi-transparent, stoked
!   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 lots of 
!   transparent trapezoids can be drawn using Cairo paths. 

    The second test scales a background image and translates another semi-transparent
--- 250,273 ----
        \caption{\small\itshape Output from cairo-demo when run with aliased GL 
          output.}
!       \label{fig3}
      \end{centering}
    \end{figure}

+   Of course these pictures cannot be expected to show any great details of the 
+   result but it might give a rough idea about the accuracy of the output. 
+   Note that no anti-aliasing is applied to the image rendered by GL as it is not
+   yet implemented in a stable fashion. Yet you can see that the image rendered by
+   GL compares rather well to that rendered by xrender. 
+ 
    A simple benchmark application was also written to compare the rendering 
!   performance with Cairo, using the different output formats including xrender, 
!   images (pure software) and the GL backend developed in this project. 
!   The benchmark application 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 lots of transparent trapezoids can be 
!   drawn using Cairo paths. 

    The second test scales a background image and translates another semi-transparent
***************
*** 218,223 ****
    transformation performance.  

!   On all the systems we currently have run these tests, performance has 
!   increased multiple times when rendering with the new GL backend. 
    All these testing and benchmarking utilities can be downloaded from the 
    project web site (referenced in Section 7). The site also contains complete 
--- 275,298 ----
    transformation performance.  

!   On all the systems on which the tests have currently been run, performance has 
!   increased multiple times when rendering with the new GL backend. The table
!   shows test results from a tested system. More tests will be presented in the
!   full report.
! 
!   \begin{table}[htbp]
!     \centering
!     \begin{tabular}{|c||c|c|}\hline
!       {\bf Output} & {\bf Test \#1} & {\bf Test \#2} 
!       \\\hline {\bf GLX} & {400 fps} & {970 fps} 
!       \\\hline {\bf xrender} & {50 fps} & {4 fps} 
!       \\\hline {\bf image} & {9 fps} & {4 fps} 
!       \\\hline
!     \end{tabular}
!     \small\itshape
!     \caption{Test results from cairobench on a AMD2600+/GeforceFX5600 
!       running Nvidias binary Linux driver.}
!     \label{tab:cairobench}
!   \end{table}
! 
    All these testing and benchmarking utilities can be downloaded from the 
    project web site (referenced in Section 7). The site also contains complete 
***************
*** 255,259 ****
    The X desktop seems to be going into a new era and Cairo is definitely the
    2D graphics API which will be used in tomorrow's X applications. The 
!   support for hardware accelareted surfaces in Cairo might then be of great
    importance. Plans for the creation of an X server that will use OpenGL for
    all rendering are currently being made and our library, or the work behind the
--- 330,334 ----
    The X desktop seems to be going into a new era and Cairo is definitely the
    2D graphics API which will be used in tomorrow's X applications. The 
!   support for hardware accelerated surfaces in Cairo might then be of great
    importance. Plans for the creation of an X server that will use OpenGL for
    all rendering are currently being made and our library, or the work behind the