- remove unused libraries

git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8850 75d07b2b-3a1a-0410-a2c5-0572b91ccdca

engine/lib/jheora/LICENSE.jheora

@@ -1,23 +0,0 @@
-/* Jheora
- * Copyright (C) 2004 Fluendo S.L.
- *  
- * Written by: 2004 Wim Taymans <wim@fluendo.com>
- *   
- * Many thanks to 
- *   The Xiph.Org Foundation http://www.xiph.org/
- * Jheora was based on their Theora reference decoder.
- *   
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Library General Public License
- * as published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- * 
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU Library General Public License for more details.
- * 
- * You should have received a copy of the GNU Library General Public
- * License along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */

engine/lib/jogl/CHANGELOG.txt

@@ -1,101 +0,0 @@
-Changes between JOGL 1.1.0 and 1.1.1:
-
- - Fixed a bug in the checking of incoming buffers' sizes to
-   glTexImage1D, glTexImage2D, and glTexImage3D.
-
-Changes between JOGL 1.0.0 and 1.1.0:
-
- - The glext.h and associated header files JOGL uses have been updated
-   to OpenGL 2.1 with NVidia's GeForce 8 series extensions. The new
-   functions are available as methods in the GL interface.
-
- - The developer build bundles have been changed to zip archives, so
-   instead of having to download multiple jars, you can now just
-   download the zip archive for your particular platform. The new zip
-   archives are versioned with the build date.
-
- - The source distribution now contains the generated sources like
-   GL.java, GLU.java, etc. for more convenient use in IDEs.
-
- - The chosen GLCapabilities are now exposed from the GLDrawable via
-   GLDrawable.getChosenGLCapabilities(); this functionality works on
-   all platforms even in cases where the GLCapabilitiesChooser is not
-   supported, and attempts to provide correct answers so programs can
-   make decisions based on the results.
-
- - The native code for the "DRI hack" (to support the open-source DRI
-   drivers on Linux and other X11 platforms) has been removed; JOGL
-   now uses the GlueGen NativeLibrary class for this purpose.
-   Reliability improvements have been made to the implementation of
-   this class; it has been confirmed as working again with ATI's
-   proprietary drivers on Linux and should also work better with
-   NVidia's drivers.
-
- - The GlueGen runtime classes have been removed from jogl.jar. These
-   have been factored out into gluegen-rt.jar and are referenced by
-   both the JOGL and JOAL projects.
-
- - Thanks to John Burkey some optimizations have been made to the
-   buffer object-related validity checks in glVertexPointer, etc. as
-   well as a buffer size query that was being made in the glMapBuffer
-   implementation. This improves performance for applications
-   performing a lot of VBO- or vertex array-based rendering, in
-   particular with the multithreaded OpenGL implementation on Mac OS
-   X.
-
- - The JOGL applet launcher now supports deployment of applets which
-   use both OpenGL for 3D graphics via JOGL as well as OpenAL for
-   spatialized audio via JOAL. It now prompts the user on Windows
-   platforms to allow it to enable the -Dsun.java2d.noddraw=true
-   system property for best robustness. It has been updated for the
-   changes in the GlueGen runtime classes and native library
-   structure. Some bugs have been fixed, some of which were preventing
-   different JOGL-based applets from being deployed from the same
-   codebase. The documentation and on-line examples have been updated
-   as well.
-
- - The TextureIO implementation has been changed to no longer copy the
-   data associated with BufferedImage TextureData objects. Instead,
-   the necessary vertical flip is now implemented by flipping the
-   texture coordinates vertically.
-
- - An API for updating a sub-image of a Texture object from a
-   sub-portion of a TextureData object has been added.
-
- - A GLContext.copy() operation has been added based on community
-   feedback.
-
- - Three helper classes have been added to the com.sun.opengl.util.j2d
-   package to improve interoperability between JOGL and Java 2D:
-   TextureRenderer, Overlay and TextRenderer. The TextureRenderer
-   supports drawing into an OpenGL texture using Java 2D. The Overlay
-   class provides a convenient Java 2D-based overlay on top of an
-   arbitrary GLDrawable. The TextRenderer class supports drawing of
-   Java 2D text into an OpenGL context. Thanks to Chris Campbell of
-   the Java 2D team for collaboration and to the JOGL community for
-   extensive feedback and testing assistance.
-
- - Various bug fixes and robustness improvements were made to the
-   GlueGen runtime, JOGL and GLU implementations.
-
- - Fixes to the DDSImage class were contributed by the community: a
-   bug fix to mipmap handling and support for cubemap textures. Thanks
-   to java.net user bandures.
-
- - TextureIO.setTexRectEnabled() and isTexRectEnabled() were added
-   based on feedback from Chris Campbell, in order to simplify the
-   writing of pixel shaders which have different samplers for
-   GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE_ARB targets.
-
- - Thanks to Erik Tollerud, the links to the OpenGL documentation in
-   the JOGL javadoc were revised to point to the new on-line man pages
-   in the OpenGL SDK.
-
- - Support for automatic mipmap generation via GL_GENERATE_MIPMAP was
-   added to the TextureIO, TextureRenderer and TextRenderer classes.
-
- - Windows/AMD64 binaries, including the JOGL Cg binding, are now
-   supplied.
-
- - Worked around breakage of JOGL with 5.0u10; see Sun bug IDs 6504460
-   and 6333613.

engine/lib/jogl/COPYRIGHT.txt

@@ -1,31 +0,0 @@
-
-Copyright 2007 Sun Microsystems, Inc., 4150 Network 
-Circle, Santa Clara, California 95054, U.S.A. All rights 
-reserved.
-
-U.S. Government Rights - Commercial software. Government 
-users are subject to the Sun Microsystems, Inc. 
-standard license agreement and applicable provisions of 
-the FAR and its supplements.
-
-Use is subject to license terms. 
-
-This distribution may include materials developed by third 
-parties.
-
-Sun, Sun Microsystems, the Sun logo and Java are trademarks 
-or registered trademarks of Sun Microsystems, Inc. in the 
-U.S. and other countries.
-
-OpenGL is a registered trademark of Silicon Graphics, Inc. 
-
-This product is covered and controlled by U.S. Export 
-Control laws and may be subject to the export or import 
-laws in other countries. Nuclear, missile, chemical 
-biological weapons or nuclear maritime end uses or end 
-users, whether direct or indirect, are strictly prohibited. 
-Export or reexport to countries subject to U.S. embargo or 
-to entities identified on U.S. export exclusion lists, 
-including, but not limited to, the denied persons and 
-specially designated nationals lists is strictly prohibited. 
-

engine/lib/jogl/LICENSE-JOGL-1.1.1.txt

@@ -1,152 +0,0 @@
-JOGL is released under the BSD license. The full license terms follow:
-
-   Copyright (c) 2003-2007 Sun Microsystems, Inc. All Rights Reserved.
- 
-   Redistribution and use in source and binary forms, with or without
-   modification, are permitted provided that the following conditions are
-   met:
-   
-   - Redistribution of source code must retain the above copyright
-     notice, this list of conditions and the following disclaimer.
-   
-   - Redistribution in binary form must reproduce the above copyright
-     notice, this list of conditions and the following disclaimer in the
-     documentation and/or other materials provided with the distribution.
-   
-   Neither the name of Sun Microsystems, Inc. or the names of
-   contributors may be used to endorse or promote products derived from
-   this software without specific prior written permission.
-   
-   This software is provided "AS IS," without a warranty of any kind. ALL
-   EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
-   INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
-   PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN
-   MICROSYSTEMS, INC. ("SUN") AND ITS LICENSORS SHALL NOT BE LIABLE FOR
-   ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR
-   DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR
-   ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR
-   DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE
-   DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY,
-   ARISING OUT OF THE USE OF OR INABILITY TO USE THIS SOFTWARE, EVEN IF
-   SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-   
-   You acknowledge that this software is not designed or intended for use
-   in the design, construction, operation or maintenance of any nuclear
-   facility.
-
-The JOGL source tree contains code ported from the OpenGL sample
-implementation by Silicon Graphics, Inc. This code is licensed under
-the SGI Free Software License B (Sun is redistributing the modified code 
-under a slightly modified, alternative license, which is described two
-paragraphs below after "NOTE:"):
-
-   License Applicability. Except to the extent portions of this file are
-   made subject to an alternative license as permitted in the SGI Free
-   Software License B, Version 1.1 (the "License"), the contents of this
-   file are subject only to the provisions of the License. You may not use
-   this file except in compliance with the License. You may obtain a copy
-   of the License at Silicon Graphics, Inc., attn: Legal Services, 1600
-   Amphitheatre Parkway, Mountain View, CA 94043-1351, or at:
-   
-   http://oss.sgi.com/projects/FreeB
-   
-   Note that, as provided in the License, the Software is distributed on an
-   "AS IS" basis, with ALL EXPRESS AND IMPLIED WARRANTIES AND CONDITIONS
-   DISCLAIMED, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES AND
-   CONDITIONS OF MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A
-   PARTICULAR PURPOSE, AND NON-INFRINGEMENT.
-
-   NOTE:  The Original Code (as defined below) has been licensed to Sun 
-   Microsystems, Inc. ("Sun") under the SGI Free Software License B 
-   (Version 1.1), shown above ("SGI License").   Pursuant to Section  
-   3.2(3) of the SGI License, Sun is distributing the Covered Code to 
-   you under an alternative license ("Alternative License").  This 
-   Alternative License includes all of the provisions of the SGI License 
-   except that Section 2.2 and 11 are omitted.  Any differences between 
-   the Alternative License and the SGI License are offered solely by Sun 
-   and not by SGI.
-   
-   Original Code. The Original Code is: OpenGL Sample Implementation,
-   Version 1.2.1, released January 26, 2000, developed by Silicon Graphics,
-   Inc. The Original Code is Copyright (c) 1991-2000 Silicon Graphics, Inc.
-   Copyright in any portions created by third parties is as indicated
-   elsewhere herein. All Rights Reserved.
-   
-   Additional Notice Provisions: The application programming interfaces
-   established by SGI in conjunction with the Original Code are The
-   OpenGL(R) Graphics System: A Specification (Version 1.2.1), released
-   April 1, 1999; The OpenGL(R) Graphics System Utility Library (Version
-   1.3), released November 4, 1998; and OpenGL(R) Graphics with the X
-   Window System(R) (Version 1.3), released October 19, 1998. This software
-   was created using the OpenGL(R) version 1.2.1 Sample Implementation
-   published by SGI, but has not been independently verified as being
-   compliant with the OpenGL(R) version 1.2.1 Specification.
-
-
-The JOGL source tree contains code from the LWJGL project which is
-similarly covered by the BSD license:
-
-   Copyright (c) 2002-2004 LWJGL Project
-   All rights reserved.
-   
-   Redistribution and use in source and binary forms, with or without
-   modification, are permitted provided that the following conditions are 
-   met:
-   
-   * Redistributions of source code must retain the above copyright 
-     notice, this list of conditions and the following disclaimer.
-  
-   * Redistributions in binary form must reproduce the above copyright
-     notice, this list of conditions and the following disclaimer in the
-     documentation and/or other materials provided with the distribution.
-  
-   * Neither the name of 'LWJGL' nor the names of 
-     its contributors may be used to endorse or promote products derived 
-     from this software without specific prior written permission.
-   
-   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
-   TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
-   PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR 
-   CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
-   EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
-   PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR 
-   PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
-   LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
-   NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
-   SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-The JOGL source tree also contains a Java port of Brian Paul's Tile
-Rendering library, used with permission of the author under the BSD
-license instead of the original LGPL:
-
-   Copyright (c) 1997-2005 Brian Paul. All Rights Reserved.
- 
-   Redistribution and use in source and binary forms, with or without
-   modification, are permitted provided that the following conditions are
-   met:
-   
-   - Redistribution of source code must retain the above copyright
-     notice, this list of conditions and the following disclaimer.
-   
-   - Redistribution in binary form must reproduce the above copyright
-     notice, this list of conditions and the following disclaimer in the
-     documentation and/or other materials provided with the distribution.
-   
-   Neither the name of Brian Paul or the names of contributors may be
-   used to endorse or promote products derived from this software
-   without specific prior written permission.
-   
-   This software is provided "AS IS," without a warranty of any
-   kind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND
-   WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,
-   FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY
-   EXCLUDED. THE COPYRIGHT HOLDERS AND CONTRIBUTORS SHALL NOT BE
-   LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING,
-   MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES. IN NO
-   EVENT WILL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY
-   LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL,
-   CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND
-   REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR
-   INABILITY TO USE THIS SOFTWARE, EVEN IF THE COPYRIGHT HOLDERS OR
-   CONTRIBUTORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

engine/lib/jogl/README.txt

@@ -1,45 +0,0 @@
-
-Java (TM) Binding for the OpenGL (r) API, version 1.1.1
--------------------------------------------------------
-
-This software is licensed by Sun Microsystems, as specified
-in the LICENSE-JOGL-1.1.1.txt file.  You must use this software 
-in accordance with the terms under which the code is licensed.
-
-
-
-Instructions for unzipping Java Binding for the OpenGL API, version 1.1.1
---------------------------------------------------------------------
-
-After downloading and unzipping the zip file containing the 
-JOGL release for your target platform, you will see the 
-following files in the top directory:
-  
-  COPYRIGHT.txt
-  LICENSE-JOGL-1.1.1.txt
-  Userguide.html
-  README.txt                  README file (you are reading it now)
-
-and the following subdirectory:
-
-  lib                         contains JOGL implementation
-
-All of the JOGL implementation files (jar files and native 
-libraries) are in the lib subdirectory.  For instructions on 
-how to use these implementation files to build or run a JOGL 
-program see the enclosed JOGL user guide (Userguide.html).
-
-
-
-Project source code and getting assistance
-------------------------------------------
-
-JOGL source code and project information can be found at:
-
-  https://jogl.dev.java.net/
-
-
-Numerous answers to common questions can be found on the JOGL
-forum:
-
-  http://www.javagaming.org/forums/index.php?board=25.0

engine/lib/jogl/Userguide.html

@@ -1,999 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
-<HTML>
-<HEAD>
-<TITLE>Jogl - User's Guide</TITLE>
-</HEAD>
-<BODY>
-
-<H1>Jogl - User's Guide</H1>
-
-<P>
-
-<UL>
-
-  <LI> Overview
-  <LI> Developing with JOGL
-  <UL>
-    <LI> Building the source tree
-    <LI> Local installation for development
-    <LI> Java Web Start integration
-    <LI> Applet support
-  </UL>
-  <LI> GLDrawable and GLContext
-  <LI> Creating a GLAutoDrawable
-  <LI> Writing a GLEventListener
-  <LI> Using the Composable Pipeline
-  <LI> Heavyweight and Lightweight Issues
-  <LI> Multithreading Issues
-  <LI> Pbuffers
-  <LI> GLU
-  <LI> More Resources
-  <LI> Platform notes
-  <UL>
-    <LI> All Platforms
-    <LI> Windows
-    <LI> Linux
-    <LI> Solaris, Linux (X11 platforms)
-    <LI> Macintosh OS X
-  </UL>
-  <LI> Version History
-
-</UL>
-
-<H2> Overview </H2>
-
-<P>
-
-Jogl is a Java programming language binding for the OpenGL 3D graphics
-API. It supports integration with the Java platform's AWT and Swing
-widget sets while providing a minimal and easy-to-use API that handles
-many of the issues associated with building multithreaded OpenGL
-applications. Jogl provides access to the latest OpenGL routines
-(OpenGL 2.0 with vendor extensions) as well as platform-independent
-access to hardware-accelerated offscreen rendering ("pbuffers"). Jogl
-also provides some of the most popular features introduced by other
-Java bindings for OpenGL like GL4Java, LWJGL and Magician, including a
-composable pipeline model which can provide faster debugging for
-Java-based OpenGL applications than the analogous C program.
-
-</P>
-<P>
-
-Jogl was designed for the most recent versions of the Java platform
-and for this reason supports only J2SE 1.4 and later. It also only
-supports truecolor (15 bits per pixel and higher) rendering; it does
-not support color-indexed modes. It was designed with New I/O (NIO) in
-mind and uses NIO internally in the implementation. The Jogl binding
-is itself written almost completely in the Java programming language.
-There are roughly 150 lines of handwritten C code in the entire Jogl
-source base (100 of which work around bugs in older OpenGL drivers on
-Windows); the rest of the native code is autogenerated during the
-build process by a new tool called <a
-href="http://gluegen.dev.java.net/">GlueGen</a>, the source code of
-which is available from its own java.net project.
-
-</P>
-<P>
-
-The JOGL source tree in its current form is an experimental workspace
-for the <a href="http://jcp.org/en/jsr/detail?id=231">JSR-231</a> Java
-Bindings for OpenGL JSR. JOGL is not the official reference
-implementation, but an evolving workspace. Snapshots of the JOGL
-source tree are run through the JSR-231 Technology Compatibility Kit
-(TCK) to become the official reference implementation (RI). As of this
-writing the JSR has not been finalized, so the first official RI of
-the JSR has not yet been produced.
-
-</P>
-
-<H2> Developing with JOGL </H2>
-
-<H3> Building the source tree </H3>
-
-<P>
-
-Most developers using JOGL will download the most current <a
-href="https://jogl.dev.java.net/servlets/ProjectDocumentList">release
-build</a>. Separate instructions are available on how to <a
-href="https://jogl.dev.java.net/unbranded-source/browse/*checkout*/jogl/doc/HowToBuild.html?rev=HEAD&amp;content-type=text/html">build
-the source tree</a>.
-
-</P>
-
-<H3> Local installation for development </H3>
-
-<P>
-
-The JOGL distribution for developers comes in the form of a zip
-archive which contains the Java classes to call OpenGL from Java, as
-well as the associated JNI native libraries. JOGL depends on some
-run-time support classes and native code provided by the GlueGen
-project; these classes and native code are also provided in the zip
-bundles.
-
-</P>
-<P>
-
-If you are developing a new application which uses JOGL, download the
-zip archive for your platform (for example.,
-jogl-[version]-windows-i586.zip) and unzip it. Modify your CLASSPATH
-environment variable to include the full paths to jogl.jar and
-gluegen-rt.jar; for example,
-".;C:\Some\Other\Package\foo.jar;C:\Users\myhome\jogl-[version]-windows-i586\lib\jogl.jar;C:\Users\myhome\jogl-[version]-windows-i586\lib\gluegen-rt.jar".
-(If you did not previously set the CLASSPATH environment variable, you
-may want to make sure that ".", the current directory, is on your new
-CLASSPATH.) Modify your PATH environment variable (Windows),
-LD_LIBRARY_PATH environment variable (Solaris and Linux), or
-DYLD_LIBRARY_PATH environment variable (Mac OS X) to contain the full
-path to the "lib" directory; for example, on Windows, add
-"C:\Users\myhome\jogl-[version]-windows-i586\lib" to your PATH using
-the System control panel, Advanced tab, Environment Variables
-button. At this point your Java installation should be able to see the
-JOGL class files. Users of IDEs such as NetBeans and Eclipse should
-consult the IDE's documentation to see how to add jar files and native
-libraries to their current project.
-
-</P>
-<P>
-
-Dropping the JOGL jar and native library into the extension directory
-of the JRE is <b>strongly discouraged</b>. Doing so can cause
-conflicts with third-party applications launched via Java Web Start,
-and causes confusion later when upgrading the distribution.
-
-</P>
-<P>
-
-If you are on the Linux platform, please see the Linux-specific
-platform notes, below, with information on incompatibility between the
-JPackage Java RPMs and JOGL.
-
-</P>
-
-<H3> Java Web Start integration </H3>
-
-<P>
-
-The recommended distribution vehicle for applications using JOGL is
-Java Web Start. JOGL-based applications do not even need to be signed;
-all that is necessary is to reference the JOGL extension JNLP file.
-Because the JOGL jar files are signed, an unsigned application can
-reference the signed JOGL library and continue to run inside the
-sandbox.
-
-</P>
-<P>
-
-To reference JOGL within your application's JNLP file, simply place
-the following line in the <code>&lt;resources&gt;</code> section:
-
-<PRE>
-  &lt;extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp" /&gt;
-</PRE>
-
-This JNLP file points to the current JSR-231 unofficial development
-build. For reference, the extension JNLP file for the most recent
-official JSR-231 build is available at
-
-<PRE>
-  &lt;extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.0/webstart/jogl.jnlp" /&gt;
-</PRE>
-
-Note that before JOGL transitioned to the JSR-231 APIs, there were
-releases of the library in the <code>net.java.games.jogl</code>
-namespace under version numbers "1.0", "1.1", and "1.1.1". All of
-these releases have been superseded by JSR-231. Please update your
-applications.
-
-</P>
-
-<H3> Applet support </H3>
-
-<P>
-
-Lilian Chamontin, in conjunction with several other members of the
-JOGL community, has contributed a JOGL applet installer. This
-installer uses some clever tricks to allow deployment of unsigned
-applets which use JOGL into existing web browsers and JREs as far back
-as 1.4.2, which is the earliest version of Java supported by JOGL.
-
-</P>
-<P>
-
-The JOGLAppletInstaller is distributed inside jogl.jar as a utility
-class in com.sun.opengl.util. It requires that the developer host a
-local, signed copy of jogl.jar and all of the jogl-natives jars; the
-certificates must be the same on all of these jars. Note that in the
-release builds of JOGL all of these jars are signed by Sun
-Microsystems, so the developer can deploy applets without needing any
-certificates.
-
-</P>
-<P>
-
-The JOGLAppletInstaller javadoc describes the basic steps for
-deployment of an applet utilizing JOGL. Please refer to this
-documentation for more information. A live example of deploying an
-unsigned JOGL applet will be added to this documentation shortly once
-the first signed build of the JOGLAppletInstaller has been shipped.
-
-</P>
-
-<H2> GLDrawable and GLContext </H2>
-
-<P>
-
-The JSR-231 APIs specify interfaces two low-level OpenGL abstractions:
-drawables and contexts. An OpenGL drawable is effectively a surface
-upon which OpenGL rendering will be performed. In order to perform
-rendering, an OpenGL rendering context is needed. Contexts and
-drawables typically go hand-in-hand. More than one context may be
-created for a particular drawable. In the JSR-231 abstractions, a
-context is always associated with exactly one drawable.
-
-</P>
-<P>
-
-Most end users will not need to use these abstractions directly.
-However, when sharing textures, display lists and other OpenGL objects
-between widgets, the concrete identifier for the "namespace" for these
-objects is the GLContext.
-
-</P>
-
-<H2> Creating a GLAutoDrawable </H2>
-
-<P>
-
-Jogl provides two basic widgets into which OpenGL rendering can be
-performed. The GLCanvas is a heavyweight AWT widget which supports
-hardware acceleration and which is intended to be the primary widget
-used by applications. The GLJPanel is a fully Swing-compatible
-lightweight widget which supports hardware acceleration but which is
-not as fast as the GLCanvas because it typically reads back the frame
-buffer in order to draw it using Java2D. The GLJPanel is intended to
-provide 100% correct Swing integration in the circumstances where a
-GLCanvas can not be used. See <a href =
-"http://java.sun.com/products/jfc/tsc/articles/mixing/">this
-article</a> on <a href = "http://java.sun.com/products/jfc/tsc/">The
-Swing Connection</a> for more information about mixing lightweight and
-heavyweight widgets. See also the section on "Heavyweight and
-Lightweight Issues" below. Recent work in the Mustang release of the
-JDK has sped up the GLJPanel significantly when the Java2D OpenGL
-pipeline is enabled; see <a
-href="http://www.javagaming.org/forums/index.php?topic=10813.0">this
-forum discussion</a> for more details.
-
-</P>
-<P>
-
-Both the GLCanvas and GLJPanel implement a common interface called
-GLAutoDrawable so applications can switch between them with minimal
-code changes. The GLAutoDrawable interface provides
-
-<UL>
-
-  <LI> access to the GL object for calling OpenGL routines
-
-  <LI> a callback mechanism (GLEventListener) for performing OpenGL
-  rendering
-
-  <LI> a <CODE>display()</CODE> method for forcing OpenGL rendering to
-  be performed synchronously
-
-  <LI> AWT- and Swing-independent abstractions for getting and setting
-  the size of the widget and adding and removing event listeners
-
-</UL>
-
-</P>
-<P>
-
-When creating GLCanvas and GLJPanel instances, the user may request a
-certain set of OpenGL parameters in the form of a GLCapabilities
-object, customize the format selection algorithm by specifying a
-GLCapabilitiesChooser, share textures and display lists with other
-GLDrawables, and specify the display device on which the
-GLAutoDrawable will be created (GLCanvas only).
-
-</P>
-<P>
-
-A GLCapabilities object specifies the OpenGL parameters for a
-newly-created widget, such as the color, alpha,, z-buffer and
-accumulation buffer bit depths and whether the widget is
-double-buffered. The default capabilities are loosely specified but
-provide for truecolor RGB, a reasonably large depth buffer,
-double-buffered, with no alpha, stencil, or accumulation buffers. 
-
-</P>
-<P>
-
-An application can override the default pixel format selection
-algorithm by providing a GLCapabilitiesChooser to the GLCanvas or
-GLJPanel constructor. (Not all platforms support the
-GLCapabilitiesChooser mechanism, however; it may be ignored, in
-particular on Mac OS X where pixel format selection is very different
-than on other platforms.) The chooseCapabilities method will be called
-with all of the available pixel formats as an array of GLCapabilities
-objects, as well as the index indicating the window system's
-recommended choice; it should return an integer index into this
-array. The DefaultGLCapabilitiesChooser uses the window system's
-recommendation when it is available, and otherwise attempts to use a
-platform-independent selection algorithm.
-
-</P>
-<P>
-
-The GLJPanel can be made non-opaque according to Swing's rendering
-model, so it can act as an overlay to other Swing or Java2D drawing.
-In order to enable this, set up your GLCapabilities object with a
-non-zero alpha depth (a common value is 8 bits) and call
-setOpaque(false) on the GLJPanel once it has been created. Java2D
-rendering underneath it will then show through areas where OpenGL has
-produced an alpha value less than 1.0. See the JGears and JRefract
-demos for examples of how to use this functionality.
-
-</P>
-
-<H2> Writing a GLEventListener </H2>
-
-<P>
-
-Applications implement the GLEventListener interface to perform OpenGL
-drawing via callbacks. When the methods of the GLEventListener are
-called, the underlying OpenGL context associated with the drawable is
-already current. The listener fetches the GL object out of the
-GLAutoDrawable and begins to perform rendering.
-
-</P>
-<P>
-
-The <CODE>init()</CODE> method is called when a new OpenGL context is
-created for the given GLAutoDrawable. Any display lists or textures
-used during the application's normal rendering loop can be safely
-initialized in <CODE>init()</CODE>. It is important to note that
-because the underlying AWT window may be destroyed and recreated while
-using the same GLCanvas and GLEventListener, the GLEventListener's
-<CODE>init()</CODE> method may be called more than once during the
-lifetime of the application. The init() method should therefore be
-kept as short as possible and only contain the OpenGL initialization
-required for the <CODE>display()</CODE> method to run properly. It is
-the responsibility of the application to keep track of how its various
-OpenGL contexts share display lists, textures and other OpenGL objects
-so they can be either be reinitialized or so that reinitialization can
-be skipped when the <CODE>init()</CODE> callback is called.
-
-</P>
-<P>
-
-Note also that the GLEventListener should be added to the
-GLAutoDrawable before the GLAutoDrawable is shown or rendered to for
-the first time. If this is not done, it is possible that the init()
-method will not be called on the GLEventListener. JOGL does not
-maintain internal state to keep track of whether init() has been
-called on a particular GLEventListener since the last time an OpenGL
-context was created for that GLAutoDrawable.
-
-</P>
-<P>
-
-The <CODE>display()</CODE> method is called to perform per-frame
-rendering. The <CODE>reshape()</CODE> method is called when the
-drawable has been resized; the default implementation automatically
-resizes the OpenGL viewport so often it is not necessary to do any
-work in this method.  The <CODE>displayChanged()</CODE> method is
-designed to allow applications to support on-the-fly screen mode
-switching, but support for this is not yet implemented so the body of
-this method should remain empty.
-
-</P>
-<P>
-
-It is strongly recommended that applications always refetch the GL
-object out of the GLAutoDrawable upon each call to the
-<CODE>init()</CODE>, <CODE>display()</CODE> and <CODE>reshape()</CODE>
-methods and pass the GL object down on the stack to any drawing
-routines, as opposed to storing the GL in a field and referencing it
-from there. The reason is that multithreading issues inherent to the
-AWT toolkit make it difficult to reason about which threads certain
-operations are occurring on, and if the GL object is stored in a field
-it is unfortunately too easy to accidentally make OpenGL calls from a
-thread that does not have a current context. This will usually cause
-the application to crash. For more information please see the section
-on multithreading.
-
-</P>
-
-<H2> Using the Composable Pipeline </H2>
-
-<P>
-
-Jogl supports the "composable pipeline" paradigm introduced by the
-Magician Java binding for OpenGL. The DebugGL pipeline calls
-<CODE>glGetError</CODE> after each OpenGL call, reporting any errors
-found. It can greatly speed up development time because of its
-fine-grained error checking as opposed to the manual error checking
-usually required in OpenGL programs written in C. The TraceGL prints
-logging information upon each OpenGL call and is helpful when an
-application crash makes it difficult to see where the error occurred.
-
-</P>
-<P>
-
-To use these pipelines, call <CODE>GLAutoDrawable.setGL</CODE> at the
-beginning of the <CODE>init</CODE> method in your GLEventListener. For
-example,
-
-<PRE>
-class MyListener implements GLEventListener {
-  public void init(GLDrawable drawable) {
-    drawable.setGL(new DebugGL(drawable.getGL()));
-    // ...
-  }
-
-  // ...
-}
-</PRE>
-
-</P>
-<P>
-
-Note that the GLAutoDrawable.setGL() method simply calls setGL() on
-the default OpenGL context created by the GLAutoDrawable, so
-sophisticated applications creating their own OpenGL contexts can use
-the composable pipeline with these contexts by setting the GL object
-in the context object itself. The composable pipeline needs to be
-re-installed every time GLContext.makeCurrent() returns
-CONTEXT_CURRENT_NEW.
-
-</P>
-
-<H2> Heavyweight and Lightweight Issues </H2>
-
-<P>
-
-As mentioned above, JOGL supplies both a heavyweight (GLCanvas) and a
-lightweight (GLJPanel) widget to be able to provide the fastest
-possible performance for applications which need it as well as 100%
-correct Swing integration, again for applications which need it. The
-GLCanvas usually provides higher performance than the GLJPanel, though
-in recent releases the GLJPanel's speed has been improved when the
-Java2D/OpenGL pipeline is active as described in <a
-href="http://www.javagaming.org/forums/index.php?topic=10813.0">this
-forum discussion</a>. Nonetheless, the GLCanvas can be used in almost
-every kind of application except those using JInternalFrames. Please
-see the Swing Connection article mentioned above for details on mixing
-heavyweight and lightweight widgets. A couple of common pitfalls are
-described here.
-
-</P>
-<P>
-
-When using JPopupMenus or Swing tool tips in conjunction with the
-GLCanvas, it is necessary to disable the use of lightweight widgets
-for the popups. See the methods
-<CODE>ToolTipManager.setLightWeightPopupEnabled</CODE>,
-<CODE>JPopupMenu.setLightWeightPopupEnabled</CODE>, and
-<CODE>JPopupMenu.setDefaultLightWeightPopupEnabled</CODE>.
-
-</P>
-<P>
-
-There are occasionally problems with certain LayoutManagers and
-component configurations where if a GLCanvas is placed in the middle
-of a set of lightweight widgets then it may only grow and never
-shrink. These issues are documented somewhat in <a href =
-"https://jogl.dev.java.net/issues/show_bug.cgi?id=135">JOGL Issue
-135</a> and most recently in the thread <a
-href="http://javagaming.org/forums/index.php?topic=8699.0">"Resize
-behaviour"</a> in the JOGL forum. The root cause is behavior of the
-Canvas, and in particular its ComponentPeer. The implementation of
-getPreferredSize() calls getMinimumSize() and getMinimumSize() turns
-around and calls Component.getSize(). This effectively means that the
-Canvas will report its preferred size as being as large as the
-component has ever been. For some layout managers this doesn't seem to
-matter, but for others like the BoxLayout it does. See the test case
-attached to Issue 135 for an example. Replacing the GLCanvas with an
-ordinary Canvas yields the same behavior.
-
-</P>
-<P>
-
-One suggestion was to override getPreferredSize() so that if a
-preferred size has not been set by the user, to default to (0,
-0). This works fine for some test cases but breaks all of the other
-JOGL demos because they use a different LayoutManager. There appear to
-be a lot of interactions between heavyweight vs. lightweight widgets
-and layout managers. One experiment which was done was to override
-setSize() in GLCanvas to update the preferred size.  This works down
-to the size specified by the user; if the window is resized any
-smeller the same problem appears. If reshape() (the base routine of
-setSize(), setBounds(), etc.) is changed to do the same thing, the
-demo breaks in the same way it originally did. Therefore this solution
-is fragile because it isn't clear which of these methods are used
-internally by the AWT and for what purposes.
-
-</P>
-<P>
-
-There are two possible solutions, both application-specific. The best
-and most portable appears to be to put the GLCanvas into a JPanel and
-set the JPanel's preferred size to (0, 0). The JPanel will cause this
-constraint to be enforced on its contained GLCanvas. The other
-workaround is to call <CODE>setPreferredSize(new Dimension(0,
-0))</CODE> on a newly-created GLCanvas; this method is new in 1.5.
-
-</P>
-<P>
-
-Another issue that occasionally arises on Windows is flickering during
-live resizing of a GLCanvas. This is caused by the AWT's repainting
-the background of the Canvas and can not be overridden on a per-Canvas
-basis, for example when subclassing Canvas into GLCanvas.  The
-repainting of the background of Canvases on Windows can be disabled by
-specifying the system property
-<CODE>-Dsun.awt.noerasebackground=true</CODE>. Whether to specify this
-flag depends on the application and should not be done universally,
-but instead on a case-by-case basis. Some more detail is in the thread
-<a href="http://javagaming.org/forums/index.php?topic=8770.0">"TIP:
-JOGL + Swing flicker"</a> in the JOGL forum.
-
-</P>
-
-<H2> Multithreading Issues </H2>
-
-<P>
-
-Jogl was designed to interoperate with the AWT, an inherently
-multithreaded GUI toolkit. OpenGL, in contrast, was originally
-designed in single-threaded C programming environments. For this
-reason Jogl provides a framework in which it is possible to write
-correct multithreaded OpenGL applications using the GLEventListener
-paradigm.
-
-</P>
-<P>
-
-If an application written using Jogl interacts in any way with the
-mouse or keyboard, the AWT is processing these events and the
-multithreaded aspects of the program must be considered.
-
-</P>
-<P>
-
-OpenGL applications usually behave in one of two ways: either they
-repaint only on demand, for example when mouse input comes in, or they
-repaint continually, regardless of whether user input is coming in. In
-the repaint-on-demand model, the application can merely call
-<CODE>GLAutoDrawable.display()</CODE> manually at the end of the mouse
-or keyboard listener to cause repainting to be done. Alternatively if
-the application knows the concrete type of the GLDrawable it can call
-repaint() to have the painting scheduled for a later time.
-
-</P>
-<P>
-
-In the continuous repaint model, the application typically has a main
-loop which is calling <CODE>GLAutoDrawable.display()</CODE>
-repeatedly, or is using the Animator class, which does this
-internally. In both of these cases the OpenGL rendering will be done
-on this thread rather than the internal AWT event queue thread which
-dispatches mouse and keyboard events.
-
-</P>
-<P>
-
-Both of these models (repaint-on-demand and repaint continually) still
-require the user to think about which thread keyboard and mouse events
-are coming in on, and which thread is performing the OpenGL rendering.
-OpenGL rendering <B>may not</B> occur directly inside the mouse or
-keyboard handlers, because the OpenGL context for the drawable is not
-current at this point (hence the warning about storing a GL object in
-a field, where it can be fetched and accidentally used by another
-thread). However, a mouse or keyboard listener may invoke
-<CODE>GLAutoDrawable.display()</CODE>.
-
-</P>
-<P>
-
-It is generally recommended that applications perform as little work
-as possible inside their mouse and keyboard handlers to keep the GUI
-responsive. However, since OpenGL commands can not be run from
-directly within the mouse or keyboard event listener, the best
-practice is to store off state when the listener is entered and
-retrieve this state during the next call to
-<CODE>GLEventListener.display()</CODE>.
-
-</P>
-<P>
-
-Furthermore, it is recommended that if there are long computational
-sequences in the GLEventListener's <CODE>display</CODE> method which
-reference variables which may be being simultaneously modified by the
-AWT thread (mouse and keyboard listeners) that copies of these
-variables be made upon entry to <CODE>display</CODE> and these copies
-be referenced throughout display() and the methods it calls. This will
-prevent the values from changing while the OpenGL rendering is being
-performed. Errors of this kind show up in many ways, including certain
-kinds of flickering of the rendered image as certain pieces of objects
-are rendered in one place and other pieces are rendered elsewhere in
-the scene. Restructuring the display() method as described has solved
-all instances of this kind of error that have been seen with Jogl to
-date.
-
-</P>
-<P>
-
-Prior to Jogl 1.1 b10, the Jogl library attempted to give applications
-strict control over which thread or threads performed OpenGL
-rendering. The <CODE>setRenderingThread()</CODE>,
-<CODE>setNoAutoRedrawMode()</CODE> and <CODE>display()</CODE> APIs
-were originally designed to allow the application to create its own
-animation thread and avoid OpenGL context switching on platforms that
-supported it. Unfortunately, serious stability issues caused by
-multithreading bugs in either vendors' OpenGL drivers or in the Java
-platform implementation have arisen on three of Jogl's major supported
-platforms: Windows, Linux and Mac OS X. In order to address these
-bugs, the threading model in Jogl 1.1 b10 and later has changed.
-
-</P>
-<P>
-
-All GLEventListener callbacks and other internal OpenGL context
-management are now performed on one thread. (In the current
-implementation, this thread is the AWT event queue thread, which is a
-thread internal to the implementation of the AWT and which is always
-present when the AWT is being used. Future versions of Jogl may change
-the thread on which the OpenGL work is performed.) When the
-<CODE>GLAutoDrawable.display()</CODE> method is called from user code,
-it now performs the work synchronously on the AWT event queue thread,
-even if the calling thread is a different thread. The
-<CODE>setRenderingThread()</CODE> optimization is now a no-op. The
-<CODE>setNoAutoRedrawMode()</CODE> API still works as previously
-advertised, though now that all work is done on the AWT event queue
-thread it no longer needs to be used in most cases. (It was previously
-useful for working around certain kinds of OpenGL driver bugs.)
-
-</P>
-<P>
-
-Most applications will not see a change in behavior from this change
-in the Jogl implementation. Applications which use thread-local
-storage or complex multithreading and synchronization may see a change
-in their control flow requiring code changes. While it is strongly
-recommended to change such applications to work under the new
-threading model, the old threading model can be used by specifying the
-system property <CODE>-Djogl.1thread=auto</CODE> or
-<CODE>-Djogl.1thread=false</CODE>. The "auto" setting is equivalent to
-the behavior in 1.1 b09 and before, where on ATI cards the
-single-threaded mode would be used. The "false' setting is equivalent
-to disabling the single-threaded mode. "true" is now the default
-setting.
-
-</P>
-<P>
-
-In the JSR-231 APIs the single-threaded behavior continues to be the
-default and the <CODE>setRenderingThread()</CODE> and
-<CODE>setNoAutoRedrawMode()</CODE> APIs have been removed. The public
-<CODE>Threading</CODE> class still provides some control over the
-internal use of threads in the library as well as external access to
-these mechanisms.
-
-</P>
-
-<H2> Pbuffers </H2>
-
-<P>
-
-Jogl exposes hardware-accelerated offscreen rendering (pbuffers) with
-a minimal and platform-agnostic API. Several recent demos have been
-successfully ported from C/C++ to Java using Jogl's pbuffer APIs.
-However, the pbuffer support in Jogl remains one of the more
-experimental aspects of the package and the APIs may need to change in
-the future.
-
-</P>
-<P>
-
-To create a pbuffer, call
-<CODE>GLDrawableFactory.createGLPbuffer()</CODE>. It is wise to call
-<CODE>GLDrawableFactory.canCreateGLPbuffer()</CODE> first to ensure
-the graphics card has pbuffer support first. The pbuffer is created
-immediately and is available for rendering as soon as
-<CODE>createGLPbuffer</CODE> returns.
-
-</P>
-<P>
-
-A pbuffer is used in conjunction with the GLEventListener mechanism by
-calling its display() method. Rendering, as always, occurs while the
-pbuffer's OpenGL context is current. There are render-to-texture
-options that can be specified in the GLCapabilities for the pbuffer
-which can make it easier to operate upon the resulting pixels. These
-APIs are however highly experimental and not yet implemented on all
-platforms.
-
-</P>
-
-<H2> GLU </H2>
-
-<P>
-
-Jogl contains support for the GLU (OpenGL Utility Library) version
-1.3. Jogl originally supported GLU by wrapping the C version of the
-APIs, but over time, and thanks to the contributions of several
-individuals, it now uses a pure-Java version of SGI's GLU library. The
-pure Java port is enabled by default, and addresses stability issues
-on certain Linux distributions as well as the lack of native GLU 1.3
-support on the Windows platform. In case of problems with the Java
-port, the C version of the GLU library may be used by specifying the
-system property <CODE>-Djogl.glu.nojava</CODE> on the command
-line. All of the same functionality is exposed with both the Java and
-C versions of the GLU library; currently NURBS support is the only
-missing feature on both sides. If you run into problems with the Java
-port of the GLU library please file a bug using the Issue Tracker on
-the Jogl home page.
-
-</P>
-<P>
-
-To use the GLU, simply instantiate a GLU object via <CODE>new
-GLU()</CODE> at the beginning of your program. The methods on the GLU
-object may be called at any point when an OpenGL context is current.
-Because the GLU implementation is not thread-safe, one GLU object
-should be created for each GLEventListener or other entity performing
-OpenGL rendering in a given thread.
-
-</P>
-
-<H2> More Resources </H2>
-
-<P>
-
-The <A HREF="http://javagaming.org/forums/index.php?board=25.0">JOGL
-forum</A> on <A HREF="http://javagaming.org/">javagaming.org</A> is
-the best place to ask questions about the library. Many users, as well
-as the Jogl developers, read this forum frequently, and the archived
-threads contain a lot of useful information (which still needs to be
-distilled into documentation).
-
-</P>
-<P>
-
-The <A HREF="http://jogl-demos.dev.java.net/">JOGL demos</A> provide
-several examples of usage of the library.
-
-</P>
-<P>
-
-Pepijn Van Eeckhoudt, Kevin Duling and Abdul Bezrati have done <A
-HREF="http://pepijn.fab4.be/software/nehe-java-ports/">JOGL ports of
-many of the the NeHe demos</A>. These are small examples of various
-pieces of OpenGL functionality. See also the <A
-HREF="http://nehe.gamedev.net/">NeHe web site</A>.
-
-</P>
-<P>
-
-Pepijn also did a <A
-HREF="http://www.glexcess.com/files/glexcess.jar">JOGL port</a> of
-Paolo Martella's <A HREF="http://www.glexcess.com/">GLExcess</A>
-demo. To see the news update about this port, go to the main GLExcess
-site and scroll down.
-
-</P>
-<P>
-
-Gregory Pierce's <A
-HREF="http://javagaming.org/forums/index.php?topic=1474.0">introduction
-to JOGL</a> is a useful tutorial on starting to use the JOGL library.
-
-</P>
-<P>
-
-For release information about the JOGL library, please see the <A
-HREF="http://javagaming.org/forums/index.php?topic=1596.0">JOGL Release
-Information</A> thread on the JOGL forum on javagaming.org.
-
-</P>
-<P>
-
-Please post on the JOGL forum if you have a resource you'd like to add
-to this documentation.
-
-</P>
-
-<H2> Platform Notes </H2>
-
-<H3> All Platforms </H3>
-
-<P>
-
-The following issues, among others, are outstanding on all platforms:
-
-</P>
-
-<UL>
-
-<LI> A few remaining stability issues, mostly on older graphics cards.
-
-<LI> JOGL now supports experimental integration and interoperability
-with the Java2D/OpenGL pipeline in Java SE 6 (Mustang), enabling a
-much faster GLJPanel as well as other features. Please see <a
-href="http://www.javagaming.org/forums/index.php?topic=10813.0">this
-forum discussion</a> for more details.
-
-</UL>
-
-<H3> Windows </H3>
-
-<P>
-
-For correct operation, it is necessary to specify the system property
-<CODE>-Dsun.java2d.noddraw=true</CODE> when running JOGL applications
-on Windows; this system property disables the use of DirectDraw by
-Java2D. There are driver-level incompatibilities between DirectDraw
-and OpenGL which manifest themselves as application crashes, poor
-performance, bad flickering, and other artifacts. This poor behavior
-may exhibit itself when OpenGL and DirectDraw are simply used in the
-same application, not even just in the same window, so disabling
-Java2D's DirectDraw pipeline and forcing it to use its GDI pipeline is
-the only way to work around these issues. Java Web Start applications
-may set this system property by adding the following line to the
-<CODE>&lt;resources&gt;</CODE> section of the JNLP file: <PRE>
-&lt;property name="sun.java2d.noddraw" value="true"/&gt; </PRE>
-
-</P>
-<P>
-
-There is a serious memory leak in ATI's OpenGL drivers which is
-exhibited on Windows XP on Mobility Radeon 9700 hardware. It's
-possible it will be present on other hardware as well though it was
-not reproducible at the time of this writing on desktop Radeon
-hardware or older ATI mobile chips. The bug is documented in <A
-HREF="https://jogl.dev.java.net/issues/show_bug.cgi?id=166">JOGL Issue
-166</A> and a bug has been filed with ATI. You can confirm the
-presence of the bug either with the test case in that bug report or by
-simply running the Gears demo; if the process size grows over time in
-the Task Manager, the memory leak is present on your hardware. For the
-time being, you can work around this memory leak by specifying the
-system property <CODE>-Djogl.GLContext.nofree</CODE> on the command
-line when launching your JOGL applications. There is no good
-general-purpose workaround for this bug which behaves well on all
-hardware.
-
-</P>
-
-<H3> Linux </H3>
-
-<P>
-
-The Sun JDK "compatibility" RPMs (java-1.5.0-sun-compat,
-java-1.6.0-sun-compat) provided by jpackage.org are incompatible with
-JOGL. These RPMs symlink an internal JDK directory to /usr/lib, which
-overrides how both NVidia and ATI currently provide their drivers to
-some Linux distributions, which is through an override in
-/etc/ld.so.conf (actually, in /etc/ld.so.conf.d). The implicit
-presence of /usr/lib on LD_LIBRARY_PATH forces the /usr/lib/libGL.so.1
-version of OpenGL to be used, which is typically Mesa and which will
-provide only software rendering.
-
-</P>
-<P>
-
-Unfortunately the JPackage maintainers have so far been unreceptive to
-changing their installation mechanism; see <a
-href="https://www.zarb.org/pipermail/jpackage-discuss/2007-January/010871.html">this
-mailing list posting</a>. Until this is resolved, we strongly
-discourage the use of the JPackage installers for the Sun JDK.
-Instead, download the JRE or JDK installers directly from Sun's
-website.
-
-</P>
-<P>
-
-Archived forum postings illustrating this problem are <a
-href="http://www.javagaming.org/forums/index.php?topic=15610.0">here</a>
-and <a
-href="http://www.javagaming.org/forums/index.php?topic=16105.0">here</a>.
-
-</P>
-
-<H3> Solaris, Linux (X11 platforms) </H3>
-
-<P>
-
-Support has been added to the JOGL library for allowing multiple
-threads to each have an OpenGL context current simultaneously, for
-example to implement multi-head CAVE-like environments. Normally a
-global AWT lock is held between calls to GLContext.makeCurrent() /
-release() for on-screen heavyweight contexts (for example, those
-associated with a Canvas or GLCanvas). We have found this to be
-necessary for stability purposes on all supported X11 platforms, even
-with relatively robust drivers such as those from NVidia.
-
-</P>
-<P>
-
-To enable multiple GLContexts to be made current simultaneously on X11
-platforms, specify the command line argument
-<CODE>-Djogl.GLContext.optimize</CODE> when starting the JVM. Note
-that this may incur robustness problems, in particular when resizing
-or moving windows. We have also found that ATI's proprietary drivers
-do not work at all with this flag, apparently because they cause GLX
-tokens to be sent to the X server for various GL calls even for direct
-contexts. For this reason if the GLX vendor is ATI then this flag
-currently has no effect.
-
-</P>
-
-<H3> Mac OS X </H3>
-
-<P>
-
-There are some problems with visual artifacts and stability problems
-with some of the Jogl demos on Mac OS X. It appears that at least some
-of these problems are due to bugs in Apple's OpenGL support. Bugs have
-been filed about these problems and it is hoped they will be addressed
-in the near future.
-
-</P>
-<P>
-
-The Mac OS X port of Jogl, in particular the GL interface and its
-implementation, can be used either with the provided GLCanvas widget
-or with the Cocoa NSOpenGLView. In order to use it with Cocoa the
-following steps should be taken:
-
-<UL>
-
-<LI> Create an "external" OpenGL context using the
-<CODE>GLDrawableFactory.createExternalGLContext()</CODE> API. The
-context object must be created while a real underlying OpenGL context
-is current.
-
-<LI> Fetch the GL instance out of the context using getGL() as usual.
-Only use the GL instance when the OpenGL context from the NSOpenGLView
-is current.
-
-</UL>
-
-<B>NOTE:</B> the Cocoa interoperability has not been retested
-recently, though similar interoperability has been tested on other
-platforms. Please report any problems found with using Jogl with an
-NSOpenGLView.
-
-</P>
-<P>
-
-The following issues remain with the Mac OS X port:
-
-<UL>
-
-<LI> Due to the mechanism by which the Cocoa graphics system selects
-OpenGL pixel formats, the GLCapabilitiesChooser mechanism can not be
-implemented on Mac OS X as on other platforms. Currently the
-underlying Cocoa pixel format selection is used on an
-NSOpenGLPixelFormat derived from the settings in the GLCapabilities,
-and the GLCapabilitiesChooser is ignored.
-
-</UL>
-
-</P>
-
-<H2> Version History </H2>
-
-<P>
-
-JOGL's version history can be found online in the <a
-href="http://javagaming.org/forums/index.php?topic=1596.0">"JOGL Release
-Information"</a> thread in the JOGL forum. Comments about the 1.1
-release train are in the thread <a
-href="http://javagaming.org/forums/index.php?topic=4217.0">"JOGL 1.1
-released"</a>.
-
-</BODY>
-</HTML>
-