aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Windows: Bump JVM to 6u29Sven Gothel2011-11-307-13/+13
|
* NEWTMacWindow:View: Make lock recursive ..Sven Gothel2011-11-292-15/+26
| | | | | Attempt to fix the shared-context-multithreading bug (eg. TestSharedContextVBOES2NEWT2) via proper locking .. but seems not to be sufficient (yet).
* NEWT MacWindow: the softLock (pthread mutex) is now always blocking (remove ↵Sven Gothel2011-11-291-18/+0
| | | | non blocking code)
* GLContextImpl*: createImpl() / makeCurrentImpl() refinement / robostnessSven Gothel2011-11-2916-50/+122
| | | | | | | | | | | | | | | createImpl(): If successful must leave context current. makeCurrentImpl(): Is only called if context is not just created, hence the boolean parameter 'boolean newCreatedContext' is removed. This clearifies and actually cleans up the native makeContextCurrent/releaseContext call pairs. MacOSXCGLContext: CGL and NS impl. of native makeContextCurrent/releaseContext uses CGL locking to provide a thread safety. This is recommended in OS X OpenGL documentation on [shared context] multithreaded use cases. Post creation code, as seen in some pbuffer cases is moved to overriden createImpl() methods.
* MacOSX: Expose CGL's CGLLockContext(..) and CGLUnlockContext(..) - to ↵Sven Gothel2011-11-291-0/+2
| | | | provide required locking in multithreading environment
* Test: Add TestSharedContextVBOES2NEWT2 (ES2 variant of ↵Sven Gothel2011-11-292-2/+160
| | | | TestSharedContextListNEWT2)
* Test: Forgot to uncomment package name of new test for ↵Sven Gothel2011-11-291-1/+1
| | | | 97218b88af9113740b3704a3666d7356cdc83cd0
* NEWT ScreenMode: Use unified ScreenMode in impl; X11Screen: Be verbose if TO ↵Sven Gothel2011-11-282-7/+7
| | | | reached, ie not successfully changed mode.
* Fix Bug 527: Creating a context w/ shared context, while the latter is in ↵Sven Gothel2011-11-2812-64/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use (threading) Bug 527 describes the situation where wglShareLists() fails (throws exception) while the shared context is in use by another thread (some Animator). It was reported by Jerome Jouvie. The exception happens not everytime, but at least around 20% on manual tests I have performed on the Windows platform. The context in question are all JOGL's GL2, which natively where bound to an OpenGL 3.0 profile. The WGL_ARB_create_context spec says http://www.opengl.org/registry/specs/ARB/wgl_create_context.txt: +++ Future versions of OpenGL may only support being added to a share group at context creation time. Specifying such a version of a context as either the <hglrc1> or <hglrc2> arguments to wglShareLists will fail. wglShareLists will return FALSE, and GetLastError will return ERROR_INCOMPATIBLE_DEVICE_CONTEXTS_ARB. +++ Hence the 1st patch was to remove 'wglShareLists()' usage in case we use the new WGL_ARB_create_context context creation method. Even though this is a desired change, and works in general, it didn't fix the issue. It seems that the shared context, which is passed @ new context creation, cannot be used while it is in use itself in another thread. This conclusion leads to the actual fix, ie. locking the shared context while creating the new context which shares it. Manual tests using this patch could not reproduce this issue (40 attempts). Test: TestSharedContextListNEWT2
* NEWT MacWindow: Fix positionChange() Usage ; Fix getLocationOnScreenImpl()Sven Gothel2011-11-271-32/+27
| | | | | | | | | - Native invocation of positionChange(x,y) uses screen coordinates of client area. Manual invocation shall respect the semantics - hence calling super.positionChanged w/ client coords. - getLocationOnScreenImpl() shall return the screen coordinates of the client area - Use getTopLevelLocationOnScreen(), ie substract Insets of getLocationOnScreenImpl()
* MacWindow: Impl. DriverUpdatePosition; Alias position2TopLevel -> ↵Sven Gothel2011-11-275-73/+88
| | | | | | | | getLocationOnScreenImpl Since the MacWindow position needs to be changed in concert with the parent, we need to be triggered to update ours. AWTParentWindowAdapter issues 'updatePosition()' if DriverUpdatePosition is implemented.
* JAWTWindow: Impl. insets (if AWT component is a Container)Sven Gothel2011-11-271-3/+14
|
* NEWT: Add DriverUpdatePosition interface; Clarify NativeWindow API doc ↵Sven Gothel2011-11-273-4/+19
| | | | | | | (position) DriverUpdatePosition: Interface tagging driver requirement of absolute positioning, ie. depend on parent position.
* NEWT OSX: Add stopNSApplication(), revert commit ↵Sven Gothel2011-11-273-9/+70
| | | | c26d6005e1fe74e9aee01d9d72942f566884fcd2
* MacOSX: Disable native verbositySven Gothel2011-11-264-4/+4
|
* NEWT OSX closeWindow: simple close, no extra view detachment etcSven Gothel2011-11-261-3/+0
|
* Revert some changes: X11Screen/RANDR, X11Util (XInitThreads/XLockDisplay), ↵Sven Gothel2011-11-264-11/+36
| | | | | | | | | | | | | | | NEWT XDisplay Locking Revert X11Screen RANDR commit 8cecd0c2963d982aa119cbb07698e56b9c271188, ie. use default 'render' display connection, best results on Ubuntu, Solaris, CentOS (no failures). Revert X11Util (XInitThreads/XLockDisplay) rational logic, commit 0314be79a7a93931a74fe4322bc78e699d7741e9, X11Util.HAS_XLOCKDISPLAY_BUG:=true and X11Util.XINITTHREADS_ALWAYS_ENABLED:=true. Which enables always utilizing XInitThreads() either before or after AWT initialization, as well as disable all XLockDisplay/XUnlockDisplay locks. Rever NEWT XDisplay X11 basic Locking commit 50100b85ce5fde48788efbc2211b26fb9d7c9dfd, ie use null locking if X11Util.HAS_XLOCKDISPLAY_BUG and X11Util.XINITTHREADS_ALWAYS_ENABLED.
* NativeWindow build: Remove duplicate class ↵Sven Gothel2011-11-261-3/+3
| | | | X11AWTGraphicsConfigurationFactory in JAR files
* X11Screen RANDR: Use temp display connection due to arbirary failures sometimesSven Gothel2011-11-261-6/+5
|
* X11Util: Remove wrapped/locked X11Lib methodsSven Gothel2011-11-2615-255/+42
| | | | | We shall lock a level above due to differentiation of XLockDisplay/RecursiveLock using X11/AWT ToolkitLock.
* MacOSXJAWTWindow: Also need to fix (onscreen:=false) of the encapsulated ↵Sven Gothel2011-11-261-1/+5
| | | | GraphicsConfiguration
* OSX GLLayer (native): Remove CALayer add/remove/swap sublayer animation; Fix ↵Sven Gothel2011-11-262-22/+28
| | | | | | | DestroyNSWindow0 The CALayer animations (add/remove/swap) confused somewhat rendering (layer position) and even triggered a deallocation sometimes.
* TestScreenMode00bNEWT: Reduce getCurrentScreenMode loop 100 -> 50, due to ↵Sven Gothel2011-11-261-2/+2
| | | | slow processing on CentOS / HD3400
* SharedResourceRunner: Use generics ; X11GLXDrawableFactory.SharedRunnable ↵Sven Gothel2011-11-263-17/+17
| | | | shutdown: don't attempt to close Display device.
* NEWT X11Screen: Update X11 RANDR / GL locking test code (still commented out)Sven Gothel2011-11-261-8/+13
|
* X11Util.shutdown(): Remove x11IOErrorHandlerSven Gothel2011-11-262-0/+7
|
* NEWT/GLContextImpl: Refine API doc, NEWT: Display name -> connection nameSven Gothel2011-11-263-7/+17
|
* TestParenting03AWT: manual test option -firstUIAction for ↵Sven Gothel2011-11-261-0/+4
| | | | GLProfile.initSingleton(firstUIAction)
* TestsGLSLShaderState*: Reduce loops / Extend timeout - Slow devices may hit ↵Sven Gothel2011-11-263-9/+11
| | | | TO otherwise.
* NEWT X11Display: Use default X11 locking for X11GraphicsDeviceSven Gothel2011-11-261-5/+15
| | | | | | | | Due to Display's reusage and hence concurrent involvement in off-thread animation, the X11 default lock is required. In case you require 2 GLWindow's w/o interference to each other (ie. locking), you need to use separate Display instances.
* NewtFactory/GLWindow: Cleanup API doc (Display lifecycle, copy or reuse, etc ..)Sven Gothel2011-11-262-22/+102
|
* DefaultGraphicsDevice: Initialize toolkitLock directly in cstr, where ↵Sven Gothel2011-11-261-4/+15
| | | | setToolkitLock(..) swaps the lock thread safe.
* X11Util: Cleanup ATI_HAS_XCLOSEDISPLAY_BUG API doc.Sven Gothel2011-11-261-9/+22
|
* X11AWTGraphicsConfigurationFactory: Use lock: owner ? AWT-Lock : X11-AWT-LockSven Gothel2011-11-261-1/+1
|
* Add Test case for bug 519Sven Gothel2011-11-251-0/+127
| | | | | | | | | | | Completes review of the underlying locking mechanism: - commit e341ad8db546530b3a49c56c32cc26980e296201 - commit c84e235b3284d0e18481748b44594116e25821a9 - commit a94c1a2945a31aa5d93e354da3bc80f59f253ec4 - commit 7ae0f2df39692e82d7955dbcd09c35c36382726c - commit 6b8f6e8d7c548cb6bfed14d8a04c9cf252ca7c4d - commit 9ef0a0c185ace5217efc014809e97c5eead842cc - commit 0314be79a7a93931a74fe4322bc78e699d7741e9
* Minor test changesSven Gothel2011-11-252-1/+5
|
* Complete commit bafd9b99816f55c105230a59211caf13f0315910 (NEWT):Sven Gothel2011-11-253-9/+16
| | | | | | - WindowImpl exposes private non-delegated GraphicsConfiguration, - which is being used by GLWindow's wrapped NativeWindow instantiation (eg: AWT driver) - Fix NewtFactoryAWT.getNativeWindow() use AWTGraphicsConfiguration.create(..)
* NativeWindow X11 Locking: Fix XInitThreads/XLockDisplay/XUnlockDisplay Usage ;Sven Gothel2011-11-255-79/+118
| | | | | | | | | | | | XLockDisplay/XUnlockDisplay shall only be used if XInitThreads() was successful, otherwise it has no effect (X11 spec). - Only issue XInitThreads() if firstX11ActionOnProcess==true, store result to determing whether we can utilize XLockDisplay/XUnlockDisplay. - If we cannot utilize XLockDisplay/XUnlockDisplay, use RecursiveLock - NativeWindowFactory: Only return AWTToolkitLock or X11JAWTToolkitLock if explicitly requested
* JAWTWindow: remove validateNative() ..Sven Gothel2011-11-254-60/+3
| | | | | - remove validateNative() - don't dispose AWT component, since we are an immutable uplink (was disposed if Window)
* GLX Information usage cleanupSven Gothel2011-11-257-190/+249
| | | | | | | - GLXUtil: Distinguish between client and server GLX information, cache client information. - GLXDrawableFactory: Utilize GLXUtil client data, as well as cache (SharedResource) GLX server data, avoiding 'uncontrolled' GLX queries, ie. w/o locking. - isMultisampleAvailable = isClientMultisampleAvailable && isServerMultisampleAvailable
* scripts: profile.jogl / setenv-jogl.sh / test.sh: Expose and use AWT / NOAWT ↵Sven Gothel2011-11-253-12/+32
| | | | | | CLASSPATH specific vars Enable tests w/ and w/o AWT JARs ..
* Fix native manual test 'displayMultiple02' for multiple X11 Display ↵Sven Gothel2011-11-251-6/+2
| | | | | | | connection open/close in various order XLockDisplay/XUnlockDisplay shall only be used if XInitThreads() was successful, otherwise it has no effect (X11 spec).
* Forgot to add JogAmp (c)Sven Gothel2011-11-259-0/+9
|
* NativeWindow X11GraphicsDevice: Pass 'owner' for close-display operation @ ↵Sven Gothel2011-11-256-21/+15
| | | | constructor
* Nativewindow AWT Device/Screen: Cleanup construction [default, specific]; ↵Sven Gothel2011-11-257-42/+19
| | | | AWTDevice: Remove subtype
* JOGL/NativeWindow: Push down JOGL's X11AWTGLXGraphicsConfigurationFactory to ↵Sven Gothel2011-11-257-171/+109
| | | | | | | | | | | | | | NativeWindow X11AWTGraphicsConfigurationFactory X11AWTGraphicsConfigurationFactory properly construct a AWTGraphicsConfiguration encapsulated a native X11GraphicsConfiguration, now available for non JOGL modules, ie NEWT. AWTGraphicsConfiguration's create() utilizes the X11AWTGraphicsConfigurationFactory via the generic factory mechanism and hence allows encapsulating a native [X11]GraphicsConfiguration. NewtCanvasAWT creates/destroys the JAWT NativeWindow on addNotify/removeNotify (reparentWindow) again. Hence the JAWTWindow is instantiated completly only, instead of utilizing updateConfiguration(..), which simplifies the mechanism.
* GraphicsConfigurationFactory: Kick off 'registerFactory' via static method ↵Sven Gothel2011-11-2315-49/+66
| | | | | | instead of constructor for clarity. - prepare for 'jogamp.nativewindow.x11.awt.X11AWTGraphicsConfigurationFactory'
* NativeSurface's getGraphicsConfiguration() returns the native (delegated) ↵Sven Gothel2011-11-2358-146/+177
| | | | | | | | | | | AbstractGraphicsConfiguration, if delegation is used. This change restricts the usage of AbstractGraphicsConfiguration's getNativeGraphicsConfiguration() to NativeSurface implementations and hence reduces complexity. NativeSurface implementations are adapted and access to it's AbstractGraphicsConfiguration is controlled via get/set method avoiding flawed usage (read/write), since read access shall return the delegated AbstractGraphicsConfiguration, if used.
* test scriptSven Gothel2011-11-231-2/+4
|
* AWTGraphicsConfiguration: Private special cstr. FIXME: Use 'encapsulated' ↵Sven Gothel2011-11-231-2/+4
| | | | ie. delegated in all cases.