| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
offscreen drawables, reported by Mark Raynsford
New common GLAutoDrawableBase missed to close the AbstractGraphicsDevice
in case it has been created and dedicated for the passed GLDrawable.
This detailed knowledge is only known to the creator, hence it is passed
in the constructor and is being passed through all specializations.
Further more the new X11/GLX impl. of GLDrawableFactory's
'createMutableSurfaceImpl' always creates it's own private X11 display connection
to avoid locking / threading issues. Since the old implementation reused the
shared display connection which is prone to threading issues, this bug was not visible before.
Also fixed the unit test TestNEWTCloseX11DisplayBug565,
now correctly validating that no display connection is left over
after a new cycle of create/destroy of onscreen and offscreen drawables.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLAutoDrawable multi-threading w/ proper pattern (hope so)
Considering code changes and remarks:
3ed491213f8f7f05d7b9866b50d764370d8ff5f6
1a91ec5c8b6fd9d9db7bc115569c369fe7b38e9b
3334a924309a9361a448d69bc707d4cce416b430
4f27bcecf7484dc041551f52a5c49e2884cb3867
It seems necessary to have
- recursive locking employed for all semantic actions which changes drawable & context (and the Window resource)
- to avoid deadlock, we have to ensure the locked code segment will not spawn
off to another thread, or a thread holds the lock, spawns of an action requiring the lock. .. sure
- other read-only methods (flags, ..) shall at least utilize a safe local copy of a volatile field
if further use to produce the result is necessary.
- flags like sendReshape require to be volatile to guarantee it's being processed
Patch impacts: AWT/SWT GLCanvas, GLAutoDrawableBase [and it's specializations]
and hopefully closes any loopholes of missing a cache hit, etc.
If you review this and find optimizations, i.e. removing a lock due to semantics etc,
don't hold back and discuss it, please.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- GLAutoDrawable (compat change - recompile):
- 'void invoke(boolean wait, GLRunnable glRunnable)' -> 'boolean invoke(boolean wait, GLRunnable glRunnable)'
Allows notifying caller whether the task has been executed or at least enqueued.
- GLAutoDrawable add 'GLEventListener removeGLEventListener(int index)'
- This allow one to remove a specific GLEventListener and reusing it (return value).
- GLDrawableImpl remove 'destroy()' to favor 'setRealized(false)'
- Using more common code of GLAutoDrawableBase, i.e. GLPbufferImpl can use defaultDestroyOp().
- Removes redundancy of methods
- GLAutoDrawableBase/Delegate
- better 'default' names to emphasize it's purpose, adding API doc
- includes more generic functionality
- defaultWindowDestroyNotify()
- defaultDestroyOp()
- TestGLAutoDrawableDelegateNEWT demonstrates a simple example w/ all window events handled.
- Fix TestParenting01cSwingAWT's threading use (gl disturbance thread)
|
|
|
(GLWindow, ..); Add new GLAutoDrawableDelegate.
- Refine API doc
- 'void setContext(GLContext)' -> 'GLContext setContext(GLContext)'
- Add note to createContext(GLContext) override
-Use new abstract impl. GLAutoDrawableBase, used by:
- GLWindow
- GLAutoDrawableDelegate
- GLPbufferImpl
- Add new GLAutoDrawableDelegate incl. unit test
|
