[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex, 1.41,
1.42
David Reveman
commit at pdx.freedesktop.org
Mon Apr 5 07:15:32 PDT 2004
Committed by: davidr
Update of /cvs/cairo/papers/opengl_freenix04
In directory pdx:/tmp/cvs-serv4178
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.41
retrieving revision 1.42
diff -C2 -d -r1.41 -r1.42
*** a/opengl_freenix04.tex 5 Apr 2004 13:18:44 -0000 1.41
--- b/opengl_freenix04.tex 5 Apr 2004 14:15:29 -0000 1.42
***************
*** 117,132 ****
style compositing operators. All pixel manipulations are carried out
through this operation. This provides for a simple and consistent model
! throughout the rendering system.
! XFree86's\cite{xfree86} Render implementation 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. To fall back on software means that all calculations
! are processed by the local CPU. For most XFree86 drivers, image
! data lives in video memory, so for the CPU to be able to access this data
! it must first be fetched from video memory. The CPU can then perform
! its calculations and the image data must then be transfered back to video
! memory.
The ideal situation would be to have XAA Render hooks for all Render
--- 117,137 ----
style compositing operators. All pixel manipulations are carried out
through this operation. This provides for a simple and consistent model
! throughout the rendering system.
! X Render allow us to perform advanced graphics operations on the
! server-side. Graphics operations that are performed on the server-side
! can be accelerated by graphics hardware. XFree86's\cite{xfree86} Render
! implementation 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. To fall back on
! software means that all graphics computations are processed by the regular
! CPU. For most XFree86 drivers, image data lives in video memory, so for
! the CPU to be able to access this data it must first be fetched from
! video memory. The CPU can then perform its computations and the image
! data must then be transfered back to video memory. The result of such a
! software fall-back is most likely to be slower than if the operation would
! have been done on client-side with all image data already local to the
! CPU.
The ideal situation would be to have XAA Render hooks for all Render
***************
*** 135,139 ****
Unfortunately, not many drivers have much support for XAA Render hooks at
this point. This results in inconsistent acceleration between different
! drivers and hardware.
\subsection{\Libname{} Fundamentals}
--- 140,144 ----
Unfortunately, not many drivers have much support for XAA Render hooks at
this point. This results in inconsistent acceleration between different
! rendering operations, different drivers and different hardware.
\subsection{\Libname{} Fundamentals}
***************
*** 249,253 ****
by using an immediate rendering model designed for the latest
hardware extensions. Immediate data is resident in graphics hardware
! and offscreen drawing is a native part of the rendering model.
\section{Implementation and Design}
--- 254,258 ----
by using an immediate rendering model designed for the latest
hardware extensions. Immediate data is resident in graphics hardware
! and off-screen drawing is a native part of the rendering model.
\section{Implementation and Design}
***************
*** 306,318 ****
entire model has changed since the previous frame.
! \subsection{Offscreen Drawing}
! Offscreen drawing is an essential part of an immediate mode 2D graphics
! API. Even though support for offscreen 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 makes offscreen rendering
possible in OpenGL. Pbuffers are allocated independently of the
framebuffer and usually stored in video memory. The process of
--- 311,323 ----
entire model has changed since the previous frame.
! \subsection{Off-screen Drawing}
! 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 makes off-screen rendering
possible in OpenGL. Pbuffers are allocated independently of the
framebuffer and usually stored in video memory. The process of
***************
*** 320,328 ****
rendering to the frambuffer. However, as pbuffers 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, 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 to software
! rendering in cases where \libname{} is not able to carry out offscreen
drawing operations. For example, the cairo library handles this
gracefully using image buffers.
--- 325,333 ----
rendering to the frambuffer. However, as pbuffers is a relatively
new feature in the OpenGL world, it is not yet supported by all
! hardware and all drivers. When support for off-screen drawing is
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 to software
! rendering in cases where \libname{} is not able to carry out off-screen
drawing operations. For example, the cairo library handles this
gracefully using image buffers.
***************
*** 366,370 ****
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
--- 371,375 ----
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 off-screen
surface, which can be used for compositing using the in-operator.
This surface can then be composited onto the destination with an
***************
*** 493,497 ****
anti-aliasing of the rendered scene in an as wide spectra
of hardware and drivers as possible. As important as a nice
! onscreen result might be, performance issues are given a high
priority in the search for a suitable anti-aliasing model. Another
important criteria has been that they do not all fit well into the
--- 498,502 ----
anti-aliasing of the rendered scene in an as wide spectra
of hardware and drivers as possible. As important as a nice
! on-screen result might be, performance issues are given a high
priority in the search for a suitable anti-aliasing model. Another
important criteria has been that they do not all fit well into the
***************
*** 523,527 ****
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 offscreen buffers (pbuffers).
The other techniques have been discarded mainly due to poor hardware
--- 528,532 ----
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
***************
*** 531,542 ****
\Libname{} has two different methods for rendering indirect polygons.
! Using an intermediate offscreen surface or using a stencil buffer.
! The first method creates an offscreen surface containing only an alpha
channel. The polygons are then rendered into this intermediate surface,
which is then used as mask when compositing the supplied source surface
! onto the destination surface. This method requires offscreen drawing
support and anti-aliased polygon edges can
! only be rendered if offscreen multi-sample support is available.
Whenever a stencil buffer is available, it will be used for drawing
--- 536,547 ----
\Libname{} has two different methods for rendering indirect polygons.
! Using an intermediate off-screen surface or using a stencil buffer.
! The first method creates an off-screen surface containing only an alpha
channel. The polygons are then rendered into this intermediate surface,
which is then used as mask when compositing the supplied source surface
! onto the destination surface. This method requires off-screen drawing
support and anti-aliased polygon edges can
! only be rendered if off-screen multi-sample support is available.
Whenever a stencil buffer is available, it will be used for drawing
***************
*** 545,550 ****
compositing the supplied source surface onto the destination surface.
This method for drawing indirect polygons is faster and doesn't require
! offscreen drawing support. When rendering to onscreen surfaces only
! onscreen multi-sample support is needed for anti-aliased polygons.
Indirect polygons can be used for pattern filling of complex objects.
--- 550,555 ----
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.
Indirect polygons can be used for pattern filling of complex objects.
***************
*** 555,559 ****
surface. Each polygon vertex has a specific color associated with it
and colors are linearly interpolated between the vertices. Direct
! polygons have the advantages of not requiring an intermediate offscreen
surface or stencil buffer and are therefor faster and supported on more
hardware. Direct polygons might not produce the same results as indirect
--- 560,564 ----
surface. Each polygon vertex has a specific color associated with it
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
***************
*** 567,571 ****
Glyph rasterization and glyph management could however be handled by
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 on the test setup described in section
--- 572,576 ----
Glyph rasterization and glyph management could however be handled by
the application or a higher level library. For efficient text rendering,
! glyph sets with off-screen surfaces containing alpha masks should be
used. With external glyph management \libname{} renders text at
approximately 50000 glyphs/sec on the test setup described in section
***************
*** 714,718 ****
\Libname's backend system works as an abstraction layer over
the supported OpenGL layers and has genuine support for
! offscreen drawing.
In addition to the 2D drawing functions \libname{} also
--- 719,723 ----
\Libname's backend system works as an abstraction layer over
the supported OpenGL layers and has genuine support for
! off-screen drawing.
In addition to the 2D drawing functions \libname{} also
***************
*** 730,734 ****
An application can initiate ordinary OpenGL rendering to a \libname{}
surface by calling the \libnamespace\_gl\_begin function with the
! surface as parameter. The surface can be either an on- or offscreen
surface. After a call to \libnamespace\_gl\_begin all OpenGL drawing
will be routed to the \libname{} surface. The \libnamespace\_gl\_end
--- 735,739 ----
An application can initiate ordinary OpenGL rendering to a \libname{}
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
***************
*** 796,800 ****
Figure~\ref{opengl_3d_example} shows an example that render 2D graphics
! to an offscreen surface and then use it as a texture when drawing in 3D.
Applications, libraries and toolkits that use \libname{} as
--- 801,805 ----
Figure~\ref{opengl_3d_example} shows an example that render 2D graphics
! to an off-screen surface and then use it as a texture when drawing in 3D.
Applications, libraries and toolkits that use \libname{} as
***************
*** 883,887 ****
Imlib2~\cite{imlib2} by doing a set of basic operations repeated times.
Comparison with Imlib2 is interesting as it's promoted as the fastest
! image compositing, rendering and manipulation library for X.
Table~\ref{output_formats} lists the tested output formats and
--- 888,894 ----
Imlib2~\cite{imlib2} by doing a set of basic operations repeated 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
! no on-screen rendering results are available for Imlib2.
Table~\ref{output_formats} lists the tested output formats and
***************
*** 891,905 ****
\begin{footnotesize}
\begin{tabular}{l|l}
! im-on & Imlib2 onscreen \\
! \hline
! im-off & Imlib2 offscreen \\
\hline
! xr-on & Xrender onscreen \\
\hline
! xr-off & Xrender offscreen \\
\hline
! gl-on & GL onscreen \\
\hline
! gl-off & GL offscreen \\
\end{tabular}
\end{footnotesize}
--- 898,910 ----
\begin{footnotesize}
\begin{tabular}{l|l}
! im-off & Imlib2 off-screen \\
\hline
! xr-on & Xrender on-screen \\
\hline
! xr-off & Xrender off-screen \\
\hline
! gl-on & GL on-screen \\
\hline
! gl-off & GL off-screen \\
\end{tabular}
\end{footnotesize}
***************
*** 955,968 ****
\begin{table}[h!tbp]
\begin{footnotesize}
! \begin{tabular}{l || c | c | c | c | c | c}
! & im-on & im-off & xr-on & xr-off & gl-on & gl-off \\
\hline \hline
! over & 12.091 & 3.769 & 2.286 & 2.240 & 0.123 & 0.107 \\
\hline
! scale & 28.530 & 16.427 & 87.761 & 85.488 & 0.127 & 0.131 \\
\hline
! blend & 40.007 & 31.585 & 73.020 & 72.707 & 0.263 & 0.263 \\
\hline
! blur & 34.741 & 26.234 & - & - & 3.093 & 3.085 \\
\end{tabular}
\end{footnotesize}
--- 960,973 ----
\begin{table}[h!tbp]
\begin{footnotesize}
! \begin{tabular}{l || c | c | c | c | c}
! & im-off & xr-on & xr-off & gl-on & gl-off \\
\hline \hline
! over & 3.769 & 2.286 & 2.240 & 0.123 & 0.107 \\
\hline
! scale & 16.427 & 87.761 & 85.488 & 0.127 & 0.131 \\
\hline
! blend & 31.585 & 73.020 & 72.707 & 0.263 & 0.263 \\
\hline
! blur & 26.234 & - & - & 3.093 & 3.085 \\
\end{tabular}
\end{footnotesize}
***************
*** 981,988 ****
\begin{table}[h!tbp]
\begin{footnotesize}
! \begin{tabular}{l || c | c | c | c | c | c}
! & im-on & im-off & xr-on & xr-off & gl-on & gl-off \\
\hline \hline
! rect & 19.479 & 3.824 & 79.495 & 79.000 & 0.108 & 0.105 \\
\end{tabular}
\end{footnotesize}
--- 986,993 ----
\begin{table}[h!tbp]
\begin{footnotesize}
! \begin{tabular}{l || c | c | c | c | c}
! & im-off & xr-on & xr-off & gl-on & gl-off \\
\hline \hline
! rect & 3.824 & 79.495 & 79.000 & 0.108 & 0.105 \\
\end{tabular}
\end{footnotesize}
***************
*** 1013,1022 ****
\begin{table}[h!tbp]
\begin{footnotesize}
! \begin{tabular}{l || c | c | c | c | c | c}
! & im-on & im-off & xr-on & xr-off & gl-on & gl-off \\
\hline \hline
! tri1 & 39.078 & 2.978 & 66.555 & 63.191 & 0.071 & 0.070 \\
\hline
! tri2 & - & - & 2.078 & 1.950 & 0.055 & 0.074 \\
\end{tabular}
\end{footnotesize}
--- 1018,1027 ----
\begin{table}[h!tbp]
\begin{footnotesize}
! \begin{tabular}{l || c | c | c | c | c}
! & im-off & xr-on & xr-off & gl-on & gl-off \\
\hline \hline
! tri1 & 2.978 & 66.555 & 63.191 & 0.071 & 0.070 \\
\hline
! tri2 & - & 2.078 & 1.950 & 0.055 & 0.074 \\
\end{tabular}
\end{footnotesize}
***************
*** 1035,1042 ****
\begin{table}[h!tbp]
\begin{footnotesize}
! \begin{tabular}{l || c | c | c | c | c | c}
! & im-on & im-off & xr-on & xr-off & gl-on & gl-off \\
\hline \hline
! grad & 23.553 & 6.139 & - & - & 1.013 & 1.009 \\
\end{tabular}
\end{footnotesize}
--- 1040,1047 ----
\begin{table}[h!tbp]
\begin{footnotesize}
! \begin{tabular}{l || c | c | c | c | c}
! & im-off & xr-on & xr-off & gl-on & gl-off \\
\hline \hline
! grad & 6.139 & - & - & 1.013 & 1.009 \\
\end{tabular}
\end{footnotesize}
***************
*** 1085,1089 ****
compared to \libname{} except for the case were transformations
are used. \libname{} is then much faster than nvidia's driver, which
! seem unable to use acceleration with transformations.
\section{Conclusion}
--- 1090,1094 ----
compared to \libname{} except for the case were transformations
are used. \libname{} is then much faster than nvidia's driver, which
! most likely fall-backs to software rendering in this case.
\section{Conclusion}
***************
*** 1127,1135 ****
\end{itemize}
- \edannote{I thought maybe sub-pixel rendering could be possible
- by masking color component output using glColorMask but
- maybe I'm way off here. I'll do some testing soon and we'll
- see what we can do.}
-
Of course the future will demand new features from the library as it is an
area of continuous development.
--- 1132,1135 ----
***************
*** 1164,1169 ****
information is available at \url{http://cairographics.org/}.
- \edannote{soon available...}
-
\bibliography{opengl_freenix04}
\bibliographystyle{plain}
--- 1164,1167 ----
More information about the cairo-commit
mailing list