[cairo-commit] papers/opengl_freenix04 ChangeLog,1.8,1.9 opengl_freenix04.tex,1.8,1.9
Peter Nilsson
commit at pdx.freedesktop.org
Tue Dec 16 17:17:12 PST 2003
Committed by: peter
Update of /cvs/cairo/papers/opengl_freenix04
In directory pdx:/tmp/cvs-serv11669
Modified Files:
ChangeLog opengl_freenix04.tex
Log Message:
More fix
Index: ChangeLog
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/ChangeLog,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** ChangeLog 16 Dec 2003 15:23:26 -0000 1.8
--- ChangeLog 17 Dec 2003 01:17:10 -0000 1.9
***************
*** 1,3 ****
--- 1,6 ----
2003-12-16 Peter Nilsson <c99pnn at cs.umu.se>
+ * opengl_freenix04.tex: Fixes all around the paper
+
+ 2003-12-16 Peter Nilsson <c99pnn at cs.umu.se>
* opengl_freenix04.tex: Changed the text about Render / XAA and
some more
Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** opengl_freenix04.tex 16 Dec 2003 19:06:17 -0000 1.8
--- opengl_freenix04.tex 17 Dec 2003 01:17:10 -0000 1.9
***************
*** 1,4 ****
- % See usetex-v1.cls for other options in place of "workingdraft" before submitting.
-
\documentclass[workingdraft]{usetex-v1}
--- 1,2 ----
***************
*** 29,98 ****
\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}
! 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.
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 attained with Matrox drivers,
! which have been known for having the best 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
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.
Even with today's powerful computers these tasks constitute a heavy burden on
--- 27,101 ----
\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.
+
+ The current implementation of this library shows speedups of 8X to 240X
+ compared to traditional rendering models on some of the benchmark tests.
\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.
! 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.
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
! attained with Matrox drivers, which have been known for having the best
! 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
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.
Even with today's powerful computers these tasks constitute a heavy burden on
***************
*** 111,132 ****
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.
! 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.
\begin{figure}[htbp]
\begin{centering}
! \epsfig{file=layers.eps, width=3.0in, height=3.5in}
\small\itshape
\caption{\small\itshape Different software layers involved when an
--- 114,134 ----
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 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.
\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
***************
*** 136,163 ****
\end{figure}
! 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.
! 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
--- 138,164 ----
\end{figure}
! 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.
! 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
***************
*** 167,179 ****
\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.
--- 168,182 ----
\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
! 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
! discussion about their performance compared to the software developed in this
! project.
***************
*** 181,198 ****
As OpenGL layers are available for various platforms and systems, the library
is designed to be usable with any of various OpenGL implementations. Different
! OpenGL implementations can be used by plugging them in to the core of the library through a
! virtualized backend. Each backend only needs to provide a few functions
! which will allow for the core of the library to perform its rendering
! operations unaware of the structure of the underlaying GL layer. Having a
! virtualized backend instead of just choosing a suitable layer at compile
! time has the advantage of allowing the library to be compiled for use with
! 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
is a relatively new feature in the OpenGL world, it is not yet supported by
all hardware and all drivers. When support for offscreen drawing is missing
--- 184,201 ----
As OpenGL layers are available for various platforms and systems, the library
is designed to be usable with any of various OpenGL implementations. Different
! OpenGL implementations can be used by plugging them in to the core of the
! library through a virtualized backend. Each backend only needs to provide a
! few functions which will allow for the core of the library to perform its
! rendering operations unaware of the structure of the underlaying GL layer.
! Having a virtualized backend instead of just choosing a suitable layer at
! compile time has the advantage of allowing the library to be compiled for use
! with 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
is a relatively new feature in the OpenGL world, it is not yet supported by
all hardware and all drivers. When support for offscreen drawing is missing
***************
*** 201,226 ****
drawing can not be performed by our library.
! All rendering operations are performed with so-called surfaces, which
! can be of type onscreen, offscreen or intermediate. Onscreen surfaces are
! usually portions of the frame buffer. Offscreen surfaces are textures stored
! in the graphic card's texture memory. Intermediate surfaces are only used
! internally 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 then blended on top of it with the IN
! operator.
! A texture is created from the resulting surface which can finally be
! composited on the destination surface and we're all done.
! Every time drawing is to be done onto an offscreen surface, an intermediate
! surface needs to be created so that the drawing can be done to this and the result can
! then be copied back to the texture.
Most parts of the Render specification have been implemented but there are
--- 204,226 ----
drawing can not be performed by our library.
! All rendering operations are performed with so-called surfaces, which can be
! of type onscreen, offscreen or intermediate. Onscreen surfaces are usually
! portions of the frame buffer. Offscreen surfaces are textures stored in the
! graphic card's texture memory. Intermediate surfaces are only used internally
! 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
! then blended on top of it with the IN operator. A texture is created from the
! resulting surface which can finally be composited on the destination surface
! and the compositing operation is finished. Every time drawing is to be done
! onto an offscreen surface, an intermediate surface needs to be created so that
! the drawing can be done to this and the result can then be copied back to the
! texture.
Most parts of the Render specification have been implemented but there are
***************
*** 268,273 ****
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
--- 268,273 ----
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
***************
*** 283,291 ****
drawn using Cairo paths.
! The second test scales a background image and translates another semi-transparent
! image randomly across the screen, testing image compositing and
! 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
--- 283,291 ----
drawn using Cairo paths.
! The second test scales a background image and translates another
! semi-transparent image randomly across the screen, testing image compositing
! and 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
***************
*** 302,307 ****
\end{tabular}
\small\itshape
! \caption{Test results from cairobench on a AMD Athlon XP 2600+ / GeforceFX5600
! running Nvidias binary Linux driver.}
\label{tab:cairobench}
\end{table}
--- 302,307 ----
\end{tabular}
\small\itshape
! \caption{Test results from cairobench on a AMD Athlon XP 2600+ /
! GeforceFX5600 running Nvidias binary Linux driver.}
\label{tab:cairobench}
\end{table}
***************
*** 320,324 ****
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 final paper.
--- 320,324 ----
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.
***************
*** 326,330 ****
As of today the existing implementation of the library supports all the basic
functionality initially set up for the project. But still the software is
! in an early stage of development and lots of work remains for making it stable
and optimized with regards to performance and accuracy. A deadline for the
project has been set for March 2004. The aim is to have a useful library by
--- 326,330 ----
As of today the existing implementation of the library supports all the basic
functionality initially set up for the project. But still the software is
! in an early stage of development and lots of work remains for making it stable
and optimized with regards to performance and accuracy. A deadline for the
project has been set for March 2004. The aim is to have a useful library by
***************
*** 357,362 ****
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
! library, can hopefully be usable for this purpose.
--- 357,362 ----
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
! the library, can hopefully be usable for this purpose.
***************
*** 364,371 ****
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 along with the staff at
! the department of Computing Science at Umeå University for supporting us in
! this project, thereby approving the project for financial funding in terms of
! study allowances.
--- 364,371 ----
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
! supporting us in this project, thereby approving the project for financial
! funding in terms of study allowances.
More information about the cairo-commit
mailing list