[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex,1.26,1.27
Peter Nilsson
commit at pdx.freedesktop.org
Mon Aug 15 11:12:59 PDT 2005
Committed by: peter
Update of /cvs/cairo/papers/opengl_freenix04
In directory pdx:/tmp/cvs-serv25921
Modified Files:
opengl_freenix04.tex
Log Message:
Spelling fixes etc
Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.26
retrieving revision 1.27
diff -C2 -d -r1.26 -r1.27
*** a/opengl_freenix04.tex 23 Feb 2004 15:31:36 -0000 1.26
--- b/opengl_freenix04.tex 23 Feb 2004 20:14:36 -0000 1.27
***************
*** 10,14 ****
\begin{document}
-
\title{\libname{}: Hardware Accelerated Image Compositing using OpenGL}
--- 10,13 ----
***************
*** 43,47 ****
utilizing the acceleration capabilities in modern graphics hardware.
! This project investigat the potential usefulness of an open source
implementation of such a graphics engine. We present \libname,
a portable open source 2D graphics library that can
--- 42,46 ----
utilizing the acceleration capabilities in modern graphics hardware.
! This project investigates the potential usefulness of an open source
implementation of such a graphics engine. We present \libname,
a portable open source 2D graphics library that can
***************
*** 119,128 ****
be drawn that the amount of accelerated rendering achieved by Render doesn't
seem to be enough for the complex visual effects addressed by this project.
! See section 5 Results and Conclusions for documented benchmark tests.
\subsection{\libname{} Fundamentals}
! Render seems to be ideal model to build \libname{} upon. It provides
! all the necessary operations needed to carry out the rendering for
modern 2D graphics applications. Hence \libname{} should be designed
to exactly match the Render model semantics, adding an efficient
--- 118,127 ----
be drawn that the amount of accelerated rendering achieved by Render doesn't
seem to be enough for the complex visual effects addressed by this project.
! See section 5 Results for documented benchmark tests.
\subsection{\libname{} Fundamentals}
! Render seems to be the ideal model to build \libname{} upon. It provides
! the necessary operations needed to carry out the rendering for
modern 2D graphics applications. Hence \libname{} should be designed
to exactly match the Render model semantics, adding an efficient
***************
*** 134,138 ****
and is very portable. OpenGL operates on image data as well as geometric
primitives and offers the necessary operations needed for the creation of
! \libname{}.For these reasons the choice has been made to use OpenGL to
realize the rendering in the library.
--- 133,137 ----
and is very portable. OpenGL operates on image data as well as geometric
primitives and offers the necessary operations needed for the creation of
! \libname{}. For these reasons the choice has been made to use OpenGL to
realize the rendering in the library.
***************
*** 147,151 ****
In addition to OpenGL's fixed rendering pipeline there are methods for
! adding new functionallity to the API if needed. An example of this is
fragment programs, which are a way to write new fragment manipulating
operations in an assembler-like fashion. Fragment programs are frequently
--- 146,150 ----
In addition to OpenGL's fixed rendering pipeline there are methods for
! adding new functionality to the API if needed. An example of this is
fragment programs, which are a way to write new fragment manipulating
operations in an assembler-like fashion. Fragment programs are frequently
***************
*** 165,170 ****
multiple output devices. 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.
The backend interface of cairo has the same semantics as Render.
So \libname{} is designed to act as an additional backend for cairo
--- 164,169 ----
multiple output devices. 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 efficiently accelerate the
! rendering process with today's high performance graphics hardware.
The backend interface of cairo has the same semantics as Render.
So \libname{} is designed to act as an additional backend for cairo
***************
*** 186,190 ****
\end{figure}
! Hence, 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
--- 185,189 ----
\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
***************
*** 194,202 ****
integration with the cairo library that then will provide an attractive
environment for developing new high performance graphical applications.
!
Hopefully the work presented in this paper will be useful in the design of
a new generation of hardware accelerated graphic applications for X and
the open source community in general.
\section{Related Work}
--- 193,204 ----
integration with the cairo library that then will provide an attractive
environment for developing new high performance graphical applications.
!
Hopefully the work presented in this paper will be useful in the design of
a new generation of hardware accelerated graphic applications for X and
the open source community in general.
+ The reminder of this paper discusses \libname{}, which is the actual
+ implementation of these ideas.
+
\section{Related Work}
***************
*** 235,241 ****
allows for the library to be compiled for multiple backends.
! As of now \libname{} has two backends for GLX and AGL. GLX is the OpenGL
implementation used on Unix like systems to provide a glue layer between
! OpenGL and the X. AGL is Apple's OpenGL implementation
available in Mac OS. Backends for other OpenGL implementations will be
added later on.
--- 237,243 ----
allows for the library to be compiled for multiple backends.
! As of now \libname{} has two backends, for GLX and AGL. GLX is the OpenGL
implementation used on Unix like systems to provide a glue layer between
! OpenGL and X. AGL is Apple's OpenGL implementation
available in Mac OS. Backends for other OpenGL implementations will be
added later on.
***************
*** 263,266 ****
--- 265,271 ----
entire model has changed since the previous frame.
+ \subsection{Offscreen Drawing}
+
+ \edannote {Add some more stuff here}
For any usable immediate mode graphics API, offscreen drawing is required.
Even though support for this has actually been around for a long time on
***************
*** 307,321 ****
as a texture.
! The optional mask surface which can be provide to the general composite
operation creates some additional complications. The source surfaces
must first be composited onto the mask using the Porter-Duff in-operator
and the result should then be composited onto the destination. The
default method for handling this is to create an intermediate offscreen
! surface which can be used for compositing operation using the in-operator
! and this surface can then be composited onto the destination for the
! correct result.
! The best would off course be to be able to perform compositing with
! a mask surface directly without the creation of an intermediate surface.
\libname{} is able to do this on hardware which supports fragment
programs. Fragment programs allows for fragment level programmability
--- 312,326 ----
as a texture.
! The optional mask surface which can be provided to the general composite
operation creates some additional complications. The source surfaces
must first be composited onto the mask using the Porter-Duff in-operator
and the result should then be composited onto the destination. The
default method for handling this is to create an intermediate offscreen
! surface which can be used for compositing using the in-operator.
! This surface can then be composited onto the destination with an
! arbitrary operator for the correct result.
! The best way to do this would off course be to perform compositing with a
! mask surface directly without the creation of an intermediate surface.
\libname{} is able to do this on hardware which supports fragment
programs. Fragment programs allows for fragment level programmability
***************
*** 325,329 ****
\subsection{Image Transformations}
! Image transformations are a natural part of OpenGL and is efficiently
done on all available hardware and with all available OpenGL
implementations. \libname{} simply transforms the vertex coordinates
--- 330,334 ----
\subsection{Image Transformations}
! Image transformations are a natural part of OpenGL and are efficiently
done on all available hardware and with all available OpenGL
implementations. \libname{} simply transforms the vertex coordinates
***************
*** 332,336 ****
When using fragment programs for direct compositing with mask
! surfaces some transformations cannot be done as both the source
surface and the mask surfaces share vertex coordinates.
--- 337,341 ----
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.
***************
*** 355,359 ****
\subsection{Polygon Rendering}
! \libname supports two separate primitive objects; triangles and
trapezoids. Triangles are specified by locating their three vertices.
Trapezoids are represented by two horizontal lines delimiting the top
--- 360,364 ----
\subsection{Polygon Rendering}
! \libname{} supports two separate primitive objects; triangles and
trapezoids. Triangles are specified by locating their three vertices.
Trapezoids are represented by two horizontal lines delimiting the top
***************
*** 362,370 ****
rendering complex objects tessellated by higher level applications.
! \libname only supports imprecise pixelization. Precise pixelization
is not supported as OpenGL has relatively weak invariant
requirements of pixelization. This is because of the desire for
high-performance mixed software and hardware implementations.
! \libname matches the following of set of invariants
for imprecise polygons so the visual artifacts associated with
polygon tessellation and translation are minimized.
--- 367,375 ----
rendering complex objects tessellated by higher level applications.
! \libname{} only supports imprecise pixelization. Precise pixelization
is not supported as OpenGL has relatively weak invariant
requirements of pixelization. This is because of the desire for
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.
***************
*** 379,385 ****
\subsubsection{Direct Polygons}
! \libname is able to render polygons direct to a destination
! surface. Each polygon vertex have a specific color associated with it
! and if the color differ between any of the vertices in a polygon, colors
will be blended between vertices. Direct polygons have the advantages
of not requiring an intermediate offscreen buffer and are therefor
--- 384,390 ----
\subsubsection{Direct Polygons}
! \libname{} is also able to render polygons direct to 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
will be blended between vertices. Direct polygons have the advantages
of not requiring an intermediate offscreen buffer and are therefor
***************
*** 391,397 ****
\subsubsection{Indirect Polygons}
! When \libname renders indirect polygons an intermediate offscreen
! surface containing only an alpha channel is created and the
! polygons are rendered onto this surface. The intermediate surface
is then used as mask when compositing the supplied source surface
onto the destination surface. Indirect polygons can be used for
--- 396,402 ----
\subsubsection{Indirect Polygons}
! When \libname{} renders indirect polygons an intermediate offscreen
! surface containing only an alpha channel is created. The polygons are
! then rendered onto this surface. The intermediate surface
is then used as mask when compositing the supplied source surface
onto the destination surface. Indirect polygons can be used for
***************
*** 533,540 ****
the application or a higher level library. For efficient text rendering,
glyph sets with offscreen surfaces containing alpha masks should be
! used. With external glyph management \libname{} renders text at around
! 50000 glyphs/sec.
! Built in text handling is planned for future version of the library and
tests have proven that this will increase glyph rendering speed to
at least 200000 glyphs/sec.
--- 538,545 ----
the application or a higher level library. For efficient text rendering,
glyph sets with offscreen surfaces containing alpha masks should be
! used. With external glyph management \libname{} renders text at
! approximately 50000 glyphs/sec.
! Built in text handling is planned for future versions of the library and
tests have proven that this will increase glyph rendering speed to
at least 200000 glyphs/sec.
***************
*** 543,547 ****
Convolutions can be used to perform many common image processing operations
! including sharpening, blurring, noise reduction, embossing, and
edge enhancement.
--- 548,552 ----
Convolutions can be used to perform many common image processing operations
! including sharpening, blurring, noise reduction, embossing and
edge enhancement.
***************
*** 554,558 ****
convolution kernel has been set for a surface, the convolution filter
will be applied when the surface is used as a source in a compositing
! operation without modifying the original source surface.
In \libname{} convolution filtering is implemented using fragment
--- 559,563 ----
convolution kernel has been set for a surface, the convolution filter
will be applied when the surface is used as a source in a compositing
! operation. The original source surface remains unmodified.
In \libname{} convolution filtering is implemented using fragment
***************
*** 561,565 ****
would be to use OpenGL's imaging extension and would require a transfer
of all pixels through OpenGL's pixel pipeline to an intermediate
! texture. Eventhough the alternative method would be supported by older
hardware, \libname{} uses fragment programs in favor of performance.
--- 566,570 ----
would be to use OpenGL's imaging extension and would require a transfer
of all pixels through OpenGL's pixel pipeline to an intermediate
! texture. Even though the alternative method would be supported by older
hardware, \libname{} uses fragment programs in favor of performance.
***************
*** 600,614 ****
\end{table}
! \edannote{Original image and image after 3x3 gaussian filtering}
! \subsection{Programmetic Surfaces}
! \libname{} allow you to create programmetic surfaces, a
! programmetic surface doesn't contain any actual image data only
! a minimum subset of attributes which describe how to calculate
the color for each pixel in the surface.
! Programmetic surfaces can be used for wide range of effects, however the
! most useful seems to be gradients. Gradients consistz of a continuously
smooth color transition along a vector from one color to another.
\libname{} provides for at least two types of gradients, linear and
--- 605,619 ----
\end{table}
! \edannote{Original image and image after 3x3 Gaussian filtering}
! \subsection{Programmatic Surfaces}
! \libname{} allows you to create programmatic surfaces. A
! programmatic surface doesn't contain any actual image data, only
! a minimum subset of attributes. These attributes describe how to calculate
the color for each pixel in the surface.
! Programmatic surfaces can be used for a wide range of effects, however the
! most useful seems to be gradients. Gradients consist of a continuously
smooth color transition along a vector from one color to another.
\libname{} provides for at least two types of gradients, linear and
***************
*** 618,622 ****
center point.
! As all programmetic surfaces are implemented using fragment programs and
they will only be available on hardware supporting the fragment program
extension.
--- 623,627 ----
center point.
! As all programmatic surfaces are implemented using fragment programs and
they will only be available on hardware supporting the fragment program
extension.
More information about the cairo-commit
mailing list