[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex,1.9,1.10
Carl Worth
commit at pdx.freedesktop.org
Wed Dec 17 08:50:27 PST 2003
Committed by: cworth
Update of /cvs/cairo/papers/opengl_freenix04
In directory pdx:/tmp/cvs-serv12678
Modified Files:
opengl_freenix04.tex
Log Message:
Fix several minor typographical errors.
Add a few editorial notes.
Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** opengl_freenix04.tex 17 Dec 2003 01:17:10 -0000 1.9
--- opengl_freenix04.tex 17 Dec 2003 16:50:25 -0000 1.10
***************
*** 27,34 ****
\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.
--- 27,34 ----
\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.
***************
*** 36,42 ****
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
--- 36,42 ----
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
***************
*** 51,57 ****
\section{Introduction}
The X Window System wasn't originally designed for the advanced graphics that
! can bee seen on modern desktops today. The main reason was that graphics
! hardware at that time wasn't fast enough to pull it off anyway. Application
! developers soon found the core graphics routines inadequate and the the trend
became to use client-side software rendering instead.
--- 51,57 ----
\section{Introduction}
The X Window System wasn't originally designed for the advanced graphics that
! can be seen on modern desktops. The main reason is that graphics
! hardware available at the time was not fast enough. Application
! developers soon found the core graphics routines inadequate and the trend
became to use client-side software rendering instead.
***************
*** 59,63 ****
(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
--- 59,63 ----
(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
***************
*** 71,83 ****
Render uses the XFree86 Acceleration Architecture (XAA)~\cite{xaa} to achieve
hardware accelerated rendering. This requires graphics driver developers to
! add their own XAA render hooks in each driver to support it, which results in
! a duplicated effort. XAA breaks down complex render operations into simpler
ones and accelerates them if support is provided by the driver, otherwise it
falls back on software. Unfortunately not many drivers have much support for
! XAA at this point, which results in an inconsistent acceleration support for
! Render between different drivers and hardware.
From the benchmarks made in the context of this project (see table 1, section
! 5) 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
--- 71,83 ----
Render uses the XFree86 Acceleration Architecture (XAA)~\cite{xaa} to achieve
hardware accelerated rendering. This requires graphics driver developers to
! add their own XAA Render hooks in each driver to support it, which results in
! duplicated effort. XAA breaks down complex Render operations into simpler
ones and accelerates them if support is provided by the driver, otherwise it
falls back on software. Unfortunately not many drivers have much support for
! XAA Render hooks at this point, which results in inconsistent acceleration
! 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
***************
*** 85,91 ****
acceleration support for Render in the past.
! There was also an other benchmark application called Renderbench released not
! too long ago by the people behind imlib2~\cite{imlib2} that compared the
! performance of Imlib2 to that of Render. Imlib2 is a 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
--- 85,91 ----
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
***************
*** 99,102 ****
--- 99,103 ----
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
***************
*** 116,129 ****
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 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 should clearly be 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
! end application uses Cairo to draw accelerated output with GLX. These layers
are more described in subsequent sections.
--- 117,130 ----
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.
***************
*** 133,137 ****
\small\itshape
\caption{\small\itshape Different software layers involved when an
! application uses Cairo to render to a GLX surface.}
\label{fig1}
\end{centering}
--- 134,138 ----
\small\itshape
\caption{\small\itshape Different software layers involved when an
! application uses cairo to render to a GLX surface.}
\label{fig1}
\end{centering}
***************
*** 150,154 ****
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.
--- 151,155 ----
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.
***************
*** 168,173 ****
\section{Related Work}
! Some of the commercially developed window systems have creathed their own 3D
! graphic engines that can render hardware accelerated 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
--- 169,174 ----
\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
***************
*** 193,197 ****
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.
--- 194,198 ----
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.
***************
*** 201,205 ****
all hardware and all drivers. When support for offscreen drawing is missing
the program using the library will have to handle this on its own. In the
! Cairo library for example, image buffers will be used instead when offscreen
drawing can not be performed by our library.
--- 202,206 ----
all hardware and all drivers. When support for offscreen drawing is missing
the program using the library will have to handle this on its own. In the
! cairo library for example, image buffers will be used instead when offscreen
drawing can not be performed by our library.
***************
*** 210,218 ****
by the library and are offscreen areas that can be rendered to. It is up to
the backend to decide on the type of intermediate surface, however pbuffers
! are most likely to be used, so is at least the case for the GLX backend.
The general composite operation is the fundamental rendering part of the
! library. It takes two source surfaces and one destination surface, where the
! second of the two source surfaces is the optional mask surface. 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
--- 211,219 ----
by the library and are offscreen areas that can be rendered to. It is up to
the backend to decide on the type of intermediate surface, however pbuffers
! 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
***************
*** 226,235 ****
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 ways to go, some
! of them require specific hardware support and some do not. 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. The final paper will have a detailed
description of the chosen model along with a motivation.
--- 227,236 ----
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.
***************
*** 238,246 ****
Right now the library hasn't really been tested that much in real applications
as it is relatively early in the development process. Some small test
! 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.
! The figures show a part of the output from the cairo-demo application, the
! output image has been cut down only to save some space in this paper.
! Figure 1 shows output from cairo-demo using xrender and figure 2 shows the
corresponding output using the GL backend for rendering.
--- 239,246 ----
Right now the library hasn't really been tested that much in real applications
as it is relatively early in the development process. Some small test
! 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.
***************
*** 251,255 ****
\caption{\small\itshape Output from cairo-demo when run with anti-aliased
xrender output.}
! \label{fig2}
\end{centering}
\end{figure}
--- 251,255 ----
\caption{\small\itshape Output from cairo-demo when run with anti-aliased
xrender output.}
! \label{cairo-demo-xrender}
\end{centering}
\end{figure}
***************
*** 261,276 ****
\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. Neverteless 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.
This benchmark application, called cairobench, currently contains two
--- 261,280 ----
\caption{\small\itshape Output from cairo-demo when run with aliased GL
output.}
! \label{cairo-demo-glc}
\end{centering}
\end{figure}
!
! Note that the image rendered by GL compares rather well to that
! rendered by xrender. Although not obvious in the printed version,
! the on-screen display of these images does show a differerence. The
! xrender output is anti-aliased while the GL output is not. Work is
! now in progress to add support for anti-aliasing to the GLC backend.
! \edannote{It might be good to add a closeup figure here to
! demonstrate the difference. That can wait until the final paper.
! Or better, the final paper may just drop this paragraph as
! hopefully GLC will be anti-aliased by then.}
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
***************
*** 278,285 ****
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
--- 282,289 ----
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.
The second test scales a background image and translates another
***************
*** 288,292 ****
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.
--- 292,296 ----
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.
***************
*** 306,309 ****
--- 310,318 ----
\label{tab:cairobench}
\end{table}
+
+ \edannote{It would be good to add some more analysis of the results
+ here. First, a summary mentioning the overall speedup (8X-240X)
+ would be appropriate. Next, why is there such a large discrepancy
+ in the speedup?}
There has also been some benchmarking of imlib2 compared to the software
***************
*** 319,323 ****
All these testing and benchmarking utilities can be downloaded from the
project web site (referenced in Section 7). The site also contains complete
! screen shots of these applications in action. A lot more testing will be done
and the results will be presented in the full paper.
--- 328,332 ----
All these testing and benchmarking utilities can be downloaded from the
project web site (referenced in Section 7). The site also contains complete
! screen shots of these applications in action. More testing will be done
and the results will be presented in the full paper.
***************
*** 353,359 ****
operation the Render compositing model would be much more efficient.
! 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 this library, or the work behind
--- 362,368 ----
operation the Render compositing model would be much more efficient.
! 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 this library, or the work behind
***************
*** 363,367 ****
\section{Acknowledgments}
We would like to thank Carl Worth, Keith Packard, and all of the
! people involved in the development of Cairo for being helpful and encouraging.
We would also like to thank our internal supervisor Berit Kvernes along with
the staff at the department of Computing Science at Umeå University for
--- 372,376 ----
\section{Acknowledgments}
We would like to thank Carl Worth, Keith Packard, and all of the
! people involved in the development of cairo for being helpful and encouraging.
We would also like to thank our internal supervisor Berit Kvernes along with
the staff at the department of Computing Science at Umeå University for
***************
*** 374,382 ****
MIT license.
! The source can be retrieved via anonymous access from the Cairo CVS
(\url{anoncvs at cvs.cairographics.org:/cvs/cairo}). Just check out the module
called libglc. There is also a simple web site that includes some information
about the project at \url{http://www.cs.umu.se/~c99pnn/thesis}. A patch for
! the Cairo library along with some test and benchmark utilities can also be
found at this location.
--- 383,391 ----
MIT license.
! The source can be retrieved via anonymous access from the cairo CVS
(\url{anoncvs at cvs.cairographics.org:/cvs/cairo}). Just check out the module
called libglc. There is also a simple web site that includes some information
about the project at \url{http://www.cs.umu.se/~c99pnn/thesis}. A patch for
! the cairo library along with some test and benchmark utilities can also be
found at this location.
More information about the cairo-commit
mailing list