From e35b9058ce5b0cacfa962c05e038292ed1136fc9 Mon Sep 17 00:00:00 2001 From: Brian Paul Date: Fri, 19 May 2006 03:42:16 +0000 Subject: updated docs for off-screen rendering --- docs/osmesa.html | 67 +++++++++++++++++++++++++++++++++----------------------- 1 file changed, 39 insertions(+), 28 deletions(-) (limited to 'docs/osmesa.html') diff --git a/docs/osmesa.html b/docs/osmesa.html index 6feb8df52a..629d054f41 100644 --- a/docs/osmesa.html +++ b/docs/osmesa.html @@ -10,46 +10,57 @@

-Mesa 1.2.4 introduced off-screen rendering, a facility for generating -3-D imagery without having to open a window on your display. Mesa's -simple off-screen rendering interface is completely operating system -and window system independent so programs which use off-screen -rendering should be very portable. This feature effectively -enables you to use Mesa as an off-line, batch-oriented renderer. +Mesa's off-screen rendering interface is used for rendering into +user-allocated blocks of memory. +That is, the GL_FRONT colorbuffer is actually a buffer in main memory, +rather than a window on your display. +There are no window system or operating system dependencies. +One potential application is to use Mesa as an off-line, batch-style renderer.

+

-The "OSMesa" API provides 3 functions for making off-screen +The OSMesa API provides three basic functions for making off-screen renderings: OSMesaCreateContext(), OSMesaMakeCurrent(), and OSMesaDestroyContext(). See the Mesa/include/GL/osmesa.h header for -more information. See the demos/osdemo.c file for an example program. -There is no facility for writing images to files. That's up to you. +more information about the API functions.

+

-If you want to generate large images (larger than 1280x1024) you'll -have to edit the src/config.h file to change MAX_WIDTH and MAX_HEIGHT -then recompile Mesa. Image size should only be limited by available -memory. +There are several examples of OSMesa in the progs/osdemo/ +directory.

Deep color channels

- For some applications 8-bit color channels don't have sufficient - accuracy (film and IBR, for example). If you're in this situation - you'll be happy to know that Mesa supports 16-bit and 32-bit color - channels through the OSMesa interface. When using 16-bit channels, - channels are GLushorts and RGBA pixels occupy 8 bytes. When using 32-bit - channels, channels are GLfloats and RGBA pixels occupy 16 bytes. +For some applications 8-bit color channels don't have sufficient +precision. +OSMesa supports 16-bit and 32-bit color channels through the OSMesa interface. +When using 16-bit channels, channels are GLushorts and RGBA pixels occupy +8 bytes. +When using 32-bit channels, channels are GLfloats and RGBA pixels occupy +16 bytes.

+

- To build Mesa/OSMesa with 16-bit color channels: +Before version 6.5.1, Mesa had to be recompiled to support exactly +one of 8, 16 or 32-bit channels. +With Mesa 6.5.1, Mesa can be compiled for either 8, 16 or 32-bit channels +and render into any of the smaller size channels. +For example, if Mesa's compiled for 32-bit channels, you can also render +16 and 8-bit channel images. +

+ +

+To build Mesa/OSMesa for 16 and 8-bit color channel support: 

       make realclean
       make linux-osmesa16
- For 32-bit channels: +

+To build Mesa/OSMesa for 32, 16 and 8-bit color channel support: 

       make realclean
       make linux-osmesa32
@@ -57,6 +68,13 @@ memory.
 
 

 You'll wind up with a library named libOSMesa16.so or libOSMesa32.so.
+Otherwise, most Mesa configurations build an 8-bit/channel libOSMesa.so library
+by default.
+

+
+

+If performance is important, compile Mesa for the channel size you're
+most interested in.
 

 
 

@@ -66,12 +84,5 @@ the top-level Makefile.  Send a patch to the Mesa developers too, if you're
 inclined.
 

 
-

-BE WARNED: 16 and 32-bit channel support has not been exhaustively
-tested and there may be some bugs.  However, a number of people have
-been using this feature successfully so it can't be too broken.
-

-
-
 
 
-- 
cgit v1.2.3