# [cairo-commit] papers/opengl_freenix04 jaggies.png, 1.2, 1.3 opengl_freenix04.tex, 1.39, 1.40

David Reveman commit at pdx.freedesktop.org
Sun Apr 4 12:26:26 PDT 2004

Committed by: davidr

Update of /cvs/cairo/papers/opengl_freenix04
In directory pdx:/tmp/cvs-serv11557

Modified Files:
jaggies.png opengl_freenix04.tex
Log Message:
jaggies and text

Index: jaggies.png
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/jaggies.png,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
Binary files /tmp/cvsmM8O0b and /tmp/cvsiWkqZd differ

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.39
retrieving revision 1.40
diff -C2 -d -r1.39 -r1.40
*** a/opengl_freenix04.tex	4 Apr 2004 11:47:20 -0000	1.39
--- b/opengl_freenix04.tex	4 Apr 2004 19:26:23 -0000	1.40
***************
*** 185,189 ****

To sum up these ideas, \libname{} is created to act as an interface on
!   top of OpenGL which provides the same consistent rendering model as
Render. This interface is implemented in such a way that it takes
advantage of the OpenGL hardware acceleration provided by modern graphics
--- 185,189 ----

To sum up these ideas, \libname{} is created to act as an interface on
!   top of OpenGL, which provides the same consistent rendering model as
Render. This interface is implemented in such a way that it takes
advantage of the OpenGL hardware acceleration provided by modern graphics
***************
*** 359,368 ****
use a pbuffer directly 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.
--- 359,368 ----
use a pbuffer directly as a texture.

!     The optional mask surface that 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.
***************
*** 371,375 ****
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 which supports
fragment programs. Fragment programs allows for fragment level
programmability in OpenGL and in combination with multi-texturing
--- 371,375 ----
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 allows for fragment level
programmability in OpenGL and in combination with multi-texturing
***************
*** 567,571 ****
used. With external glyph management \libname{} renders text at
approximately 50000 glyphs/sec on the test setup described in section
!     \ref{Results}.

Built in text handling is planned for future versions of the library and
--- 567,571 ----
used. With external glyph management \libname{} renders text at
approximately 50000 glyphs/sec on the test setup described in section
!     \ref{section: Results}.

Built in text handling is planned for future versions of the library and
***************
*** 676,680 ****

\Libname{} also support programmatic surfaces that represent linear or
!     radial transition vector patterns. A linear pattern defines two points
which form a transition vector. A radial gradient defines a center point
and a radius, together they form a dynamic transition vector around the
--- 676,680 ----

\Libname{} also support programmatic surfaces that represent linear or
!     radial transition vector patterns. A linear pattern defines two points,
which form a transition vector. A radial gradient defines a center point
and a radius, together they form a dynamic transition vector around the
***************
*** 714,718 ****

In addition to the 2D drawing functions \libname{} also
!     provides a set of functions which makes it possible to use
\libname{} as a cross-platform OpenGL layer. The following three
functions allow the application to use ordinary OpenGL calls
--- 714,718 ----

In addition to the 2D drawing functions \libname{} also
!     provides a set of functions that makes it possible to use
\libname{} as a cross-platform OpenGL layer. The following three
functions allow the application to use ordinary OpenGL calls
***************
*** 795,799 ****
to an offscreen surface and then use it as a texture when drawing in 3D.

!   Applications, libraries and toolkits which use \libname{} as
rendering backend will get both 2D and 3D support with the ability
two use all 2D surfaces as textures for 3D rendering.
--- 795,799 ----
to an offscreen surface and then use it as a texture when drawing in 3D.

!   Applications, libraries and toolkits that use \libname{} as
rendering backend will get both 2D and 3D support with the ability
two use all 2D surfaces as textures for 3D rendering.
***************
*** 816,822 ****
Figures~\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]
--- 816,822 ----
Figures~\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]
***************
*** 1001,1005 ****
\item \emph{tri2.}
Draws a set of triangles in one single rendering operation.
!           This type of operation is often used for rendering complex objects
which have been tessellated into (in this case) triangles.
Imlib2 skips this test as it lacks support for it.
--- 1001,1005 ----
\item \emph{tri2.}
Draws a set of triangles in one single rendering operation.
!           This type of operation is often used for rendering complex objects,
which have been tessellated into (in this case) triangles.
Imlib2 skips this test as it lacks support for it.
***************
*** 1081,1086 ****
Table~\ref{rendermark5} shows that nvidia's driver performs well
compared to \libname{} except for the case were transformations
!   are used. \libname{} is then much faster than nvidia's driver which
!   seems unable to use acceleration with transformation.

\section{Conclusion}
--- 1081,1086 ----
Table~\ref{rendermark5} shows that nvidia's driver performs well
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}
***************
*** 1135,1139 ****

The X desktop seems to be going into a new era and cairo is definitely the
!   2D graphics API which will be used in tomorrow's X applications. The
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
--- 1135,1139 ----

The X desktop seems to be going into a new era and cairo is definitely the
!   2D graphics API that will be used in tomorrow's X applications. The
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