fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2026-05-05 11:48:06 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

updated docs for off-screen rendering

Browse source
This commit is contained in:
Brian Paul 2006-05-19 03:42:16 +00:00
parent d44248ca00
commit e35b9058ce
1 changed files with 39 additions and 28 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

67
docs/osmesa.html
View file

@ -10,46 +10,57 @@
<p>
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.
</p>
<p>
The "OSMesa" API provides 3 functions for making off-screen
The <B>OSMesa</B> 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.
</p>
<p>
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 <code>progs/osdemo/</code>
directory.
</p>
<H2>Deep color channels</H2>
<p>
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.
</p>
<p>
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.
</p>
<p>
To build Mesa/OSMesa for 16 and 8-bit color channel support:
<pre>
make realclean
make linux-osmesa16
</pre>
For 32-bit channels:
<p>
To build Mesa/OSMesa for 32, 16 and 8-bit color channel support:
<pre>
make realclean
make linux-osmesa32
@ -57,6 +68,13 @@ memory.
<p>
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.
</p>
<p>
If performance is important, compile Mesa for the channel size you're
most interested in.
</p>
<p>
@ -66,12 +84,5 @@ the top-level Makefile. Send a patch to the Mesa developers too, if you're
inclined.
</p>
<p>
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.
</p>
</BODY>
</HTML>