# [cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex,1.24,1.25

David Reveman commit at pdx.freedesktop.org
Mon Aug 15 11:12:59 PDT 2005

Committed by: davidr

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

Modified Files:
opengl_freenix04.tex
Log Message:
More text

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.24
retrieving revision 1.25
diff -C2 -d -r1.24 -r1.25
*** a/opengl_freenix04.tex	23 Feb 2004 13:49:09 -0000	1.24
--- b/opengl_freenix04.tex	23 Feb 2004 15:12:08 -0000	1.25
***************
*** 129,133 ****
and more consistent hardware acceleration of the rendering process.

-
Still the question remains about how to actually render all the graphics
with hardware support. OpenGL~\cite{gl:1.2.1} is the most widely used and
--- 129,132 ----
***************
*** 528,551 ****
surfaces when rendering indirect polygons.

-
\subsection{Text Rendering}

Current versions of \libname{} has no built in text support.
!     Glyph rasterization and glyph management should 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.
!
!     Right now \libname{} renders text at around 50000 glyphs/sec.
!     But major part of the rendering time is CPU time in the library and
!     we are confident that after some profiling and optimization glyph
!     rendering speed could be at least doubled.

!     For optimal glyph rendering speed, built in text rendering support
!     needs to be added \libname{}.

-     \edannote{Built in text support or not? We'll see after we've done
-               some profiling and optimizations.}
-
\subsection{Convolution Filters}

--- 527,543 ----
surfaces when rendering indirect polygons.

\subsection{Text Rendering}

Current versions of \libname{} has no built in text support.
!     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 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.

\subsection{Convolution Filters}

***************
*** 617,629 ****
the color for each pixel in the surface.

!     Programmetic surfaces can be used for wide range of effects,
!

!     Programmetic surfaces requires fragment program support.

!     \edannote{Maybe a picture showing results form composite with
!               a programmatic surface}

\edannote{Programmatic surfaces are not implemented yet but I've
--- 609,627 ----
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
!     radial. A linear gradient defines two points which form the color
!     transition vector. A radial gradient defines a center point and a
!     radius, together they form a dynamic transisiton vector around the
!     center point.

!     As all programmetic surfaces are implemented using fragment programs
!     they will only be available on hardware supporting the fragment program
!     extension.

!     \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
***************
*** 653,675 ****
Allowing for the applications to perform ordinary OpenGL calls in this
way enables \libname to also act as an easy to use toolkit on top of
!     OpenGL. The initialization process then becomes much simplified and it takes
!     only a few lines of code to set up a powerful OpenGL drawing environment
!     for on- and offscreeen rendering.

An example of usage is application that implements a visual effect
like a 3D transformation on a 2D surface created with \libname{}.
Something like the well known cube effect in Mac OS X's user switching
!     procedure could easily be implemented with a \libname{} application in this
!     fashion.
!
!     \subsection{Still Under Construction}
!
!     Most parts of the Render specification have been implemented but there are
!     still some issues that need to be addressed.
!
!     Disjoint and Conjoint operators.

-     Sub-pixel ordering.
-
\section{Results}

--- 651,664 ----
Allowing for the applications to perform ordinary OpenGL calls in this
way enables \libname to also act as an easy to use toolkit on top of
!     OpenGL. The initialization process then becomes much simplified and it
!     takes only a few lines of code to set up a powerful OpenGL drawing
!     environment for on- and offscreeen rendering.

An example of usage is application that implements a visual effect
like a 3D transformation on a 2D surface created with \libname{}.
Something like the well known cube effect in Mac OS X's user switching
!     procedure could easily be implemented with a \libname{} application in
!     this fashion.

\section{Results}

***************
*** 778,814 ****
\section{Conclusion}

!   \section{Future Work}

!   \edannote {To be updated}

As of today the existing implementation of the library supports all
!   the basic functionality initially set up for the project. But still the
!   software is in an early stage of development and lots of work remains for
!   making it stable and optimized with regards to performance and accuracy.
!   A deadline for the project has been set for March 2004. The aim is to have
!   a useful library by that time as well as complete documentation of the
!   project. A presentation of the work will be held at Umeå University at
!   that time but development and maintenance of the software will certainly
!   stretch beyond that date.

!   Of course the future will demand new features from the library as it is an
!   area of continuous development. For example in the near future new functions
!   for the creation and compositing of glyph sets probably need to be added for
!   more efficient rendering of text.

!   Special functions for more efficient rendering of gradients could also be

!   in the full paper.

!   \section{Visions}

!   \edannote {To be updated}

!   The Render compositing model has one major weakness when used with OpenGL,
!   and that is that all compositing operations that use a mask surface require
!   that OpenGL creates an intermediate surface and perform the compositing
!   in two steps.

The X desktop seems to be going into a new era and cairo is definitely the
--- 767,817 ----
\section{Conclusion}

!   During the development of \libname{} we've found that with the OpenGL
!   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. We're not all the way there yet but with
!   the current version of \libname{} we've taken a big step.

!   \section{Future Work}

As of today the existing implementation of the library supports all
!   the basic functionality initially set up for the project. But there are
!   still some important features missing and the software is in an early
!   stage of development and lots of work remains for making it stable and
!   optimized with regards to performance and accuracy.

!   The following list contains those features that most importantly need to
!   be addressed in future versions of the library.

!   \begin{itemize}
!     \item \bf{Text rendering}
!           Built in text rendering will allow much better glyph rendering
!           speeds and remove complex glyph management from the application.
!     \item \bf{Sub-pixel rendering}
!           Sub-pixel rendering can be used to effectively increase the
!           horizontal resolution of LCD displays. This will require
!           support for compositing each color component with different
!     \item \bf{Conjoint operators}
!     \item \bf{Disjoint operators}
!           For tesselating figures with anti-aliased edges.
!   \end{itemize}

!   \edannote{Thought maybe sub-pixel rendering could be possible
!             maybe I'm way off here. I'll do some testing soon and we'll
!             see what we can do.}

!   \edannote{Conjoint and Disjoint operators, this might
!             be done with one of the many blending extensions that exists.
!             If not, we can always have both the source and destinations as
!             textures and do all blending using fragment programs, slow and
!             complex though.}

!   Of course the future will demand new features from the library as it is an
!   area of continuous development.

!   \section{Visions}

The X desktop seems to be going into a new era and cairo is definitely the
***************
*** 817,824 ****
importance. Plans for the creation of an X server that will use OpenGL for
all rendering are currently being made and this library, or the work behind
!   the library, can hopefully be usable for this purpose.
!

\section{Acknowledgments}
We would like to thank Carl Worth, Keith Packard, and all of the
people involved in the development of cairo for being helpful and
--- 820,827 ----
importance. Plans for the creation of an X server that will use OpenGL for
all rendering are currently being made and this library, or the work behind
!   the library, can hopefully be usable for this purpose.

\section{Acknowledgments}
+
We would like to thank Carl Worth, Keith Packard, and all of the
people involved in the development of cairo for being helpful and