Subversion Repositories Kolibri OS

=======

latest setup.exe from Cygwin the GL (Mesa) libraries and include are already

installed in /usr/X11R6.

============

    type 'make cygwin-sl'.

    Mesa-x.y/bin directories.

    type 'make cygwin-static'.

    When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory.

   After you've compiled Mesa and tried the demos I recommend the following

   procedure for "installing" Mesa.

	cp -a include/GL /usr/X11R6/include

	cp -a lib/* /usr/X11R6ocal/lib

	cp -a lib/cyg* /usr/X11R6/bin

   If you want to use Mesa or OpenGL in your Xt/Motif program you can build

   the widgets found in either the widgets-mesa or widgets-sgi directories.

   The former were written for Mesa and the later are the original SGI

   widgets.  Look in those directories for more information.

   For the Motif widgets you must have downloaded the lesstif package.

=================

   The file src/mesa/main/config.h has many parameters which you can adjust

   such as maximum number of lights, clipping planes, maximum texture size,

   etc.  In particular, you may want to change DEPTH_BITS from 16 to 32

   if a 16-bit depth buffer isn't precise enough for your application.

   If you compile shared libraries (Win32 DLLS) you may have to set an

   environment variable to specify where the Mesa libraries are located.

   Set the PATH variable to include /your-dir/Mesa-2.6/bin.

   Otherwise, when you try to run a demo it may fail with a message saying

   that one or more DLL couldn't be found.

   Two versions of the Xt/Motif OpenGL drawing area widgets are included:

      widgets-mesa/	Mesa-tuned widgets

   Togl is an OpenGL/Mesa widget for Tcl/Tk.

   See http://togl.sourceforge.net for more information.

   Mesa supports RGB(A) rendering into almost any X visual type and depth.

   for the given attribute list.  However, if this doesn't suit your needs

   you can force Mesa to use any X visual you want (any supported by your

   X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL

   environment variables.  When an RGB visual is requested, glXChooseVisual

   will first look if the MESA_RGB_VISUAL variable is defined.  If so, it

   will try to use the specified visual.  Similarly, when a color index

   visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL

   variable.

   Here are some examples:

	% setenv MESA_RGB_VISUAL "TrueColor 8"		// 8-bit TrueColor

	% setenv MESA_CI_VISUAL "PseudoColor 12"	// 12-bit PseudoColor

	% setenv MESA_RGB_VISUAL "PseudoColor 8"	// 8-bit PseudoColor

	$ export MESA_RGB_VISUAL="TrueColor 8"

	$ export MESA_CI_VISUAL="PseudoColor 12"

	$ export MESA_RGB_VISUAL="PseudoColor 8"

   Mesa can use either an X Pixmap or XImage as the backbuffer when in

   double buffer mode.  Using GLX, the default is to use an XImage.  The

   MESA_BACK_BUFFER environment variable can override this.  The valid

   values for MESA_BACK_BUFFER are:  Pixmap and XImage (only the first

   letter is checked, case doesn't matter).

   XImage is faster when Mesa has to do pixel-by-pixel rendering.  If you

   need depth buffering the XImage will almost surely be faster.  Exper-

   iment with the MESA_BACK_BUFFER variable to see which is faster for

   your application.

   When using Mesa directly or with GLX, it's up to the application writer

   to create a window with an appropriate colormap.  The aux, tk, and GLUT

   toolkits try to minimize colormap "flashing" by sharing colormaps when

   possible.  Specifically, if the visual and depth of the window matches

   that of the root window, the root window's colormap will be shared by

   the Mesa window.  Otherwise, a new, private colormap will be allocated.

   it needs, resulting in poor color quality.  This can happen when a

   large number of colorcells in the root colormap are already allocated.

   To prevent colormap sharing in aux, tk and GLUT, define the environment

   variable MESA_PRIVATE_CMAP.  The value isn't significant.

   To compensate for the nonlinear relationship between pixel values

   and displayed intensities, there is a gamma correction feature in

   Mesa.  Some systems, such as Silicon Graphics, support gamma

   correction in hardware (man gamma) so you won't need to use Mesa's

   gamma facility.  Other systems, however, may need gamma adjustment

   to produce images which look correct.  If in the past you thought

   Mesa's images were too dim, read on.

   variable.  Its value is of the form "Gr Gg Gb" or just "G" where

   Gr is the red gamma value, Gg is the green gamma value, Gb is the

   blue gamma value and G is one gamma value to use for all three

   channels.  Each value is a positive real number typically in the

   range 1.0 to 2.5.  The defaults are all 1.0, effectively disabling

   gamma correction.  Examples using csh:

	% setenv MESA_GAMMA "2.0"		// same gamma for R,G,B

   value for your display.  With correct gamma values, the color intensities

   displayed in the top row (drawn by dithering) should nearly match those

   in the bottom row (drawn as grays).

   on HP displays using the HP-ColorRecovery technology.

   a "linear" pixel value to a gamma-corrected pixel value.  There is a

   small performance penalty.  Gamma correction only works in RGB mode.

   Also be aware that pixel values read back from the frame buffer will

   not be "un-corrected" so glReadPixels may not return the same data

   drawn with glDrawPixels.

   http://www.inforamp.net/~poynton/notes/colour_and_gamma/GammaFAQ.html

   hardware and X server support.  To determine if your X server has

   overlay support you can test for the SERVER_OVERLAY_VISUALS property:

   will be used when clearing the color buffer.  This is only applicable

   to HP systems with the HPCR (Color Recovery) system.

==========

   There are three Mesa-specific GLX extensions at this time.

                                           Pixmap pixmap, Colormap cmap )

      Since Mesa supports RGB rendering into any X visual, not just True-

      Color or DirectColor, Mesa needs colormap information to convert RGB

      values into pixel values.  An X window carries this information but a

      pixmap does not.  This function associates a colormap to a GLX pixmap.

      See the xdemos/glxpixmap.c file for an example of how to use this

      extension.

      alpha) buffers with each X window it draws into.  These ancillary

      buffers are allocated for each X window the first time the X window

      is passed to glXMakeCurrent().  Mesa, however, can't detect when an

      X window has been destroyed in order to free the ancillary buffers.

      the client calls the glXCreateContext() or glXDestroyContext()

      functions.  This may not be sufficient in all situations though.

      deallocate the ancillary buffers by calling glxReleaseBuffersMESA()

      just before an X window is destroyed.  For example:

            glXReleaseBuffersMESA( dpy, window );

         #endif

         XDestroyWindow( dpy, window );

      like glXSwapBuffers() but only copies a sub-region of the window

      instead of the whole window.

   MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)

   MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)

   MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)

   MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)

   MESA_GAMMA - gamma correction coefficients (X only)

README.CYGWIN - lassauge April 2004 - based on README.X11