[cairo-commit] papers/opengl_freenix04 opengl_freenix04.tex, 1.46, 1.47

David Reveman commit at pdx.freedesktop.org
Wed Apr 7 07:40:09 PDT 2004


Committed by: davidr

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

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.46
retrieving revision 1.47
diff -C2 -d -r1.46 -r1.47
*** a/opengl_freenix04.tex	7 Apr 2004 11:21:18 -0000	1.46
--- b/opengl_freenix04.tex	7 Apr 2004 14:40:05 -0000	1.47
***************
*** 54,58 ****
    accelerated output.
  
!   Furthermore an effort has been made to investigate if the level of hardware 
    acceleration provided by the X Window System can be improved 
    by using \libname{} to carry out its fundamental drawing operations.
--- 54,58 ----
    accelerated output.
  
!   Furthermore, an effort has been made to investigate if the level of hardware 
    acceleration provided by the X Window System can be improved 
    by using \libname{} to carry out its fundamental drawing operations.
***************
*** 91,96 ****
    Furthermore, these ideas have been applied to the X Window System 
    (X)~\cite{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 
--- 91,95 ----
    Furthermore, these ideas have been applied to the X Window System 
    (X)~\cite{x}, to see if they could improve hardware acceleration of
!   graphical applications and thereby making way for more advanced graphics. 
  
    The software that is developed in this project will primarily target users 
***************
*** 99,103 ****
    \subsection{Traditional X Graphics}
  
!   X wasn't originally designed for the advanced graphics that can be
    seen on modern desktops. The main reason is that graphics
    hardware available at the time was not fast enough. Application
--- 98,102 ----
    \subsection{Traditional X Graphics}
  
!   X was not originally designed for the advanced graphics that can be
    seen on modern desktops. The main reason is that graphics
    hardware available at the time was not fast enough. Application
***************
*** 120,124 ****
    throughout the rendering system.
  
!   X Render allows us to perform advanced graphics operations on
    server-side. Graphics operations that are performed on server-side
    can be accelerated by graphics hardware. XFree86's\cite{xfree86} Render
--- 119,123 ----
    throughout the rendering system.
  
!   Render allows us to perform advanced graphics operations on
    server-side. Graphics operations that are performed on server-side
    can be accelerated by graphics hardware. XFree86's\cite{xfree86} Render
***************
*** 127,131 ****
    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
--- 126,130 ----
    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
    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
***************
*** 145,149 ****
    \subsection{\Libname{} Fundamentals}
  
!   Render seems to be the ideal model to build \libname{} upon. It provides
    the necessary operations needed to carry out the rendering for 
    modern 2D graphics applications. Hence \libname{} is designed
--- 144,148 ----
    \subsection{\Libname{} Fundamentals}
  
!   The Render model seems to be ideal to build \libname{} upon. It provides
    the necessary operations needed to carry out the rendering for 
    modern 2D graphics applications. Hence \libname{} is designed
***************
*** 186,191 ****
    understandable because it was used primarily for 3D applications like
    visualizations and games in the past. However, it is just as well suited for
!   the kind of 2D graphics discussed in this paper, where transformations and
!   other visual effects play a central part, much like in traditional 
    3D applications. OpenGL is the most widely used and supported graphics 
    API available today, it is well supported in hardware and very portable.
--- 185,190 ----
    understandable because it was used primarily for 3D applications like
    visualizations and games in the past. However, it is just as well suited for
!   2D graphics of the nature discussed in this paper, where transformations
!   and other visual effects play a central part, much like in traditional 
    3D applications. OpenGL is the most widely used and supported graphics 
    API available today, it is well supported in hardware and very portable.
***************
*** 212,216 ****
    with the order of internal operations used in OpenGL implementations is of 
    great importance. This is often visualized as a series of processing
!   stages called the OpenGL rendering pipeline. This ordering, is not a
    strict rule of how OpenGL is implemented but provides a reliable guide
    for predicting what OpenGL will do.
--- 211,215 ----
    with the order of internal operations used in OpenGL implementations is of 
    great importance. This is often visualized as a series of processing
!   stages called the OpenGL rendering pipeline. This ordering is not a
    strict rule of how OpenGL is implemented but provides a reliable guide
    for predicting what OpenGL will do.
***************
*** 225,229 ****
    \end{figure}
  
!   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
--- 224,228 ----
    \end{figure}
  
!   The latest generations 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
***************
*** 237,254 ****
  
    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 
!   loaded with advanced graphics effects of the nature discussed in this paper. 
!   They all seem to run smoothly without bringing too much load on the CPU.
    
    Microsoft is also developing something similar in their 
!   Avalon~\cite{avalon} graphics engine. It will be the core of all hardware
!   accelerated graphics handling in the next windows version, currently
    being developed under the name Windows Longhorn~\cite{longhorn}.
  
    \Libname{} is not the first Open Source graphics library that 
!   has been layered on top of OpenGL. For example, Evas~\cite{evas}; 
    a hardware accelerated canvas API, which is part of the Enlightenment
    Foundation Libraries. \Libname{} is unique compared to these libraries
--- 236,254 ----
  
    Some of the proprietary window systems have created their own  
!   graphics 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 loaded with advanced graphics effects of the nature discussed
!   in this paper. They all seem to run smoothly without bringing too much
!   load on the CPU.
    
    Microsoft is also developing something similar in their 
!   Avalon~\cite{avalon} graphics engine. It will be a fundamental part for
!   hardware accelerated 2D graphics in the next windows version, currently
    being developed under the name Windows Longhorn~\cite{longhorn}.
  
    \Libname{} is not the first Open Source graphics library that 
!   has been layered on top of OpenGL. An example, Evas~\cite{evas}; 
    a hardware accelerated canvas API, which is part of the Enlightenment
    Foundation Libraries. \Libname{} is unique compared to these libraries
***************
*** 260,264 ****
  
    The development of \libname{} and the other parts have been made in an 
!   entirely open fashion. Input from the open source community have been
    regarded.
  
--- 260,264 ----
  
    The development of \libname{} and the other parts have been made in an 
!   entirely open fashion. Input from the open source community has been
    regarded.
  
***************
*** 268,272 ****
      library is designed to be usable with any of various OpenGL 
      layers. Different OpenGL layers can be used by plugging them in to 
!     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
--- 268,272 ----
      library is designed to be usable with any of various OpenGL 
      layers. Different OpenGL layers can be used by plugging them in to 
!     the core of \libname{} through a virtualized backend system. 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
***************
*** 278,282 ****
      core library.
  
!     The advantages of having a virtualized backend and different backend
      libraries instead of just choosing the code to compile using preprocessor
      macros are important. It makes the link between the OpenGL
--- 278,282 ----
      core library.
  
!     The advantages of having a virtualized backend system and different backend
      libraries instead of just choosing the code to compile using preprocessor
      macros are important. It makes the link between the OpenGL
***************
*** 298,302 ****
      by the application and immediately draws the appropriate objects.
  
!     The opposite would be to have a retained rendering model. A rendering 
      model is operating in retained mode if it retains a copy of all the data 
      describing a model. Retained mode rendering requires a completely
--- 298,302 ----
      by the application and immediately draws the appropriate objects.
  
!     The opposite is to have a retained rendering model. A rendering 
      model is operating in retained mode if it retains a copy of all the data 
      describing a model. Retained mode rendering requires a completely
***************
*** 324,328 ****
      frame-buffer and usually stored in video memory. The process of 
      rendering to pbuffer is accelerated by hardware in the same way as
!     rendering to the frame-buffer. 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
--- 324,328 ----
      frame-buffer and usually stored in video memory. The process of 
      rendering to pbuffer is accelerated by hardware in the same way as
!     rendering to the frame-buffer. However, as the pbuffer 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
***************
*** 361,368 ****
      rectangular polygon is used. This means that the source surfaces must
      be available as textures. The default method for making a surface 
!     available as a texture is to have the graphics
!     hardware copy the pixel data into a texture image. As this is a
      relatively slow operation, \libname{} does its best to minimize the
!     area and number of occasions for this copy operation. On some hardware a 
      feature called render-texture is available that allows \libname{} to 
      completely eliminate the need for this copy operation and instead
--- 361,368 ----
      rectangular polygon is used. This means that the source surfaces must
      be available as textures. The default method for making a surface 
!     available as a texture is to have the graphics hardware copy the pixel
!     data from a drawable into a texture image. As this is a
      relatively slow operation, \libname{} does its best to minimize the
!     area and number of occasions for this copy operation. On some hardware, a 
      feature called render-texture is available that allows \libname{} to 
      completely eliminate the need for this copy operation and instead
***************
*** 389,393 ****
      \subsection{Image Transformations}
  
!     Image transformations are a natural part of OpenGL and are efficiently
      done on all available hardware and with all available OpenGL
      implementations. \Libname{} simply transforms the vertex coordinates
--- 389,393 ----
      \subsection{Image Transformations}
  
!     Image transformation is a natural part of OpenGL and is efficiently
      done on all available hardware and with all available OpenGL
      implementations. \Libname{} simply transforms the vertex coordinates
***************
*** 517,522 ****
        of the rendering model. It is relatively fast on current hardware and 
        it produces adequate results in real-time rendering. The trend among 
!       graphics hardware manufacturers seems to be to have well supported
!       multi-sampling in new products. 
       
        Full-scene anti-aliasing using hardware assist is typically
--- 517,522 ----
        of the rendering model. It is relatively fast on current hardware and 
        it produces adequate results in real-time rendering. The trend among 
!       graphics hardware manufacturers seems to be to favor multi-sampling
!       over other anti-aliasing techniques in new products.
       
        Full-scene anti-aliasing using hardware assist is typically
***************
*** 524,529 ****
        very fast model that works for all primitives, interrelationships,
        and rendering models. It is also well supported in current hardware,
!       since a couple of graphic card generations back. It requires some 
!       extra memory, but typically less than for software super-sampling or
        accumulation buffering. It yields decent-quality results but some 
        people may not find them acceptable for small text. This does not 
--- 524,529 ----
        very fast model that works for all primitives, interrelationships,
        and rendering models. It is also well supported in current hardware,
!       since a couple of graphics card generations back. Some extra memory is
!       required, but typically less than for software super-sampling or
        accumulation buffering. It yields decent-quality results but some 
        people may not find them acceptable for small text. This does not 
***************
*** 579,588 ****
      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
!     \ref{section: Results}.
  
      Built in text handling is planned for future versions of the library and
      tests have proven that this will increase glyph rendering speed to
!     around 200000 glyphs/sec.
  
      \subsection{Clipping}
--- 579,588 ----
      glyph-sets with off-screen surfaces containing alpha masks, should be 
      used. With external glyph management, \libname{} renders text at 
!     approximately 50000 glyphs per second on the test setup described in
!     section \ref{section: Results}.
  
      Built in text handling is planned for future versions of the library and
      tests have proven that this will increase glyph rendering speed to
!     around 200000 glyphs per second.
  
      \subsection{Clipping}
***************
*** 593,597 ****
      but the clip-mask cannot be created by the application, it must always
      be implicitly generated from a set of rectangles, triangles and trapezoids.
!     With \libname{},  clipping only restricts writing to a surface.
      \Libname{}'s clipping interface cannot restrict reading of a surface.
   
--- 593,597 ----
      but the clip-mask cannot be created by the application, it must always
      be implicitly generated from a set of rectangles, triangles and trapezoids.
!     With \libname{}, clipping only restricts writing to a surface.
      \Libname{}'s clipping interface cannot restrict reading of a surface.
   
***************
*** 612,616 ****
      operation. The original source surface remains unmodified.
  
!     In \libname{} convolution filtering is implemented using fragment
      programs and is only available on hardware with fragment program support.
      The alternative would be to use OpenGL's imaging extension, which would
--- 612,616 ----
      operation. The original source surface remains unmodified.
  
!     In \libname{}, convolution filtering is implemented using fragment
      programs and is only available on hardware with fragment program support.
      The alternative would be to use OpenGL's imaging extension, which would
***************
*** 1092,1098 ****
  
    Table~\ref{rendermark5} shows that nvidia's driver performs well 
!   compared to \libname{}, except for the case where transformations
!   are used. In this case \libname{} is much faster than nvidia's driver,
!   which most likely falls back on software rendering.
  
    \section{Conclusion}
--- 1092,1098 ----
  
    Table~\ref{rendermark5} shows that nvidia's driver performs well 
!   compared to \libname{} in the cases where no transformations are used.
!   In cases where transformations are used, \libname{} is much faster than
!   nvidia's driver, which most likely falls back on software rendering.
  
    \section{Conclusion}
***************
*** 1100,1112 ****
    During the development of \libname{} we have found that with the OpenGL 
    API and the extensions available today, along with the wide range of
!   hardware supporting them, it is not only possible to create an
!   Render-like interface on top of OpenGL, it is actually very efficient.
!   This is an important conclusion as the desire for having an X server
!   running on top of OpenGL grows rapidly.
  
    The benchmark results points out \libname's remarkable rendering 
!   performance compared to the widely used software implementations. Even 
!   Imlib2's highly optimized rendering engine is no where near \libname's
!   performance.
  
    Although performance is of high importance, the greatest advantage 
--- 1100,1110 ----
    During the development of \libname{} we have found that with the OpenGL 
    API and the extensions available today, along with the wide range of
!   hardware supporting them, a Render-like interface on top of OpenGL
!   is viable and very efficient. This is an important conclusion as the
!   desire for having an X server running on top of OpenGL grows rapidly.
  
    The benchmark results points out \libname's remarkable rendering 
!   performance. Even Imlib2's highly optimized rendering engine is no where
!   near \libname's performance.
  
    Although performance is of high importance, the greatest advantage 
***************
*** 1118,1122 ****
    Today, the existing implementation of the library supports all 
    the basic functionality, which where initially set up for the project.
!   But there are still some important features missing, and the software is
    in an early stage of development with a lot of work remaining to make it
    stable and optimized with regards to performance and accuracy.
--- 1116,1120 ----
    Today, the existing implementation of the library supports all 
    the basic functionality, which where initially set up for the project.
!   However, there are still some important features missing, and the software is
    in an early stage of development with a lot of work remaining to make it
    stable and optimized with regards to performance and accuracy.
***************
*** 1136,1141 ****
    \end{itemize}
  
!   Of course the future will demand new features from the library, since it is
!   an area of continuous development.
  
    \section{Visions}
--- 1134,1139 ----
    \end{itemize}
  
!   The future will most certainly demand new features from the library, since
!   it is an area of continuous development.
  
    \section{Visions}





More information about the cairo-commit mailing list