[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

Peter Nilsson commit at pdx.freedesktop.org
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
layers.eps layers.png
Log Message:

--- NEW FILE: layers.eps ---
%%Creator: pnmtops
%%Title: noname.ps
%%Pages: 1
%%BoundingBox: 5 251 211 511
} 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}
!
!
!   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.
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}
!
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