[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex, 1.45,
1.46
David Reveman
commit at pdx.freedesktop.org
Wed Apr 7 04:21:20 PDT 2004
Committed by: davidr
Update of /cvs/cairo/papers/opengl_freenix04
In directory pdx:/tmp/cvs-serv12727
Modified Files:
opengl_freenix04.tex
Log Message:
even more fixes
Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.45
retrieving revision 1.46
diff -C2 -d -r1.45 -r1.46
*** a/opengl_freenix04.tex 7 Apr 2004 09:13:18 -0000 1.45
--- b/opengl_freenix04.tex 7 Apr 2004 11:21:18 -0000 1.46
***************
*** 16,20 ****
\title{\Libname{}: Hardware Accelerated Image Compositing using OpenGL}
! \docstatus{soon ready}
\author{
--- 16,20 ----
\title{\Libname{}: Hardware Accelerated Image Compositing using OpenGL}
! \docstatus{ready?}
\author{
***************
*** 50,64 ****
render hardware accelerated graphics.
! \Libname{} is layered on top of OpenGL~\cite{gl:1.2.1} and is designed
! to act as an additional backend for cairo (formerly known as Xr~\cite{xr}),
! providing it with hardware accelerated output.
Furthermore an effort has been made to investigate if the level of hardware
! acceleration provided by the X Window System (X)~\cite{x} can be improved
by using \libname{} to carry out its fundamental drawing operations.
\section{Introduction}
! There's an obvious trend visible in the appearance of modern window systems
and 2D graphics in general these days.
They all become more and more loaded with graphical features and visual
--- 50,64 ----
render hardware accelerated graphics.
! \Libname{} is layered on top of OpenGL and is designed
! to act as an additional backend for cairo, providing it with hardware
! accelerated output.
Furthermore an effort has been made to investigate if the level of hardware
! acceleration provided by the X Window System can be improved
by using \libname{} to carry out its fundamental drawing operations.
\section{Introduction}
! There is an obvious trend visible in the appearance of modern window systems
and 2D graphics in general these days.
They all become more and more loaded with graphical features and visual
***************
*** 82,95 ****
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.
This paper presents \libname, an open source implementation of a 2D graphics
! library that can use this acceleration to become the basis for a high
! performance rendering environment.
! Furthermore, these ideas have been applied to X to see if they could
! improve hardware acceleration of graphical applications
! in that context and thereby making way for more advanced graphics.
The software that is developed in this project will primarily target users
--- 82,96 ----
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 would not even be feasible without hardware
accelerated rendering.
This paper presents \libname, an open source implementation of a 2D graphics
! library that uses OpenGL~\cite{gl:1.2.1} to realize a hardware
! accelerated high performance rendering environment.
! Furthermore, these ideas have been applied to the X Window System
! (X)~\cite{x}, to see if they could improve hardware acceleration of
! graphical applications in that context and thereby making way for
! more advanced graphics.
The software that is developed in this project will primarily target users
***************
*** 98,107 ****
\subsection{Traditional X Graphics}
! X 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.
! Several steps have been taken to rectify this since then.
One major improvement was made with the introduction of the X Render
--- 99,108 ----
\subsection{Traditional X Graphics}
! X 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. Several steps have been taken to rectify this since then.
One major improvement was made with the introduction of the X Render
***************
*** 153,162 ****
operations, not always suitable for direct use by application developers.
A higher level graphics API is needed on top of the Render model to make
! it useful for this purpose. The cairo library is a modern, open source,
! cross-platform 2D graphics API designed for multiple output devices.
! With its PDF~\cite{pdf14}-like 2D graphics API it provides an attractive
! and powerful vector based drawing environment.
Cairo uses a backend system to realize its multiple output formats.
! One thing missing thus far in cairo though, is a backend that efficiently
accelerates the rendering process with today's high performance graphics
hardware. The backend interface of cairo has the same semantics as Render.
--- 154,163 ----
operations, not always suitable for direct use by application developers.
A higher level graphics API is needed on top of the Render model to make
! it useful for this purpose. The cairo (formerly known as Xr~\cite{xr})
! library is a modern, open source, cross-platform 2D graphics API designed
! for multiple output devices. With its PDF~\cite{pdf14}-like 2D graphics API,
! it provides an attractive and powerful vector based drawing environment.
Cairo uses a backend system to realize its multiple output formats.
! One thing missing thus far in cairo, is a backend that efficiently
accelerates the rendering process with today's high performance graphics
hardware. The backend interface of cairo has the same semantics as Render.
***************
*** 182,192 ****
OpenGL is the obvious way to accelerate graphics output, in 2D as well as
! 3D. Surely most people think of OpenGL as a 3D graphics API, which is
understandable because it was used primarily for 3D applications like
! visualizations and games in the past. However it is just as well suited for
the kind of 2D graphics discussed in this paper, where transformations and
other visual effects play a central part, much like in traditional
3D applications. OpenGL is the most widely used and supported graphics
! API available today, it's well supported in hardware and very portable.
It operates on image data as well as geometric primitives and offers
the necessary operations needed for the creation of \libname{}.
--- 183,193 ----
OpenGL is the obvious way to accelerate graphics output, in 2D as well as
! 3D. Most people think of OpenGL as a 3D graphics API, which is
understandable because it was used primarily for 3D applications like
! visualizations and games in the past. However, it is just as well suited for
the kind of 2D graphics discussed in this paper, where transformations and
other visual effects play a central part, much like in traditional
3D applications. OpenGL is the most widely used and supported graphics
! API available today, it is well supported in hardware and very portable.
It operates on image data as well as geometric primitives and offers
the necessary operations needed for the creation of \libname{}.
***************
*** 202,206 ****
applications.
! Hopefully the work presented in this paper will be useful in the design of
a new generation of hardware accelerated 2D graphics applications for X and
the open source community in general.
--- 203,207 ----
applications.
! Hopefully, the work presented in this paper will be useful in the design of
a new generation of hardware accelerated 2D graphics applications for X and
the open source community in general.
***************
*** 248,253 ****
being developed under the name Windows Longhorn~\cite{longhorn}.
! \Libname{} isn't the first Open Source graphics library that
! has been layered on top of OpenGL. e.g. Evas~\cite{evas};
a hardware accelerated canvas API, which is part of the Enlightenment
Foundation Libraries. \Libname{} is unique compared to these libraries
--- 249,254 ----
being developed under the name Windows Longhorn~\cite{longhorn}.
! \Libname{} is not the first Open Source graphics library that
! has been layered on top of OpenGL. For example, Evas~\cite{evas};
a hardware accelerated canvas API, which is part of the Enlightenment
Foundation Libraries. \Libname{} is unique compared to these libraries
***************
*** 293,310 ****
The Render protocol describes an immediate rendering model. This
means that the application itself maintains the data that describes the
! model. For example, with Xrender you draw objects by completely
! specifying what should be drawn. Xrender simply takes the data provided
by the application and immediately draws the appropriate objects.
The opposite would be to have a retained rendering model. A rendering
model is operating in retained mode if it retains a copy of all the data
! describing a model. In other words, retained mode rendering requires a
! completely specified model by passing data to the
! rendering system using predefined structures. The rendering system
! organizes the data internally, usually in a hierarchical database.
Principal advantages of immediate mode rendering includes a more
flexible model and immediately available data that is not
! duplicated by the rendering system. However it's more difficult to
accelerate the immediate rendering model, because you generally need to
specify the entire model to draw a single frame, whether or not the
--- 294,311 ----
The Render protocol describes an immediate rendering model. This
means that the application itself maintains the data that describes the
! model. For example, with Render you draw objects by completely
! specifying what should be drawn. Render simply takes the data provided
by the application and immediately draws the appropriate objects.
The opposite would be to have a retained rendering model. A rendering
model is operating in retained mode if it retains a copy of all the data
! describing a model. Retained mode rendering requires a completely
! specified model by passing data to the rendering system using predefined
! structures. The rendering system organizes the data internally, usually
! in a hierarchical database.
Principal advantages of immediate mode rendering includes a more
flexible model and immediately available data that is not
! duplicated by the rendering system. However, it is more difficult to
accelerate the immediate rendering model, because you generally need to
specify the entire model to draw a single frame, whether or not the
***************
*** 314,321 ****
Off-screen drawing is an essential part of an immediate mode 2D graphics
! API. Even though support for off-screen drawing in OpenGL has
! actually been around for a long time on IRIX~\cite{irix} systems and other
! workstations, it's not until recently that it has become a standard
! feature on the regular home desktop computer.
Pixel buffers or so called pbuffers are what make off-screen rendering
--- 315,322 ----
Off-screen drawing is an essential part of an immediate mode 2D graphics
! API. Support for off-screen drawing in OpenGL has been around
! for a long time on IRIX~\cite{irix} systems and other workstations, but
! it is not until recently that it has become a standard feature on the
! regular home desktop computer.
Pixel buffers or so called pbuffers are what make off-screen rendering
***************
*** 328,332 ****
missing, the application using \libname{} will have to handle this
on its own. Even though \libname{} is primarily designed for modern
! graphics hardware, it's important to be able to fall back on software
rendering in cases where \libname{} is not able to carry out off-screen
drawing operations. For example, the cairo library handles this
--- 329,333 ----
missing, the application using \libname{} will have to handle this
on its own. Even though \libname{} is primarily designed for modern
! graphics hardware, it is important to be able to fall back on software
rendering in cases where \libname{} is not able to carry out off-screen
drawing operations. For example, the cairo library handles this
***************
*** 345,349 ****
The general composite operation is the fundamental part of the rendering
model. It takes two source surfaces and one destination surface, where the
! second of the two source surfaces is the optional mask surface.
\begin{figure}[htbp]
--- 346,351 ----
The general composite operation is the fundamental part of the rendering
model. It takes two source surfaces and one destination surface, where the
! second of the two source surfaces is the optional mask surface. Figure
! ~\ref{porter_duff} illustrates this operation.
\begin{figure}[htbp]
***************
*** 352,356 ****
\small\itshape
\caption{\small\itshape src IN mask OP dst}
! \label{layers}
\end{centering}
\end{figure}
--- 354,358 ----
\small\itshape
\caption{\small\itshape src IN mask OP dst}
! \label{porter_duff}
\end{centering}
\end{figure}
***************
*** 378,382 ****
The best way to do this would be to perform compositing with a
mask surface directly without the creation of an intermediate surface.
! Even though the fixed OpenGL pipeline doesn't seem to allow for such an
operation, \libname{} is able to do this on hardware that support
fragment programs. Fragment programs allow for fragment level
--- 380,384 ----
The best way to do this would be to perform compositing with a
mask surface directly without the creation of an intermediate surface.
! Even though the fixed OpenGL pipeline does not seem to allow for such an
operation, \libname{} is able to do this on hardware that support
fragment programs. Fragment programs allow for fragment level
***************
*** 408,412 ****
are power of two sized. If surface dimensions are of this size
\libname{} can let OpenGL handle the tiling for maximum efficiency.
! For surfaces that don't have power of two sized dimensions,
\libname{} will repeat the surfaces manually by performing multiple
texturing operations.
--- 410,414 ----
are power of two sized. If surface dimensions are of this size
\libname{} can let OpenGL handle the tiling for maximum efficiency.
! For surfaces that do not have power of two sized dimensions,
\libname{} will repeat the surfaces manually by performing multiple
texturing operations.
***************
*** 447,451 ****
occur whenever an analog signal is point sampled to convert it into
a digital signal, and the sample rate is to low.
! The number of samples don't contain enough information to represent the
actual source signal. Instead the samples seem to represent a different
signal of lower frequency, called an aliased signal.
--- 449,453 ----
occur whenever an analog signal is point sampled to convert it into
a digital signal, and the sample rate is to low.
! The number of samples do not contain enough information to represent the
actual source signal. Instead the samples seem to represent a different
signal of lower frequency, called an aliased signal.
***************
*** 521,534 ****
implemented as multi-sampling, sometimes super-sampling. This is a
very fast model that works for all primitives, interrelationships,
! and rendering models. It's also well supported in current hardware,
since a couple of graphic card generations back. It requires some
extra memory, but typically less than for software super-sampling or
accumulation buffering. It yields decent-quality results but some
! people may not find them acceptable for small text. This doesn't
affect the choice in this case however, as anti-aliasing of text will
preferably be handled by an external font rendering library.
On high end systems this technique has potential for generating
! extremely high quality results with a relatively low cost. Unfortunately
! it is not always available for off-screen buffers (pbuffers).
The other techniques have been discarded mainly due to poor hardware
--- 523,537 ----
implemented as multi-sampling, sometimes super-sampling. This is a
very fast model that works for all primitives, interrelationships,
! and rendering models. It is also well supported in current hardware,
since a couple of graphic card generations back. It requires some
extra memory, but typically less than for software super-sampling or
accumulation buffering. It yields decent-quality results but some
! people may not find them acceptable for small text. This does not
affect the choice in this case however, as anti-aliasing of text will
preferably be handled by an external font rendering library.
On high end systems this technique has potential for generating
! extremely high quality results with a relatively low cost.
! Unfortunately, it is not always available for off-screen buffers
! (pbuffers).
The other techniques have been discarded mainly due to poor hardware
***************
*** 551,555 ****
buffer and the stencil buffer is used for clipping when
compositing the supplied source surface onto the destination surface.
! This method for drawing indirect polygons is faster and doesn't require
off-screen drawing support. When rendering to on-screen surfaces only
on-screen multi-sample support is needed for anti-aliased polygons.
--- 554,558 ----
buffer and the stencil buffer is used for clipping when
compositing the supplied source surface onto the destination surface.
! This method for drawing indirect polygons is faster and does not require
off-screen drawing support. When rendering to on-screen surfaces only
on-screen multi-sample support is needed for anti-aliased polygons.
***************
*** 563,567 ****
and colors are linearly interpolated between the vertices. Direct
polygons have the advantages of not requiring an intermediate off-screen
! surface or stencil buffer and are therefor faster, and supported on more
hardware. Direct polygons might not produce the same results as indirect
polygons when the alpha color component is not equal to one and should
--- 566,570 ----
and colors are linearly interpolated between the vertices. Direct
polygons have the advantages of not requiring an intermediate off-screen
! surface or stencil buffer and are therefore faster, and supported on more
hardware. Direct polygons might not produce the same results as indirect
polygons when the alpha color component is not equal to one and should
***************
*** 677,681 ****
\Libname{} allows you to create programmatic surfaces. A
! programmatic surface doesn't contain any actual image data, only
a minimal set of attributes. These attributes describe how to calculate
the color for each fragment of the surface.
--- 680,684 ----
\Libname{} allows you to create programmatic surfaces. A
! programmatic surface does not contain any actual image data, only
a minimal set of attributes. These attributes describe how to calculate
the color for each fragment of the surface.
***************
*** 697,701 ****
where it can be used with linear and radial patterns. This allows
applications to use linear and radial patterns for wide range of
! shading effects. e.g. linear color gradients and Gaussian shading.
By setting the \emph{extend} attribute of a color range to
\emph{pad, repeat} or \emph{reflect}, the application can also control
--- 700,704 ----
where it can be used with linear and radial patterns. This allows
applications to use linear and radial patterns for wide range of
! shading effects. For example, linear color gradients and Gaussian shading.
By setting the \emph{extend} attribute of a color range to
\emph{pad, repeat} or \emph{reflect}, the application can also control
***************
*** 723,727 ****
off-screen drawing.
! In addition to the 2D drawing functions \libname{} also
provides a set of functions that make it possible to use
\libname{} as a cross-platform OpenGL layer. The following three
--- 726,730 ----
off-screen drawing.
! In addition to the 2D drawing functions, \libname{} also
provides a set of functions that make it possible to use
\libname{} as a cross-platform OpenGL layer. The following three
***************
*** 738,742 ****
surface by calling the \libnamespace\_gl\_begin function with the
surface as parameter. The surface can be either an on- or off-screen
! surface. After a call to \libnamespace\_gl\_begin all OpenGL drawing
will be routed to the \libname{} surface. The \libnamespace\_gl\_end
function must be called before any other \libname{} function can be
--- 741,745 ----
surface by calling the \libnamespace\_gl\_begin function with the
surface as parameter. The surface can be either an on- or off-screen
! surface. After a call to \libnamespace\_gl\_begin, all OpenGL drawing
will be routed to the \libname{} surface. The \libnamespace\_gl\_end
function must be called before any other \libname{} function can be
***************
*** 812,817 ****
\label{section: Results}
! Right now the library hasn't been tested that much in real
! applications since it's relatively early in the development process.
Some test and benchmark utilities have been developed to analyze library
functionality with respect to accuracy and performance.
--- 815,820 ----
\label{section: Results}
! Right now the library has not been tested that much in real
! applications since it is relatively early in the development process.
Some test and benchmark utilities have been developed to analyze library
functionality with respect to accuracy and performance.
***************
*** 820,832 ****
The quality of the visual output from \libname{} compares quite well to the
! corresponding output from Xrender. Most objects tessellated by the cairo
! library are rendered without noticeable differences compared to Xrender
! using \libname{}. However, in some complex objects a slight
! variation can be seen between \libname's output and Xrender's output.
! Figure~\ref{Infinity Sign 1} and~\ref{Infinity Sign 2} illustrates the
! output inconsistencies for aliased rendering. The infinite sign is
! tessellated into 370 trapezoids by the cairo library, which are then
! rendered using \libname{} and Xrender. Both figures are magnified to
! better show the output differences.
\begin{figure}[h!tbp]
--- 823,835 ----
The quality of the visual output from \libname{} compares quite well to the
! corresponding output from XFree86's Render implementation (Xrender).
! Most objects tessellated by the cairo library are rendered without
! noticeable differences compared to Xrender using \libname{}. However, in
! some complex objects a slight variation can be seen between \libname's
! output and Xrender's output. Figure~\ref{Infinity Sign 1}
! and~\ref{Infinity Sign 2} illustrates the output inconsistencies for
! aliased rendering. The infinite sign is tessellated into 370 trapezoids
! by the cairo library, which are then rendered using \libname{} and
! Xrender. Both figures are magnified to better show the output differences.
\begin{figure}[h!tbp]
***************
*** 851,855 ****
the output between \libname{} and Xrender. The number of samples used
for multi-sampling has a big effect on the anti-aliasing quality.
! On older hardware, anti-aliasing isn't even guaranteed as it depends on
relatively new OpenGL extensions. Nevertheless, if \libname{} is run on
fairly modern graphics hardware, very similar results are achieved with
--- 854,858 ----
the output between \libname{} and Xrender. The number of samples used
for multi-sampling has a big effect on the anti-aliasing quality.
! On older hardware, anti-aliasing is not even guaranteed, as it depends on
relatively new OpenGL extensions. Nevertheless, if \libname{} is run on
fairly modern graphics hardware, very similar results are achieved with
***************
*** 890,894 ****
Rendermark compares the rendering performance of \libname{}, Xrender and
Imlib2~\cite{imlib2} by doing a set of basic operations a repeated number
! of times. Comparison with Imlib2 is interesting as it's promoted as
the fastest image compositing, rendering and manipulation library for X.
Imlib2 performs all its rendering operations on client-side image buffers, so
--- 893,897 ----
Rendermark compares the rendering performance of \libname{}, Xrender and
Imlib2~\cite{imlib2} by doing a set of basic operations a repeated number
! of times. Comparison with Imlib2 is interesting as it is promoted as
the fastest image compositing, rendering and manipulation library for X.
Imlib2 performs all its rendering operations on client-side image buffers, so
***************
*** 953,959 ****
\item \emph{blur.}
blends one image onto another using the over operator with
! a blur filter. For \libname{} this means applying a 3x3 mean blur
! convolution filter. The version of Xrender used for this test doesn't
! support convolution filters, and the test is therefor skipped.
\end{itemize}
--- 956,962 ----
\item \emph{blur.}
blends one image onto another using the over operator with
! a blur filter. For \libname{}, this means applying a 3x3 mean blur
! convolution filter. The version of Xrender used for this test does
! not support convolution filters, and the test is therefore skipped.
\end{itemize}
***************
*** 1095,1102 ****
\section{Conclusion}
! During the development of \libname{} we've found that with the OpenGL
API and the extensions available today, along with 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.
This is an important conclusion as the desire for having an X server
running on top of OpenGL grows rapidly.
--- 1098,1105 ----
\section{Conclusion}
! During the development of \libname{} we have found that with the OpenGL
API and the extensions available today, along with the wide range of
! hardware supporting them, it is not only possible to create an
! Render-like interface on top of OpenGL, it is actually very efficient.
This is an important conclusion as the desire for having an X server
running on top of OpenGL grows rapidly.
***************
*** 1133,1137 ****
\end{itemize}
! Of course the future will demand new features from the library, since it's
an area of continuous development.
--- 1136,1140 ----
\end{itemize}
! Of course the future will demand new features from the library, since it is
an area of continuous development.
More information about the cairo-commit
mailing list