[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex, 1.30,
1.31
David Reveman
commit at pdx.freedesktop.org
Sun Mar 14 07:55:08 PST 2004
Committed by: davidr
Update of /cvs/cairo/papers/opengl_freenix04
In directory pdx:/tmp/cvs-serv23329
Modified Files:
opengl_freenix04.tex
Log Message:
text
Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.30
retrieving revision 1.31
diff -C2 -d -r1.30 -r1.31
*** a/opengl_freenix04.tex 5 Mar 2004 08:54:24 -0000 1.30
--- b/opengl_freenix04.tex 14 Mar 2004 15:55:05 -0000 1.31
***************
*** 70,82 ****
own processor to boost performance levels. These processors are specialized
for computing graphical transformations, so they achieve better results than
! the general-purpose CPU. In addition, they free up the
! computer's CPU to execute other commands while the graphics accelerator is
! handling graphics computations.
! To relieve the CPU, modern window systems have developed 2D-graphics
! engines which utilize the high performance rendering capabilities
! inherent in today's graphics hardware. In fact, much of the visual effects
! and advanced graphics that can be seen in these systems wouldn't even be
! feasible without hardware accelerated rendering.
The main idea behind this project is to investigate the potential usefulness
--- 70,82 ----
own processor to boost performance levels. These processors are specialized
for computing graphical transformations, so they achieve better results than
! the general-purpose CPU. In addition, they free up the computer's CPU
! to execute other tasks while the graphics accelerator is handling graphics
! computations.
! Modern window systems have developed 2D-graphics engines which utilize the
! high performance rendering capabilities inherent in today's 3D-graphics
! hardware. In fact, much of the visual effects and advanced graphics that
! can be seen in these systems wouldn't even be feasible without hardware
! accelerated rendering.
The main idea behind this project is to investigate the potential usefulness
***************
*** 114,125 ****
throughout the rendering system.
! Render uses the XFree86 Acceleration Architecture (XAA)~\cite{xaa} to
! achieve hardware accelerated rendering. 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. This requires graphics
! driver developers to add their own XAA Render hooks in each driver to
! support it, which results in a duplicated effort. 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 the conclusion can
--- 114,129 ----
throughout the rendering system.
! XFree86's Render implemenation uses XFree86 Acceleration
! Architecture (XAA)~\cite{xaa} to achieve hardware accelerated rendering.
! 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. This requires graphics driver developers to add their
! own XAA Render hooks in each driver to support it, which results in a
! duplicated effort. Unfortunately not many drivers have much support for
! XAA Render hooks at this point, which results in inconsistent acceleration
! between different drivers and hardware.
!
! \edannote{Maybe something about the acceleration in freedesktop's xserver
! here}
From the benchmarks made in the context of this project the conclusion can
***************
*** 130,134 ****
\subsection{\libname{} Fundamentals}
! In order for \libname{} to be useful it will haveto fit well into a complete
environment suitable for 2D graphic application developers.
The challenge is to realize these ideas in the simplest and most efficient
--- 134,138 ----
\subsection{\libname{} Fundamentals}
! In order for \libname{} to be useful it will have to fit well into a complete
environment suitable for 2D graphic application developers.
The challenge is to realize these ideas in the simplest and most efficient
***************
*** 149,166 ****
realize the rendering in the library.
\begin{figure}[htbp]
\begin{centering}
\epsfig{file=flow.eps}
\small\itshape
! \caption{\small\itshape The OpenGL Visualization Programming Pipeline}
\label{layers}
\end{centering}
\end{figure}
! In addition to OpenGL's fixed rendering pipeline there are methods for
! adding new functionality if needed. An example of this is
! fragment programs, which are a way to write new fragment manipulating
! operations in an assembler-like fashion. They provide an attractive feature
! that has been proven very useful in the development of \libname{}.
The Render model provides only low level fundamental graphics
--- 153,178 ----
realize the rendering in the library.
+ To fully utilize the hardware acceleration provided by OpenGL, you
+ have to know the order of operations used in most OpenGL implementations.
+ This is often visualized as a series of processing stages called the
+ OpenGL rendering pipeline. This ordering, is not a strict rule of how OpenGL
+ is implemented but provides a reliable guide for predicting what OpenGL
+ will do.
+
\begin{figure}[htbp]
\begin{centering}
\epsfig{file=flow.eps}
\small\itshape
! \caption{\small\itshape The OpenGL Rendering Pipeline}
\label{layers}
\end{centering}
\end{figure}
! The latest generation of graphics hardware allow the application to
! replace the per-vertex and per-fragment processing stages show in figure
! with user defined computations. These computations are defined with
! assembler-like languages and can be sent to graphics hardware where they
! are compiled and run. They provide an attractive feature that has been
! proven very useful in the development of \libname{}.
The Render model provides only low level fundamental graphics
***************
*** 197,201 ****
\end{figure}
! To sum up these ideas, 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
--- 209,213 ----
\end{figure}
! To sum up these ideas, the goal was 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
***************
*** 215,219 ****
\section{Related Work}
! \edannote{Mentione other 2D API's that have been layered on top of OpenGL.
Why is this a completely different cup of tea?}
--- 227,231 ----
\section{Related Work}
! \edannote{Mention other 2D API's that have been layered on top of OpenGL.
Why is this a completely different cup of tea?}
***************
*** 361,368 ****
When using fragment programs for direct compositing with mask
surfaces some transformations cannot be done as the source
! surface and the mask surfaces share vertex coordinates.
- \edannote{What happens then? Fallback? Performance loss?}
-
\subsection{Repeating Patterns}
--- 373,379 ----
When using fragment programs for direct compositing with mask
surfaces some transformations cannot be done as the source
! surface and the mask surfaces share vertex coordinates. If this is
! the case \libname will be forced to not use direct compositing.
\subsection{Repeating Patterns}
***************
*** 379,385 ****
texturing operations.
! Some hardware supports tiling of none power of two sized textures as well.
! If this is the case, \libname{} will let OpenGL handle tiling of all
! surfaces.
\subsection{Polygon Rendering}
--- 390,396 ----
texturing operations.
! Some OpenGL implementations supports tiling of none power of two sized
! textures as well. If this is the case, \libname{} will let OpenGL
! handle tiling of all surfaces.
\subsection{Polygon Rendering}
***************
*** 393,396 ****
--- 404,408 ----
\edannote{QUE? Pixelization talk below maby needs a short explaination?}
+ \edannote{No}
\libname{} only supports imprecise pixelization. Precise pixelization
***************
*** 399,403 ****
high-performance mixed software and hardware implementations.
\libname{} matches the following set of invariants
! for imprecise polygons so the visual artifacts associated with
polygon tessellation and translation are minimized.
--- 411,415 ----
high-performance mixed software and hardware implementations.
\libname{} matches the following set of invariants
! for imprecise polygons hench the visual artifacts associated with
polygon tessellation and translation are minimized.
***************
*** 411,415 ****
\subsubsection{Direct Polygons}
! \libname{} is also able to render polygons directly onto a destination
surface. Each polygon vertex has a specific color associated with it.
If the color differ between any of the vertices in a polygon, colors
--- 423,427 ----
\subsubsection{Direct Polygons}
! \libname{} is able to render polygons directly onto a destination
surface. Each polygon vertex has a specific color associated with it.
If the color differ between any of the vertices in a polygon, colors
***************
*** 645,651 ****
programmatic surface doesn't contain any actual image data, only
a minimum set of attributes. These attributes describe how to calculate
! the color for each pixel in the surface.
! \edannote{Rewrite this}
Not containing any actual image data makes initialization time for
--- 657,663 ----
programmatic surface doesn't contain any actual image data, only
a minimum set of attributes. These attributes describe how to calculate
! the color for each fragment of the surface.
! \edannote{Not completely happy with the follwing text}
Not containing any actual image data makes initialization time for
***************
*** 668,676 ****
\edannote{A picture showing results form composite with
a programmatic surface (linear gradient should be fine)}
-
- \edannote{Programmatic surfaces are not implemented yet but I've
- written working fragment programs for linear and radial
- gradients and that should be a good start so I'll
- probably implement it soon.}
\subsection{A Cross-platform OpenGL Layer}
--- 680,683 ----
***************
*** 771,775 ****
\subsection{Accuracy}
! This section discusses rendering accuracy with text and images.
\subsection{Performance}
--- 778,853 ----
\subsection{Accuracy}
! The quality of the visual output from \libname{} compares well to the
! corresponding output from xrender. Pixel precision in \libname{} output
! appears to match precisely that of xrender when rendered without any
! anti-aliasing applied. Figures~\ref{cairo-demo1} and~\ref{cairo-demo2}
! illustrates the similarity between an aliased path rendered with cairo
! using the OpenGL and xrender outputs.
!
! \begin{figure}[htbp]
! \begin{centering}
! \epsfig{file=cairo-demo1.eps}
! \small\itshape
! \caption{\small\itshape Aliased OpenGL output from cairo-demo}
! \label{cairo-demo1}
! \end{centering}
! \end{figure}
!
! \begin{figure}[htbp]
! \begin{centering}
! \epsfig{file=cairo-demo1.eps}
! \small\itshape
! \caption{\small\itshape Aliased xrender output from cairo-demo}
! \label{cairo-demo2}
! \end{centering}
! \end{figure}
!
! Anti-aliasing however may introduce some inconsistencies in the output
! between \libname{} and xrender. Different anti-aliasing techniques
! might be used in \libname{} depending on the graphics driver and
! hardware being used. On older hardware anti-aliasing isn't even
! guaranteed as it requires relatively new OpenGL extensions.
! Nevertheless, if \libname{} is run on fairly modern graphics
! hardware very similar results are achieved even with anti-aliased output.
! Figures~\ref{cairo-demo2} and~\ref{cairo-demo2} shows the same paths as
! above, now with anti-aliased output.
!
! \begin{figure}[htbp]
! \begin{centering}
! \epsfig{file=cairo-demo2.eps}
! \small\itshape
! \caption{\small\itshape Anti-Aliased OpenGL output from cairo-demo}
! \label{cairo-demo3}
! \end{centering}
! \end{figure}
!
! \begin{figure}[htbp]
! \begin{centering}
! \epsfig{file=cairo-demo2.eps}
! \small\itshape
! \caption{\small\itshape Anti-Aliased xrender output from cairo-demo}
! \label{cairo-demo4}
! \end{centering}
! \end{figure}
!
! Even though these results appear somewhat different in these magnified
! figures, the performance gained by using these OpenGL accelerated
! anti-aliasing techniques by far makes up for this. In most cases the
! generated results are close to indistinguishable.
!
! The most demanding tests of the visual accuracy of \libname{} is probably
! Scalable Vector Graphics (SVG)~\ref{svg} rendering. xsvg is a cairo-based
! SVG viewer that has been modified to allow rendering with \libname{} output.
! Figure~\ref{svg-image} shows a correctly rendered complex SVG image
! containing demanding details such as linear and radial gradients.
!
! \begin{figure}[htbp]
! \begin{centering}
! \epsfig{file=svg-image.eps}
! \small\itshape
! \caption{\small\itshape A complex SVG image rendered with \libname{}}
! \label{svg-image}
! \end{centering}
! \end{figure}
\subsection{Performance}
***************
*** 781,788 ****
During the development of \libname{} we've found that with the OpenGL
API and the extensions available today and the wide range of hardware
! supporting them.
!
!
! it's not only possible create an Render-like interface
on top of OpenGL it's actually very efficient.
--- 859,863 ----
During the development of \libname{} we've found that with the OpenGL
API and the extensions available today and the wide range of hardware
! supporting them, it's not only possible to create an Render-like interface
on top of OpenGL it's actually very efficient.
***************
*** 851,855 ****
All source code related to this project is free software distributed
! under the MIT license.
The source can be retrieved via anonymous access from the cairo CVS
--- 926,931 ----
All source code related to this project is free software distributed
! under the MIT license. The licence of \libname{} will follow that of
! cairo in case of changes.
The source can be retrieved via anonymous access from the cairo CVS
More information about the cairo-commit
mailing list