Bug 776

Summary: Allow sharing a GLContext w/ GLAutoDrawable more conveniently
Product: [JogAmp] Jogl Reporter: Sven Gothel <sgothel>
Component: macosxAssignee: Sven Gothel <sgothel>
Status: RESOLVED FIXED    
Severity: enhancement    
Priority: ---    
Version: 2   
Hardware: All   
OS: all   
Type: --- SCM Refs:
7f7a23dd0ddf106e6f0c69fc2a05ff92ac56200e aa7cbaea0c6998644ca9311f269ba0aae224d1c4 f73c10f71be979d214537679f85f1897c5642e11 bcfaa149b9803ce33c5a356cbcb45f7dfd3e4361 3598b398dfd39502078f3750ad97bbbece060846 5dffa6a4895a06edc44de6fe335c35af291fbd19 d8074fb1df1bdb63fdb97585c797c15d34695e9c 9f2a9df0a4b7093925c8854b37fba053469a4b35 6f9cb656934fe9daa85e585ee2770210ceb43950 5cb08416a6ed44814065771f469a94f79c49ab3f c53440b808ecf8ea066479c004cac4cdbb1e989d d2690939b46a91b346bdd2d4ce750ddb0d2136fd
Workaround: ---
Bug Depends on: 873    
Bug Blocks:    
Attachments: Example sharing contexts and using the same VBO from different GLCanvases
JOGLTabbedPaneUsageFixed.java
Patch of to get fixed version of JOGLTabbedPaneUsage w/ annotations
Log file - OSX CALayer Java7
Log file - Linux X11 Java7

Description Sven Gothel 2013-07-11 04:40:12 CEST
Created attachment 492 [details]
Example sharing contexts and using the same VBO from different GLCanvases

> *From:*Tom Gaskins [mailto:tom@tomgaskins.com]
> *Sent:* Tuesday, July 09, 2013 10:18 AM

<snip/>

> I've attached a very simple standalone program that
> attempts to do the same thing that World Wind is doing -- sharing contexts and
> using the same VBO from different GLCanvases. It doesn't exhibit the same
> failure mode that World Wind does when trying to do this. In World Wind the
> application crashes right away. In this example an exception is generated when
> you attempt to view Window B. Neither failure is expected.
Comment 1 Sven Gothel 2013-10-25 07:05:26 CEST
Created attachment 525 [details]
JOGLTabbedPaneUsageFixed.java

Fixed version of JOGLTabbedPaneUsage w/ annotations
Comment 2 Sven Gothel 2013-10-25 07:06:12 CEST
Created attachment 526 [details]
Patch of to get fixed version of JOGLTabbedPaneUsage w/ annotations

Patch of to get fixed version of JOGLTabbedPaneUsage w/ annotations
Comment 3 Sven Gothel 2013-10-25 07:06:47 CEST
Created attachment 527 [details]
Log file - OSX CALayer Java7
Comment 4 Sven Gothel 2013-10-25 07:07:15 CEST
Created attachment 528 [details]
Log file - Linux X11 Java7
Comment 5 Sven Gothel 2013-10-25 07:09:39 CEST
There is no issue w/ shared context on OSX/CALayer or otherwise ..

However, there were at least two issues w/ the test case:
  - Buffer not bound before using (glVertexPointer)
  - GLCanvas's GLContext (intended to be shared) was not yet created

Fixed version tested on:
  - GNU/LInux X11 Java 7 
  - OSX 10.7 and 10.9 w/ CALayer usage and Java7

See attachments ..

~Sven
Comment 6 Sven Gothel 2013-10-25 07:11:33 CEST
Besides, ctx sharing is thoroughly tested on all platforms via unit tests: 
  - TestSharedContextVBOES1NEWT
  - TestSharedContextVBOES2NEWT
  - TestSharedContextNewtAWTBug523
  - TestSharedContextList*
Comment 7 Sven Gothel 2013-10-26 00:04:31 CEST
Regarding GLCanvas lazy initialization, as specified in it's GLAutoDrawable super interface:

    The implementation shall initialize itself as soon as possible,
    ie if the attached {@link javax.media.nativewindow.NativeSurface NativeSurface} becomes visible/realized.

Hence, this is true for all GLAutoDrawable instances.

Why is it ?

B/c we cannot create a NativeSurface wrapper instance before it exists,
we cannot create a drawable based on it,
and hence no GLContext.

The immediate creation, as it was w/ JOGL1, has been proven to be in-accurate
and erroneous.

We need the NativeSurface's GraphicsConfiguration to properly determine 
_what_ type of instances we actually have to declare. One example is OSX's CALayer .. etc.

A very simple remedy for your orig. use-case - besides the suggested fix,
is to create a common shared offscreen context, which you immediately
realize (makeCurrent()/release()) .. you may fetch a providing offscreen drawable
via:  GLDrawableFactory.createDummyDrawable(..) !!!
The above is used in GLMediaPlayer.StreamWorker.initGL(GL) <- have a look !!

Besides .. the other mentioned shared GLContext unit tests follow a similar approach:
  - TestSharedContextVBOES1NEWT
  - TestSharedContextVBOES2NEWT
  - TestSharedContextNewtAWTBug523
  - TestSharedContextList*
Comment 8 Sven Gothel 2013-10-27 00:46:54 CEST
Reopened: Refine unit tests to be explanatory .. also add queries to GLContext
allowing to retrieve the shared state.
Comment 9 Sven Gothel 2013-10-27 17:53:55 CET
http://jogamp.org/git/?p=jogl.git;a=commit;h=7f7a23dd0ddf106e6f0c69fc2a05ff92ac56200e

Refine API for relaxed and lazy GLContext sharing ; Fix GLContext memory contract (volatile)

(Unit test remarks see below)

- Add shared GLContext queries
  - Refined GLContextShareSet:
    - Use IdentityHashMap since GLContext's can only be identical w/ same reference (footprint, performance)
    - Add API doc for clarification
    - Add methods:
       - ArrayList<GLContext> getCreatedShares(final GLContext context)
       - ArrayList<GLContext> getDestroyedShares(final GLContext context)
    - Use 'final' where possible

  - Add GLContext methods:
      - boolean isShared()
      - List<GLContext> getCreatedShares()
      - List<GLContext> getDestroyedShares()

- Add GLSharedContextSetter interface defining setting a shared GLContext
  directly (GLContext) or via a GLAutoDrawable:
  - setSharedContext(GLContext)
  - setSharedAutoDrawable(GLAutoDrawable)

  Both cause initialization/creation of GLAutoDrawable's drawable/context to be postponed,
  if the shared GLContext is not yet created natively or
  the shared GLAutoDrawable's GLContext does not yet exist.

  Most of impl. resides in GLDrawableHelper

  Implemented in:
    - GLAutoDrawableBase, GLOffscreenAutoDrawable
    - GLWindow
    - AWT GLCanvas

  TODO:
    - GLJPanel
    - SWT GLCanvas

- GLDrawableFactory:
   - Add 'GLOffscreenAutoDrawable createOffscreenAutoDrawable(..)' variant w/o passing the
     optional shared GLContext _and_ specifying lazy GLContext
     creation. This allows to benefit from GLSharedContextSetter contract.
     Lazy GLContext creation is performed at 2st display() call at the latest.

     All JOGL code and unit tests use this new method now.

  - Mark 'createOffscreenAutoDrawable(..)' w/ shared GLContext argument
    and immediate GLContext creation deprecated - shall be removed in 2.2.0

- Make reference to GLContext and it's native handle volatile
  Since we rely on the query 'GLContext.isCreated()' to properly allow GLAutoDrawable's to query whether
  a shared GLContext is natively created (already), the handle must be volatile
  since such query and the actual creation may operate on different threads.

+++++

- Add/Refine shared GLContext unit tests demonstrating diff. sharing methods.

  All variants of using shared GLContext:
      com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextVBO*

  Most convenient way to share via setSharedAutoDrawable(GLAutoDrawable):
      com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextVBOES2[NEWT|AWT]3

  AWT use w/ JTabbedPane using setSharedAutoDrawable(GLAutoDrawable):
      com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextWithJTabbedPaneAWT
Comment 10 Sven Gothel 2013-10-27 18:58:02 CET
aa7cbaea0c6998644ca9311f269ba0aae224d1c4
  Fix GLCanvas ctor shared GLContext: Use helper.setSharedContext(..) remove local shared ctx fields.

f73c10f71be979d214537679f85f1897c5642e11
  Bug 776 GLContext Sharing: Add GLSharedContextSetter to GLJPanel
Comment 11 Sven Gothel 2013-10-28 04:00:37 CET
bcfaa149b9803ce33c5a356cbcb45f7dfd3e4361

- Add note about driver stability (destruction order)
  - See GLSharedContextSetter: Don't destroy master context before slaves!
    
- Fix spec-overview.html#SHARED links, add link to GLSharedContextSetter in SHARED subsection.
    
- Fix unit tests (Shared Gears, wait for created context and destruction order)
  - The GearsObject sharing was completly bogus!
    It simply used the _same_ GLArrayDataServer instance for sharing,
    but it should use a _copy_ of the shared GLArrayDataServer while
    only preserving the VBO object!
    Fixed, while adding required methods to GLArrayDataServer.
    
  - Waiting for the created GLContext of a GLAutoDrawable required us
    to pass the latter _and_ check whether it's GLContext exists and is natively created.
    
  - Accomodated the destruction order - see above!
Comment 12 Sven Gothel 2013-10-30 01:06:55 CET
3598b398dfd39502078f3750ad97bbbece060846
  Add GLSharedContextSetter to SWT GLCanvas

5dffa6a4895a06edc44de6fe335c35af291fbd19
  TestSharedContextNewtAWTBug523: Don't use VAO's w/ GL2 context - No VAO on GL2 ctx on OSX ; GLWindow #2 shall also use sharedDrawable; Cleanup  ..

d8074fb1df1bdb63fdb97585c797c15d34695e9c
  GLDrawableFactory: Add 'GLAutoDrawable createDummyAutoDrawable(..)' for convenience

9f2a9df0a4b7093925c8854b37fba053469a4b35
  Add copy-ctor to GLArrayData* w/ sliced Buffer; Refine GearsObject* GLArrayDataServer copying; GearsES*: Init VBO eagerly

6f9cb656934fe9daa85e585ee2770210ceb43950
   Fix copy-ctor GLArrayDataClient: Create new instance of GLArrayHandler of same type; Simplify GLArrayHandler inheritance.

5cb08416a6ed44814065771f469a94f79c49ab3f
   GLSharedContextSetter API Doc: No 'Driver stability constraints' ; Fixing Test cases: Enable all, GearsObject*: Check VBO
Comment 13 Sven Gothel 2013-10-30 01:59:07 CET
c53440b808ecf8ea066479c004cac4cdbb1e989d
  GLSharedContextSetter API Doc: Add 'glFinish()' to lifecycle considerations ; GearsES2: Add glFinish() after init().

All 'junit.run.sharedctx' (ant target of build-test.xml) passed on 
  - GNU/Linux/X11
  - Windows 7
  - OSX 10.7.5
  - OSX 10.9 (rare concurrency crashes ..)
Comment 14 Sven Gothel 2013-10-30 20:28:20 CET
d2690939b46a91b346bdd2d4ce750ddb0d2136fd
  Fix Unit Test Regression (commit 9f2a9df0a4b7093925c8854b37fba053469a4b35): GearsObject used getGL2ES2(), which is not allowed.
Comment 15 Sven Gothel 2013-10-31 00:47:12 CET
Related is our 'tracking' Bug 873,
which tracks  the Intel/Mesa one <https://bugs.freedesktop.org/show_bug.cgi?id=41736>.