| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
on to trunk
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1958 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue turned up with NASA World Wind Java as well as with this
bug report.
The current situation is that GLJPanel.setAutoSwapBufferMode() and
GLJPanel.swapBuffers() have no effect due to how the Swing-compatible
GLJPanel works, and due to the fact that the backing OpenGL drawables
for the GLJPanel are always single-buffered.
Therefore there is no adverse effect to current applications to simply
making setAutoSwapBufferMode and swapBuffers no-ops, and returning
"true" from getAutoSwapBufferMode (although the latter is a change in
behavior, it reflects the current reality).
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1582 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
| |
Fixed obvious bug in algorithm as per submitter's comment.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1381 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
| |
builder based on suggestions from Josh Marinacci
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1234 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
| |
Fixed NPEs in setAutoSwapBufferMode and swapBuffers if Java 2D / JOGL
bridge is enabled. These methods are essentially no-ops on the
GLJPanel anyway because of how the copying to the Swing rendering area
(be it a BufferedImage or the Swing back buffer) is done.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1199 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
visible/showing
Investigation revealed that the symptom was similar to what happens
when one tries to create a new OpenGL context against an invalid HDC
on Windows. Discussion with Chris Campbell from the Java 2D team
indicated that in situations where the Java 2D OpenGL pipeline is
using Frame Buffer Objects for its rendering, it is possible that its
internal OpenGL context can be left current to the on-screen drawable,
and it only has a valid device context for the brief period of time
when its OpenGL context was being made current. This means that by the
time JOGL's code got a chance to run, it did not have a valid HDC and
therefore could not create its OpenGL context against it. The
workaround, suggested by Chris, is to forcibly make the Java 2D
context current against its internal "scratch" pbuffer, which can be
done with the internal invokeWithOGLSharedContextCurrent method. Added
this workaround and verified it fixes the problem with the user's test
case. This issue will be fixed in a forthcoming Java SE 6 update
release, hopefully 6u2.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1176 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added getChosenGLCapabilities() to the GLDrawable interface.
Implemented on Windows, Unix and Mac OS X platforms with various
techniques. Attempts to provide correct answers in all cases, even
when the GLCapabilitiesChooser mechanism is not supported. Required
addition of new platform-specific Java code in most cases to either
re-convert existing PIXELFORMATDESCRIPTORS / XVisualInfos, or to query
the pixel format or visual chosen for drawables like pbuffers for
which the chooser mechanism is not (yet) implemented. Tested on
Windows, Solaris/x86, and Mac OS X with on-screen, off-screen and
pbuffer drawables. (Full support for the Java2D/JOGL bridge is not yet
in place; the answer returned from the GLJPanel in this case is
currently the default GLCapabilities, and it is likely that "external"
GLDrawables will return null.)
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@989 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
| |
A workaround for the reported issue has been added to the GLJPanel
class and tested by forcing GLPbuffer.destroy() to throw a
GLException. The new fallback path appears to be working correctly.
Please reopen this issue or file a new one if this doesn't appear to
be the case.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@985 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
| |
CGLSurfaceData.createOGLContextOnSurface(Graphics, long). Testing
indicates that sharing of textures, etc. between pbuffers and the
context created on the Java2D back buffer is no longer functioning,
however.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@871 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
| |
sun.java2d.opengl.CGLSurfaceData added by gziemski to enable the
Java2D/JOGL bridge on Mac OS X. Currently untested.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@838 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
| |
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@818 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
| |
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@817 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
| |
support in Java2D/OpenGL pipeline's FBO code path
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@816 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
| |
On non-X11 platforms, removed workaround in Threading class which
treats both the EDT and the QFT as viable threads upon which to
execute OpenGL work. Deadlock issues remain on X11 threads when
causing OpenGL contexts associated with heavyweight widgets to be made
current on the QFT. On Windows the QFT is now used for all OpenGL work
when the Java2D/JOGL bridge is active.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@786 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
| |
hardware pointed out by Chris Campbell by unbinding the FBO from
Java2D's context before making it current in ours
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@677 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
| |
drawn from within the GLEventListener rather than in a guaranteed
fashion from the AWT event queue thread within paintComponent(),
causing problems on OS X with the new GLWorkerThread
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@669 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
context destruction. Now, in addition to tracking sharing between
contexts requested by the user, also tracks the behind-the-scenes
sharing going on with e.g. Java2D. Makes determination of whether
objects can be immediately destroyed by checking current context and
seeing whether it shares the same deleted object pool as the one being
destroyed. If objects can not be destroyed immediately, their
destruction is deferred until the next makeCurrent of a context
sharing objects with the one currently being destroyed (if one exists
-- the case of this being the last context actually referencing the
objects is handled by the OpenGL drivers). This fixes the resizing
problems seen when -Dsun.java2d.opengl.fobject=true is specified along
with -Dsun.java2d.opengl=true in Mustang.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@654 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
| |
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@645 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
| |
NVidia cards; made the code auto-detect whether the workaround is
needed
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@617 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
| |
and pointed to it from GLDrawableFactory, GLDrawable, GLCanvas and
GLJPanel
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@611 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
| |
the Java2D/JOGL bridge apparently causing exhaustion of VRAM
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@607 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
| |
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@604 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Discovered it was necessary to re-attach the color and depth
renderbuffers to the FBO in JOGL's context, even though it shared
textures and display lists with Java2D's context; this may be a driver
problem and merits further investigation. Found it was also necessary
to create a new depth renderbuffer; apparently could not use Java2D's.
This is almost certainly a driver bug. At this point, with the
forthcoming planned changes to Mustang, JOGL works when
-Dsun.java2d.opengl.fbobject=true is specified. Problems remain with
the HWShadowmapsSimple (extremely slow performance) and
InfiniteShadowVolumes (throws exception because of inability to share
textures and display lists between pbuffer's context with stencil
buffer and Java2D's context) demos. Worked around earlier exceptions
with InfiniteShadowvolumes demo by avoiding sharing textures and
display lists with dummy GLContexts. Changed build to produce DebugGL
and TraceGL earlier so they can be used in e.g. GLJPanel.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@599 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Java2D class to latest proposed set of APIs in OGLUtilities and
changed usage of these APIs to be approximately correct. Left in
fallback path for working with non-FBO case in current Mustang builds.
Not working yet, and don't yet understand why; checking in at this
intermediate point to be able to more easily test on more machines.
Added error checking to creation of external GLContexts and
GLDrawables on Windows and X11 platforms.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@597 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Obtained from:
Submitted by: Travis
Reviewed by:
These are all documentation changes in preparation for the Proposed Final
Draft submission.
Carefully separated out references to the implementation from the
specification. Did not delete any comments, just made sure that it was
clear when it was the Reference Implementation being referred to.
Add note to Spec Overview about version information. We now include
version information in the manifest of the jar file and we require
this of all implementations. This is currently done automatically
as part of the build process and is easy to access at runtime with
the java.lang.Package APIs.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@592 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLObjectTrackers are specified between contexts and separated this
from the maintenance of the GLContextShareSet, although the API
(registerForObjectTracking) is in the GLContextShareSet class. If the
Java2D/OpenGL pipeline and FBOs are active, causes all JOGL contexts
created to share textures and display lists with a context from Java2D
(currently acquired from a VolatileImage, but will probably need to
change how this is done). GLObjectTrackers however are only shared
between JOGL contexts where the user has explicitly requested sharing.
This yields the expected semantics of server-side object deletion when
the context is destroyed. Upgraded GLJPanel to handle FBO
manipulation. Not working yet; more debugging necessary on Java2D side
as well.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@585 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
| |
GLDrawableFactory.createGLPbuffer() based on JSR-231 expert group's
feedback. Updated GLJPanel and demos.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@464 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
| |
instantiation pointed out by Justin Couch
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@440 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
API more toolkit-agnostic:
1. Decoupled instantiation of GLCanvas and GLJPanel objects from the
GLDrawableFactory. GLCanvas and GLJPanel's constructors are now
public and the associated factory methods have been removed from
the GLDrawableFactory.
2. Changed the signature of GLDrawableFactory.
chooseGraphicsConfiguration() to accept and return marker
AbstractGraphicsDevice and AbstractGraphicsConfiguration
interfaces, respectively. Defined new AWTGraphicsDevice and
AWTGraphicsConfiguration wrapper classes simply wrapping the
associated objects. An SWT port could define similar wrapper
classes for its data types.
3. Allowed overriding of the specific GLDrawableFactory subclass
instantiated through GLDrawableFactory.getFactory() by setting the
system property "opengl.factory.class.name". For example, an SWT
port might swap itself in by specifying the following system
property on the command line:
-Dopengl.factory.class.name=com.ibm.swt.opengl.SWTGLDrawableFactory
Tested on Solaris/SPARC. Also fixed breakage on Solaris/SPARC due to
recent split of jogl native library into jogl and jogl_awt pieces.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@431 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
| |
etc. based on feedback from pepijnve on the javagaming.org forums.
Added documentation on what subclasses must do if these methods are
overridden as in Java3D specification.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@411 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
| |
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@408 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
contains the evolving JSR-231 Reference Implementation and the JSR-231
branch is permanently closed.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@401 232f8b59-042b-4e1e-8c03-345bb8c30851
|