| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
surfaceUpdated(); BroadcomEGL: Use custom surfaceSwap(); GLDrawableImpl's: Utilize NativeWindow's surfaceSwap() and surfaceUpdated(); Fix common enum of GL2ES1 and GL2GL3, merge them in GL
|
|
|
|
| |
non native OS factory is available
|
| |
|
|
|
|
| |
(-Dnativewindow.ws.name=BroadcomEGL): 1st Draft of supporting broadcom's proprietary EGL mapping
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Clean up X11 dependency
- NativeWindow:
- Seperate X11 out of core.
- Add nativewindow.x11.jar and nativewindow.x11.cdc.jar
- Newt:
- Seperate X11,win,osx out of core.
- Add newt.x11.jar, newt.win.jar, newt.osx.jar and the CDC variants
Fix: External Context & Drawable (X11 and Windows)
- Properly fetch current context values (ctx, display, drawable, ..)
- Create GraphicsConfiguration based on the given pixelformat/FBConfig
Fix: Java2D OpenGL Usage
- Using the external context as shared for the external drawable
- JAWTUtil: Skip locking in case of OGL-Flush-Queue
- TODO: Windows FBO still does not work .. (X11 is fine)
|
|
|
|
| |
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@2018 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
| |
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@2016 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Cg classes reside in jogl.cg.jar
- Restrict native Cg library dependency only to the jogl cg library,
which is loaded from the CgGL class only.
- Tested Cg demos with and w/o Cg installation,
tested regular GL demos with and w/o Cg installation.
(Linux & MacOSX)
- jogl/etc/profile.jogl
- Changed invocation: $0 <JOGL-PROFILE> [jogl-build-dir]
- Autodetects if used from within a autobuild directory
- Added it to the autobuild zip file
- Fixed: NativeWindow X11GraphicsScreen, adding missing Toolkit locks
- Set RI to true !
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@2009 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Multithreading / Locking ..
It turns out that there exist platforms with a
buggy thread safe OpenGL/GLX/.. implementation.
E.g. Linux x86_64, NV 185.18.14 where 1/6 attempts
of the test case
java -Djava.awt.headless=true demos.es2.RedSquare -GL2 -GL2 -GL2 -GL2
will result in:
C [libGL.so.1+0x5c08a] glXGetFBConfigAttrib+0x40a
[error occurred during error reporting (printing native stack), id 0xb]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sun.opengl.impl.x11.glx.GLX.glXGetFBConfigAttrib1(JJILjava/lang/Object;I)I+0
j com.sun.opengl.impl.x11.glx.GLX.glXGetFBConfigAttrib(JJI[II)I+67
j com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfiguration.glXGetFBConfig(JJI[II)I+24
In these cases, you can set the system property
nativewindow.locking=true
to always use the generic reentrance capable
LockingNativeWindowFactory implementation as a last resort.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1992 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current thread default display or
the given display is being used,
hence it is no more required to use a ToolkitLock
for X11 without AWT.
Removed X11 ToolkitLock in case of X11 without AWT,
which is being detected with the absence of the classes
java.awt.Component _AND_ javax.media.nativewindow.awt.AWTGraphicsDevice
or with the system property
java.awt.headless=true
Only in the Java2D/Swing case, one 'leaking' Display
is created within canCreateGLPbuffer().
- Workaround for Hotsport bugs #4395095, #6852404
4395095 JNI access to java.nio DirectBuffer constructor/accessor
6852404 Race condition in JNI Direct Buffer access and creation routines
- Added build.xml
-Dbuild.noarchives=true property to skip the time consuming
creation of zip archives.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1988 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that under some circumstances,
e.g. >3 threads within initialization time,
the static X11Display usage result in a
native deadlock within glXQueryServerString().
The call never returned. May be
This happend even with NativeWindowFactory.getDefaultFactory().getToolkitLock().lock();
Removed X11Util.getStaticDefaultDisplay()
This allows us to remove the ToolkitLock around
these segments, due to a thread local X11Display utilization.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1977 232f8b59-042b-4e1e-8c03-345bb8c30851
|
|
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1959 232f8b59-042b-4e1e-8c03-345bb8c30851
|