Fix synchronization issues in GLDrawableHelper.flushGLRunnables(), fixes rare deadlock with animator-exception and invoke(wait=true, ..)
Fix synchronization issues in GLDrawableHelper.flushGLRunnables(): - Querying 'glRunnables.size()' is not synchronized, only its reference is volatile, not the instance's own states.
- 'flushGLRunnable()' must operates while acquired the 'glRunnable' lock.
- 'glRunnables' are no more volatile
- introduced volatile 'glRunnableCount', allowing 'display(..)' method to pre-query whether blocking 'execGLRunnables(..)' must be called. This is risk (deadlock) free.
Also fixes rare deadlock in animator display-exception / GLAD.invoke(wait=true, ..) case: - 'GLDrawableHelper.invoke(.., GLRunnable)' acquires the 'glRunnable' lock. - Then it queries animator state, which is blocking. - Hence animator's 'flushGLRunnable()' call must happen outside the animator lock
Fix GLContextImpl.setRendererQuirks(..) CTX_IMPL_ACCEL_SOFT profile state
- GLContextImpl.setRendererQuirks(..) in called in GLContextImpl.setGLFunctionAvailability(..)
- GLContextImpl.setRendererQuirks(..) was called before fixing CTX_IMPL_ACCEL_SOFT via isCurrentContextHardwareRasterizer().
The latter set CTX_IMPL_ACCEL_SOFT based on known software renderer string within GL_RENDERER.
This lead to incorrect hwAccel assumption and hence wrong setting of GLRendererQuirks: - NoDoubleBufferedPBuffer (was selected even w/ later CTX_IMPL_ACCEL_SOFT) - BuggyColorRenderbuffer (was never selected)
- Fix performs GLContextImpl.setRendererQuirks(..) _after_ fixing CTX_IMPL_ACCEL_SOFT via isCurrentContextHardwareRasterizer().
- The animator monitor-lock was still hold in the post finally block issuing flushGLRunnables(), due to intrinsic monitor release (in finally): - <http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10> - <http://stackoverflow.com/questions/10743285/behavior-of-a-synchronized-method-with-try-and-finally>
- Further: AnimatorBase.flushGLRunnables() acquired the lock itself (duh!)
This commit removes the requirement for finally altogether by simply return a boolean from handleUncaughtException(caughtException), where false denotes the caller to propagate the exception itself (no handler).
Post synchronized block then issues flushGLRunnables() and exceptation propagation as required.
AnimatorBase.flushGLRunnables() 'synchronized' modifier is removed.
Further, ThreadDeath is being propagated if caught. Here the finally block is also removed - redundant.
FontFactory Remove: - Font get(final URLConnection conn) - Font get(final InputStream stream)
FontFactory Add: - [1] Font get(final InputStream stream, final int streamLen, final boolean closeStream) - Direct usage of font InputStream w/ determined length, may instantiate BufferedInputStream in case given stream doesn't support mark/reset!
- [2] Font get(final InputStream stream, final boolean closeStream) - Copy font InputStream w/o determined length, resulting in BufferedInputStream supporting mark/reset!
Security Related: - Only perform priviledged code on determine InputStream, _not_ when parsing the font stream itself!
- Hence PrivilegedAction only happens in FontFactory's InputStream preparation.
Bug 1078: Add Fallback in AWTPrintLifecycle.setupPrint(): Use Onscreen GLAD if Offscreen-GLAD Realization throws an Exception (Stability)
- GLDrawableFactoryImpl: createOffscreenDrawable(..) and createDummyAutoDrawable(..) Temporary catch exception during setRealized(true) of newly created GLDrawable, to unrealize the instance before propagating the exception.
This handling removes a memory leak in case the exception of this method is handled and application continues to operate, e.g. as in AWTPrintLifecycle.setupPrint().
The underlying drawable gets unrealized, since it's setRealized(boolean) implementation toggles its realize-state before delegating the realize-operation. Hence this is functional.
- AWTPrintLifecycle.setupPrint() Stability Catch exception thrown by factory.createOffscreenAutoDrawable(..)'s setRealize(true) to continue operation w/ onscreen GLAD.
Bug 1081: Fix GLJPanel Regression: Honor pre-init reshape-size at initializeBackendImpl()
Commit 84f367a73c5b16dcebfd877e82e1c2cb90ae74ce removed utilization of reshape-size in case panel-size is valid, even if a reshape event happened in between: - addNotify - paintComponent
initializeBackendImpl() includes now uses reshape-size IFF handleReshape is set. Before it was using reshape-size only if panel-size was invalid.
Uses System.err instead of System.out in order to drive the debug logs more consistent, adds a method to convert an attribute list into a capabilities object with no check in order to display some information about skipped capabilities objects and fixes a NullPointerException when skipping a capabilities object
Bug 1085: Fix GLJPanel regression while printing w/ invisible GLJPanel: Zero size panel size
This is a regression due to commit 84f367a73c5b16dcebfd877e82e1c2cb90ae74ce: GLJPanel Cleanup: Remove initial FBO reshape; ** Propagate reshape only if differs from panel-size; ** <- this one Use pre-fetched panel-size.
Above commit only issued 'sendReshape' if the reshape-size differs from the actual panel-size.
Note: The reshape-size is propagated to panel-size either in [1] initializeBackendImpl(..) or [2] handleReshape(..) @ paintComponent.
While printing w/ an invisible GLJPanel the reshape-size has not yet propagated to the panel-size (see above) and two consecutive reshape calls will cause the last one to be dropped.
![[Jenkins]](/chuck/static/5bc96da9/images/svgs/logo.svg){kind=logo}
