| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
12 -> 7 in initialization.
Reducing the calls to resetProcAddressTable() 12 -> 7 in initialization, saves:
Linux/AMD: 600ms -> 300ms
Linux/NV: 161ms -> 112ms
OSX 10.7/NV: 522ms -> 397ms
Still some freezes on OSX 10.6.8/NV .. further analysis is going on.
|
| |
|
|
|
|
| |
is called 1st, add tests. Add performance numbers of init/shutdown in tests.
|
|
|
|
| |
GLWindow/NewtCanvasAWT to AWT Applet Container
|
|
|
|
| |
hook or not
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'dead' thread (Applets)
GLDrawableFactory:
- clarify: public getWasSharedContextCreated(..) -> protected createSharedResource(..)
- add: getSharesResourceThread()
GLProfile:
- proper locking of initSingletion(..) path:
- Use RecursiveThreadGroupLock and add/remove GLDrawableFactory's sharesResourceThread
while creating it's the sharedResource.
This simplifies and fixes GLProfile's locking code.
- Fix and simplify initSingleton(boolean) API doc - mark it deprecated.
- Add initSingleton() for controlled initialization only, pairing w/ shutdown(..)
Remove initSingleton(boolean) calls in code and test!
+++
Fix SharedResourceRunner 'dead' thread (Applets)
In Applets, stopping an Applet makes the browser Java plugin interrupting
and killing all related threads, including our SharedResourceRunner thread.
- Validate whether the shared resource thread is alive
- Catch interruption in shared resource thread and assume it's a kill signal
- releaseSharedResource: clear devicesTried set
|
|
|
|
|
|
|
|
|
|
| |
> 0: UP
< 0: DOWN
See MouseEvent.getWheelRotation() for details.
OSX/Windows: Default to wheel 'button' 1
OSX: Properly report '<0'
X11: Synthesize wheel events by mapping buttons 4/5 and 6/7 to wheel 1 and 2.
|
| |
|
|
|
|
| |
n/a on some AWT impl.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Management
- Leave Platform, .. TempJarCache untouched.
- GLDrawableFactoryImpl*: Leave DynamicLibraryBundle(lib-binding) untouched,
for NativeLibrary, JNILibLoaderBase (JNI libs), .. consistency.
- SHARED_ONLY: shutdown shared GLDrawableFactoryImpl* resources and NativeWindowFactory
- COMPLETE: additionally shutdown GLContext*
Clear all cached GL/GLX proc-address and device/context mappings.
- Use new "GLProfile.shutdown(GLProfile.ShutdownType.SHARED_ONLY)" in Applets
- X11GLXDrawableFactory Shutdown: Uncomment close/destroy of shared resources.
- JAWTWindow.destroy(): Close the delegated device.
In case it's X11 this closes the exclusive opened X11 Display.
|
|
|
|
| |
(GLContextImpl)
|
| |
|
| |
|
|
|
|
| |
JNILibLoaderBase addNativeJarLibs(..)
|
| |
|
|
|
|
|
|
|
|
| |
X11Util:
- shutdown: keep list of displays, if not really closed.
- Init default display name in initSingleton.
GDISurface: Check ReleaseDC and throw exception if fails
|
| |
|
| |
|
|
|
|
| |
constructor/destroy()
|
|
|
|
|
|
| |
RegisteredClassFactory: Reference the factories itself instead of the RegisteredClass.
This enables the shutdown hook to clear the factories state,
which is required for proper recreation.
|
|
|
|
|
|
|
|
|
|
|
|
| |
lifecycle.
Applet 'restart' (init.start.stop.destroy .. init.start...)
didn't work on Windows browsers (Firefox, Safari, Chrome, ..) w/ JVM 6u26..6u29.
It seems that after destroy we loose the ClassLoader already (plugin2)
hence we need to bind to the native resources again.
Solution is to map the JOGL lifecycle of GLProfile [initSingleton()..shutdown()]
to the Applet's [init..destroy].
|
|
|
|
|
|
|
|
|
|
|
|
| |
More Robust GLProfile Initialization
- Catch GLException in GLDrawableFactory getWasSharedContextCreated(device) impl.,
which may fail (See comment on Firefox/Chorme EGL deployed library for Windows).
- If getWasSharedContextCreated(devide) fails, set respective factory availability to false,
ie. hasDesktopGLFactory, hasEGLFactory, ..
Add NativeWindowFactory Shutdown
- Currenly a dummy entry, may evolve. X11Util shutdown is issued by respective GLDrawableFactory
|
|
|
|
|
| |
Attempt to fix the shared-context-multithreading bug (eg. TestSharedContextVBOES2NEWT2)
via proper locking .. but seems not to be sufficient (yet).
|
|
|
|
| |
non blocking code)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
TestSharedContextListNEWT2)
|
|
|
|
| |
97218b88af9113740b3704a3666d7356cdc83cd0
|
|
|
|
| |
reached, ie not successfully changed mode.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
- 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()
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
(position)
DriverUpdatePosition:
Interface tagging driver requirement of absolute positioning, ie. depend on parent position.
|
|
|
|
| |
c26d6005e1fe74e9aee01d9d72942f566884fcd2
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
We shall lock a level above due to differentiation of XLockDisplay/RecursiveLock
using X11/AWT ToolkitLock.
|
|
|
|
| |
GraphicsConfiguration
|
|
|
|
|
|
|
| |
DestroyNSWindow0
The CALayer animations (add/remove/swap) confused somewhat rendering (layer position) and
even triggered a deallocation sometimes.
|
|
|
|
| |
slow processing on CentOS / HD3400
|
|
|
|
| |
shutdown: don't attempt to close Display device.
|
| |
|
| |
|
| |
|
|
|
|
| |
GLProfile.initSingleton(firstUIAction)
|
|
|
|
| |
TO otherwise.
|