[cairo-commit] papers/opengl_freenix04 .cvsignore,1.1,1.2 ChangeLog,1.1,1.2 opengl_freenix04.tex,1.2,1.3

[Carl Worth]

Committed by: cworth

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

Modified Files:
	.cvsignore ChangeLog opengl_freenix04.tex 
Log Message:

        * opengl_freenix04.tex: Fixed several, very minor spelling errors.


Index: .cvsignore
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** .cvsignore	15 Dec 2003 12:39:09 -0000	1.1
--- .cvsignore	15 Dec 2003 12:53:58 -0000	1.2
***************
*** 1 ****
--- 1,9 ----
  *.gz
+ *.aux
+ *.bbl
+ *.blg
+ *.dvi
+ *.log
+ *.ps
+ *.pdf
+ *.ps.gz

Index: ChangeLog
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/ChangeLog,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** ChangeLog	15 Dec 2003 12:39:09 -0000	1.1
--- ChangeLog	15 Dec 2003 12:53:58 -0000	1.2
***************
*** 1,4 ****
--- 1,6 ----
  2003-12-15  Carl Worth  <cworth at isi.edu>
  
+ 	* opengl_freenix04.tex: Fixed several, very minor spelling errors.
+ 
  	* cairo-demo-glc.png:
  	* cairo-demo-glc.eps:

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** opengl_freenix04.tex	15 Dec 2003 12:39:09 -0000	1.2
--- opengl_freenix04.tex	15 Dec 2003 12:53:58 -0000	1.3
***************
*** 50,57 ****
    tend to use more demanding graphic features like alpha blending, image 
    transformations and anti-aliasing.
!   Even with todays powerful computers these tasks constitute a heavy burden on 
!   the CPU. To relief the CPU, modern window systems have developed 2D-graphics
    engines which utilize the high performance rendering capabilities inherent in 
!   todays graphics hardware. In fact, much of the eye candy we have seen in these
    systems wouldn't even be feasible without hardware accelerated rendering.
    The one that has probably attracted the most attention is Apple's Quartz 
--- 50,57 ----
    tend to use more demanding graphic features like alpha blending, image 
    transformations and anti-aliasing.
!   Even with today's powerful computers these tasks constitute a heavy burden on 
!   the CPU. To relieve the CPU, modern window systems have developed 2D-graphics
    engines which utilize the high performance rendering capabilities inherent in 
!   today's graphics hardware. In fact, much of the eye candy we have seen in these
    systems wouldn't even be feasible without hardware accelerated rendering.
    The one that has probably attracted the most attention is Apple's Quartz 
***************
*** 60,65 ****
    this time called Longhorn~\cite{longhorn}.
  
!   The fact that this is a field in which the X Window system and the open source
!   community doesn't quite seem to keep up is what originally lead up to the 
    ideas behind this project. The main idea is to investigate the potential 
    usefulness of a 2D graphics library that can be 
--- 60,65 ----
    this time called Longhorn~\cite{longhorn}.
  
!   The fact that this is a field in which the X Window System and the open source
!   community doesn't quite seem to keep up is what originally led up to the 
    ideas behind this project. The main idea is to investigate the potential 
    usefulness of a 2D graphics library that can be 
***************
*** 69,78 ****
  
    What we need is a complete 2D graphics API that is accelerated by
!   graphics hardware. Much of work has already been done as we are very 
    fortunate to have the Cairo library~\cite{cairo}, an open source 
    library which provides a PDF-like 2D graphics API. One 
!   thing missing this far in Cairo is the ability to accelerate the rendering 
!   process  with todays high performance graphics hardware. 
!   The Cairo library which is a modern cross-platform 2D graphics API designed 
    for multiple output formats with Render semantics and provides a powerful 
    vector based drawing environment. So what we need is an output format for 
--- 69,78 ----
  
    What we need is a complete 2D graphics API that is accelerated by
!   graphics hardware. Much of the work has already been done as we are very 
    fortunate to have the Cairo library~\cite{cairo}, an open source 
    library which provides a PDF-like 2D graphics API. One 
!   thing missing thus far in Cairo is the ability to accelerate the rendering 
!   process  with today's high performance graphics hardware. 
!   The Cairo library is a modern cross-platform 2D graphics API designed 
    for multiple output formats with Render semantics and provides a powerful 
    vector based drawing environment. So what we need is an output format for 
***************
*** 91,95 ****
    Render-like interface on top of OpenGL. This research is concluded with 
    the implementation of an OpenGL 2D compositing library. The semantics of the
!   library is designed to precisely match the specification of the 
    X Render extension. Having the same semantics as Render allows for seamless 
    integration with the Cairo library that then will provide an attractive
--- 91,95 ----
    Render-like interface on top of OpenGL. This research is concluded with 
    the implementation of an OpenGL 2D compositing library. The semantics of the
!   library are designed to precisely match the specification of the 
    X Render extension. Having the same semantics as Render allows for seamless 
    integration with the Cairo library that then will provide an attractive
***************
*** 101,106 ****
  
    The development of the 2D compositing library and the other implementation
!   parts are made in an entirely open fashion, input from the open source 
!   community are regarded.
  
  
--- 101,106 ----
  
    The development of the 2D compositing library and the other implementation
!   parts are made in an entirely open fashion. Input from the open source 
!   community is regarded.
  
  
***************
*** 112,124 ****
    which will allow for the core of the library to perform its rendering 
    operations unaware of the structure of the underlaying GL layer. Having a 
!   virulized backend instead of just choosing a suitable layer at compile 
    time has the advantage of allowing the library to be compiled for use with
    multiple GL layers.
  
!   As of now the GLX backend is the only backend implemented but on request
    backends for other GL layers will be added.
  
    For any usable 2D graphics API, offscreen drawing is required. This is 
!   something GL has lacked efficient support for until recently. However as this 
    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 
--- 112,124 ----
    which will allow for the core of the library to perform its rendering 
    operations unaware of the structure of the underlaying GL layer. Having a 
!   virtualized backend instead of just choosing a suitable layer at compile 
    time has the advantage of allowing the library to be compiled for use with
    multiple GL layers.
  
!   As of now the GLX backend is the only backend implemented but on request,
    backends for other GL layers will be added.
  
    For any usable 2D graphics API, offscreen drawing is required. This is 
!   something GL has lacked efficient support for until recently. However, as this 
    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 
***************
*** 127,131 ****
    drawing can not be performed by our library.
  
!   All rendering operations are performed on and with so called surfaces, which 
    can be of type onscreen, offscreen or intermediate. Onscreen surfaces are 
    usually portions of the frame buffer. Offscreen surfaces are textures stored 
--- 127,131 ----
    drawing can not be performed by our library.
  
!   All rendering operations are performed with so-called surfaces, which 
    can be of type onscreen, offscreen or intermediate. Onscreen surfaces are 
    usually portions of the frame buffer. Offscreen surfaces are textures stored 
***************
*** 147,154 ****
    composited on the destination surface and we're all done. 
    Every time drawing is to be done onto an offscreen surface, an intermediate 
!   needs to be created so that the drawing can be done to this and the result can
    then be copied back to the texture.
  
!   Most parts of the Render specification has been implemented but there are
    still some issues that need to be addressed. The most obvious one being the 
    implementation of an anti-aliasing model. There are several ways to go, some 
--- 147,154 ----
    composited on the destination surface and we're all done. 
    Every time drawing is to be done onto an offscreen surface, an intermediate 
!   surface needs to be created so that the drawing can be done to this and the result can
    then be copied back to the texture.
  
!   Most parts of the Render specification have been implemented but there are
    still some issues that need to be addressed. The most obvious one being the 
    implementation of an anti-aliasing model. There are several ways to go, some 
***************
*** 157,161 ****
    means that they are drawn in the order which the end application wishes. This 
    means some complications when drawing correctly anti-aliased polygons with 
!   OpenGL in the old fashion way. The final paper will have a detailed 
    description of the model we have chosen and why we choose that model.
  
--- 157,161 ----
    means that they are drawn in the order which the end application wishes. This 
    means some complications when drawing correctly anti-aliased polygons with 
!   OpenGL in the old-fashioned way. The final paper will have a detailed 
    description of the model we have chosen and why we choose that model.
  
***************
*** 166,177 ****
    utilities for Cairo have been ported to use the new GL backend though. The 
    results have been satisfying both with respect to performance and accuracy. 
!   The figures shows a part of the output from the cairo-demo application, the 
    output image has been cut down only to save some space in this paper. 
    Figure 1 shows output from cairo-demo using xrender and figure 2 shows the 
    corresponding output using the GL backend for rendering.
!   Off course these pictures cannot be expected to show any great details of the 
!   result but it might give a ruff idea about the accuracy of the output. 
    Note that no anti-aliasing is applied to the image rendered by GL as it is not
!   yet implemented in a stable fashion. Yet you can se that the image rendered by
    GL compares rather well to that rendered by xrender. 
  
--- 166,177 ----
    utilities for Cairo have been ported to use the new GL backend though. The 
    results have been satisfying both with respect to performance and accuracy. 
!   The figures show a part of the output from the cairo-demo application, the 
    output image has been cut down only to save some space in this paper. 
    Figure 1 shows output from cairo-demo using xrender and figure 2 shows the 
    corresponding output using the GL backend for rendering.
!   Of course these pictures cannot be expected to show any great details of the 
!   result but it might give a rough idea about the accuracy of the output. 
    Note that no anti-aliasing is applied to the image rendered by GL as it is not
!   yet implemented in a stable fashion. Yet you can see that the image rendered by
    GL compares rather well to that rendered by xrender. 
  
***************
*** 199,209 ****
    performance with Cairo, using the different output formats including the new 
    GL backend developed in this project. The benchmark application currently 
!   contains two separate tests. The first one animates a semi transparent, stoked
    and filled Cairo path made up of several bezier curves that moves randomly 
    over a simple background image. This test shows the speed at which lots of 
    transparent trapezoids can be drawn using Cairo paths. 
  
!   The second test scales a background image and translates an other semi 
!   transparent image randomly across the screen, testing image compositing and 
    transformation performance.  
  
--- 199,209 ----
    performance with Cairo, using the different output formats including the new 
    GL backend developed in this project. The benchmark application currently 
!   contains two separate tests. The first one animates a semi-transparent, stoked
    and filled Cairo path made up of several bezier curves that moves randomly 
    over a simple background image. This test shows the speed at which lots of 
    transparent trapezoids can be drawn using Cairo paths. 
  
!   The second test scales a background image and translates another semi-transparent
!   image randomly across the screen, testing image compositing and 
    transformation performance.  
  
***************
*** 219,230 ****
    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 remain in making it stable 
    and optimized with regards to performance and accuracy. A deadline for the 
!   project has been set up in 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 
!   maintaining of the software will certainly stretch beyond that date. 
  
!   Off 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
--- 219,230 ----
    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
***************
*** 237,260 ****
    \section{Visions}
    The Render compositing model has one major weakness when used with OpenGL, and
!   that is that all compositing operations that uses a mask surface requires 
!   that OpenGL creates an intermediate surface and performs the compositing 
!   in two steps. If an extension for GL would exist that allows for the 
    blending of two textures with each other and then onto a drawable in one 
    operation the Render compositing model would be much more efficient. 
  
    The X desktop seems to be going into a new era and Cairo is definitely the
!   2D graphics API which will be used in tomorrows X applications. The 
!   support for hardware accelareted surfaces in Cairo might then be of big 
!   importance. Plans on the creation of a X server that will use OpenGL for
!   all rendering is currently being made and our library or the work behind the
!   library can hopefully be usable for this purpose. 
  
  
    \section{Acknowledgments}
!   We would like to thank Carl Worth and Keith Packard and along with all of the 
    people involved in the development of Cairo for being helpful and encouraging.
    We would also like to thank our internal supervisor along with the staff at 
    the department of Computing Science at Umeå University for supporting us in 
!   this project. Thereby approving the project for financial funding in terms of 
    study allowances. 
  
--- 237,260 ----
    \section{Visions}
    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 create an intermediate surface and perform the compositing 
!   in two steps. If an extension for GL would exist to allow for the 
    blending of two textures with each other and then onto a drawable in one 
    operation the Render compositing model would be much more efficient. 
  
    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 accelareted surfaces in Cairo might then be of great
!   importance. Plans for the creation of an X server that will use OpenGL for
!   all rendering are currently being made and our 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 encouraging.
    We would also like to thank our internal supervisor along with the staff at 
    the department of Computing Science at Umeå University for supporting us in 
!   this project, thereby approving the project for financial funding in terms of 
    study allowances.