Remodel OSX/CALayer Threading (commit 896e8b021b39e9415040a57a1d540d7d24b02db1): Run on main-thread w/o blocking ; Misc Changes

Commit 896e8b021b39e9415040a57a1d540d7d24b02db1 moved all native CALayer calls to the current thread
to avoid deadlocks.

Even though this seemed to be fine at least resource GC (release/dealloc calls) were issued
very late in time, probably due to multithreading synchronization of JAWT and/or OSX API.

Example: Our 'TestAddRemove01GLCanvasSwingAWT' test didn't freed CALayer resources incl. GL ctx
         when destroying the objects (AWT Frame, GLCanvas, ..), leading to resource starvation .. eventually.

Remedy is a compromise of behavior before commit 896e8b021b39e9415040a57a1d540d7d24b02db1
and that commit, i.e. to run CALayer lifecycle methods on main-thread, but do not block!

The careful part within MacOSXCGLContext.associateDrawable(..) performs the following block on main-thread:
  - lock the context
  - create NSOpenGLLayer (incl. it's own shared GL context and the DisplayLink)
  - attach NSOpenGLLayer to root CALayer
  - unlock the context

Due to the GL ctx locking, this async offthread operation is safe within our course of operations.

Details:
  - NSOpenGLContext
    - Context and CVDisplayLink creation at init
    - Call [ctx update] if texture/frame size changed
    - 'waitUntilRenderSignal' uses default TO value if given TO is 0 to avoid deadlocks

+++

Misc Changes:
  - Fix object type detection: isMemberOfClass -> isKindOfClass
    - OSXUtil_isNSView0
      OSXUtil_isNSWindow0,
      CGL_isNSOpenGLPixelBuffer

  - MacOSXCGLDrawable/MacOSXPbufferCGLDrawable: remove getNSViewHandle() method.
    MacOSXCGLContext uses common code to detect nature of the drawable handle.

  - MacOSXCGLContext/CALayer: Use safe screenVSyncTimeout values, never 0 to avoid deadlock!

  - JAWTWindow.invalidate: Call detachSurfaceLayer() if not done yet

0 files changed, 0 insertions, 0 deletions