[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex, 1.38, 1.39

[David Reveman]

Committed by: davidr

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

Modified Files:
	opengl_freenix04.tex 
Log Message:
fixes

Index: opengl_freenix04.tex
===================================================================
RCS file: /cvs/cairo/papers/opengl_freenix04/opengl_freenix04.tex,v
retrieving revision 1.38
retrieving revision 1.39
diff -C2 -d -r1.38 -r1.39
*** a/opengl_freenix04.tex	3 Apr 2004 17:59:12 -0000	1.38
--- b/opengl_freenix04.tex	4 Apr 2004 11:47:20 -0000	1.39
***************
*** 39,43 ****
    interfaces by making it possible to add more visual effects as well as 
    new usable functionalities. All together it makes the graphical 
!   interface a more hospitable as well as efficient environment for the user.
    
    Even with today's powerful computers these tasks constitute a heavy 
--- 39,43 ----
    interfaces by making it possible to add more visual effects as well as 
    new usable functionalities. All together it makes the graphical 
!   interface a more hospitable, as well as efficient, environment for the user.
    
    Even with today's powerful computers these tasks constitute a heavy 
***************
*** 65,69 ****
    effects for each available product generation. 
    
!   Unfortunately these features demand a lot of computation time from the CPU.
    In the past this has meant a slowdown throughout the entire system as
    well as a significant limitation in the kind of visual effects that could be 
--- 65,69 ----
    effects for each available product generation. 
    
!   Unfortunately, these features demand a lot of computation time from the CPU.
    In the past this has meant a slowdown throughout the entire system as
    well as a significant limitation in the kind of visual effects that could be 
***************
*** 75,83 ****
    own processor to boost performance levels. These processors are specialized 
    for computing graphical transformations, so they achieve better results than 
!   the general-purpose CPU. In addition, they free up the computer's CPU 
    to execute other tasks while the graphics accelerator is handling graphics
    computations.
  
!   Modern window systems have developed 2D-graphics engines which utilize the
    high performance rendering capabilities inherent in today's 3D-graphics
    hardware. In fact, much of the visual effects and advanced graphics that
--- 75,83 ----
    own processor to boost performance levels. These processors are specialized 
    for computing graphical transformations, so they achieve better results than 
!   the general purpose CPU. In addition, they free up the computer's CPU 
    to execute other tasks while the graphics accelerator is handling graphics
    computations.
  
!   Modern window systems have developed 2D-graphics engines, which utilize the
    high performance rendering capabilities inherent in today's 3D-graphics
    hardware. In fact, much of the visual effects and advanced graphics that
***************
*** 89,98 ****
    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 
!   equipped with the latest in modern accelerated graphics hardware.  
  
    \subsection{Traditional X Graphics}
--- 89,98 ----
    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 
!   equipped with the latest in modern graphics hardware.  
  
    \subsection{Traditional X Graphics}
***************
*** 112,118 ****
    supports are alpha compositing, anti-aliasing, sub-pixel positioning,
    polygon rendering, text rendering and image transformations. The core 
!   of Render is its image compositing model which borrows fundamental notions
    from the Plan 9 window system~\cite{pike:draw}. Render provides a unified
!   rendering operation which supports the Porter-Duff~\cite{porterduff:1984}
    style compositing operators. All pixel manipulations are carried out 
    through this operation. This provides for a simple and consistent model
--- 112,118 ----
    supports are alpha compositing, anti-aliasing, sub-pixel positioning,
    polygon rendering, text rendering and image transformations. The core 
!   of Render is its image compositing model, which borrows fundamental notions
    from the Plan 9 window system~\cite{pike:draw}. Render provides a unified
!   rendering operation, which supports the Porter-Duff~\cite{porterduff:1984}
    style compositing operators. All pixel manipulations are carried out 
    through this operation. This provides for a simple and consistent model
***************
*** 126,134 ****
    own XAA Render hooks in each driver to support it, which results in a
    duplicated effort. Unfortunately not many drivers have much support for
!   XAA Render hooks at this point, which results in inconsistent acceleration
    between different drivers and hardware.
  
    From the benchmarks made in the context of this project the conclusion can 
!   be drawn that the amount of accelerated rendering achieved by Render doesn't 
    seem to be enough for the complex visual effects addressed by this project. 
    See section~\ref{section: Results} Results for documented benchmark tests.
--- 126,134 ----
    own XAA Render hooks in each driver to support it, which results in a
    duplicated effort. Unfortunately not many drivers have much support for
!   XAA Render hooks at this point. This results in inconsistent acceleration
    between different drivers and hardware.
  
    From the benchmarks made in the context of this project the conclusion can 
!   be made that the amount of accelerated rendering achieved by Render doesn't 
    seem to be enough for the complex visual effects addressed by this project. 
    See section~\ref{section: Results} Results for documented benchmark tests.
***************
*** 149,153 ****
    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 it's 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 
--- 149,153 ----
    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 
***************
*** 167,171 ****
        \small\itshape
        \caption{\small\itshape Different layers involved when an application
!                               uses cairo to render to an OpenGL surface.}
        \label{layers}
      \end{centering}
--- 167,172 ----
        \small\itshape
        \caption{\small\itshape Different layers involved when an application
!                               uses cairo to render graphics to an OpenGL
!                               surface.}
        \label{layers}
      \end{centering}
***************
*** 216,226 ****
  
    The latest generation of graphics hardware allow the application to 
!   replace the conventional per-vertex calculations and per-fragment
!   calculations done in the vertex operations and fragment operations 
!   processing stages shown in figure~\ref{pipe} with application defined
    computations. These computations are defined with assembler-like
    languages that an OpenGL implementation compiles into vertex and
!   fragment programs. The vertex and fragment programs provides an
!   interface for directly accessing hardware and has been proven very
    useful in the development of \libname{}.
  
--- 217,226 ----
  
    The latest generation of graphics hardware allow the application to 
!   replace the conventional vertex operations and fragment operations 
!   processing stages shown in figure~\ref{pipe}, with application defined
    computations. These computations are defined with assembler-like
    languages that an OpenGL implementation compiles into vertex and
!   fragment programs. The vertex and fragment programs provide an
!   interface for directly accessing hardware and have been proven very
    useful in the development of \libname{}.
  
***************
*** 229,233 ****
    Some of the proprietary window systems have created their own  
    graphic engines that can perform hardware accelerated rendering in a similar 
!   manner to the model discussed here. The one that has probably attracted the 
    most attention is Apple's Quartz Extreme~\cite{quartzextreme} compositing 
    engine used in Mac OS X~\cite{macosx}. The user interface in Mac OS X is 
--- 229,233 ----
    Some of the proprietary window systems have created their own  
    graphic engines that can perform hardware accelerated rendering in a similar 
!   manner to the model discussed here. The one, that has probably attracted 
    most attention is Apple's Quartz Extreme~\cite{quartzextreme} compositing 
    engine used in Mac OS X~\cite{macosx}. The user interface in Mac OS X is 
***************
*** 242,247 ****
    \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 the Enlightenment
!   Foundation Libraries. \Libname{} is unique regards to these libraries
    by using an immediate rendering model designed for the latest
    hardware extensions. Immediate data is resident in graphics hardware
--- 242,247 ----
    \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
    by using an immediate rendering model designed for the latest
    hardware extensions. Immediate data is resident in graphics hardware
***************
*** 261,265 ****
      the core of \libname{} through a virtualized backend. Each backend
      needs to provide a table of OpenGL function pointers and few additional
!     functions which will allow for the core to perform its rendering
      operations unaware of the structure of the underlying OpenGL layer.
  
--- 261,265 ----
      the core of \libname{} through a virtualized backend. Each backend
      needs to provide a table of OpenGL function pointers and few additional
!     functions, which will allow for the core to perform its rendering
      operations unaware of the structure of the underlying OpenGL layer.