| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
delegated Activity, i.e. our ActivityLauncher
|
|
|
|
| |
BaseNewtEventModifiers ignore more events (clicked, wheel, entered, exited); Fix TestNewtEventModifiersNewtCanvasSWT SWT-Display thread.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TODO: NEWT Event Factories. Misc: Cleaned up spacing.
On some native OS, the accumulation of pressed button modifier-mask is not available, e.g. OS X.
NEWT WindowImpl.doMouseEvent(..), invoked by native NEWT events,
will track the pressed mouse button modifier-mask, similar to mouseButtonPressed to synthesize the DRAGGED event.
Added NEWT WindowImpl.doKeyEvent(..) to honor the pressed mouse button modifier-mask,
i.e. pass it w/ key events as well.
TODO: Unify synthesization of NEWT event artifacts as described by the above,
allowing NEWT event translation to benefit from same code to gain same semantics.
Notable: AWTNewtEventFactory and SWTNewtEventFactory
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Finetune delay
- Wait for eventCount
- Fix Listener concurrency
- Manually tested (enabled in our unit tests now)
- Tool Combinations
- NEWT GLWindow
- AWT GLCanvas
- NewtCanvasAWT
- NewtCanvasSWT
- On
- Linux/X11
- Windows
- OSX(+)
(+): Failure NEWT: When multiple buttons are pressed,
only the last one is visible via modifier MASK.
"expected:[button1, button2], have: [button2]"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- AWTNewtEventFactory's awtModifiers2Newt:
- always include NEWT BUTTON_MASK (press, release, ..)
where AWT doesn't include them at release (it's only a DOWN_MASK).
- Test BaseNewtEventModifiers, ..
- No need to call super class Before, BeforeClass, .. manually
- Use RedSquareES2 as GL demo
- Adapt to AWTNewtEventFactory's modifier change above (NEWT BUTTON MASK even at release)
- More descriptive error/log text
- Added _mandatory_ TestNewtEventModifiersNEWTWindowAWT
to test native NEWT behavior.
This shall be the golden behavior all translated events shall compare w/.
|
|
|
|
| |
com.jogamp.opengl.test.junit.newt.event
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
811e3791b98fea0dfa3b7d301cb532c54df8dc82: AWT-NEWT Modifier mapping - part-2
AWTNewtEventFactory:
- getAWTButtonMask() -> getAWTButtonDownMask()
- using proper _DOWN_MASK values (regression of commit 13168c99ff9e8bf71c83f1be7afee270a3db4074)
- com.jogamp.newt.event.MouseEvent.BUTTON_NUMBER buttons
- adding 'ModifierMappings.txt' to API doc header
- remove obsolete 'int awtModifiers2Newt(int awtMods, boolean mouseHint)'
- 'int awtButton2Newt(int awtButton)' 1:1 button name mapping
Tests:
- rename TestNewtEventModifiers -> BaseNewtEventModifiers
to avoid being picked up by our junit testing framework.
The latter tests all classes starting w/ 'Test*'
|
|
|
|
| |
clean (was using Java7 stuff); Note: Need to test!
|
|\
| |
| | |
Fix For Bug 629, Plus First Crack At Associated Unit Tests
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The change to AWTNewtEventFactory appears to fix the original issue
for AWTCanvas instances, and the TestNewtEventModifiersAWTCanvas
appears to work ok too. However, there are still issues with
NewtCanvasAWT and NewtCanvasSWT instances. These might be problems
in the test code, but there's also a good chance there are still
issues in the NEWT event delivery infrastructure. For the time being
I recommend that only TestNewtEventModifiersAWTCanvas be included
in routine unit tests.
The tests are defined in TestNewtEventModifiers, and the remaining
test classes extend it to define how the window and associated
GL drawing surface are created.
File ModifierMappings.txt is simply informational, and shows how
the modifier bits are laid out between AWT and NEWT. This possibly
should have been a spreadsheet.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GLCanvas.displayOnEDT: Also check null!=drawable
As for 1ae0737f34143a5ed655bd9c4d5fe9b0437c7774, an animator may inject a display Runnable on the EDT
before AWT destruction. In case this Runnable is executed after destruction on the EDT - it would fail.
|
| | |
| | |
| | |
| | | |
ShaderState for share ctor.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GLContextImpl.makeCurrent() - Handle !drawable.isRealized() early, don't catch 'create' Exception
Catching the createImpl() exception could be confusing, since it shall succeed.
Such exception is required to hint a platform bug and to debug it.
Hence testing drawable.isRealized() upfront is preferrable, i.e. catching a well known case
for returning CONTEXT_NOT_CURRENT.
|
| | |
| | |
| | |
| | | |
avoid remove/add of GL component on Window when moving splitter.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GLContext/GLDrawable
- Fix Bug 642 TestJSplitPaneMixHwLw01AWT
On Windows platform when mixing hw/lw JSplitPanel,
the GLCanvas is removed and added when splitter is moved.
The lack of robustness (see below) lead to an exception.
Note: Only w/ GLJPanel (no hw/lw mixing) the splitter can be moved
in both direction. Only here it is guaranteed that the GL component
will survive the action.
- Fix AWT-GLCanvas EDT Runnable: swapBuffer().. / display(..)
- Check drawable.isRealized() within the lock on the performing thread.
This is not possible before issuing the EDT Runnable action
since we cannot hold the lock beforehand.
- Robustness GLDrawableImpl
- boolean realized -> volatile boolean realized
- remove 'synchronized' on isRealized() and setRealized(..)
- Use dbl-checked locking on 'realized' test for swapBuffers() and setRealized(..)
- Robustness GLContextImpl
- Catch createImpl(..) exception and properly return CONTEXT_NOT_CURRENT
|
| | | |
|
| | |
| | |
| | |
| | | |
GL2ES2.GL_MAX_COLOR_ATTACHMENTS
|
| | |
| | |
| | |
| | | |
robost while detecting erroneous queried GL version
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
glGetIntegerv(pname=GL_MAX_TEXTURE_IMAGE_UNITS) ; Add unit test / bisect Mesa3D
This bug lies within Mesa3D (any renderer) and is fixed in
commit 8dc79ae7d73cf6711c2182ff9a5d37ef6c989d23.
Mesa3D Version 9.0 still exposes this bug,
where 9.0.1 has it fixed w/ above commit.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GLU:
jogl-glu.jar <- jogl-glutess.jar, jogl-glumipmap.jar and
javax/media/opengl/glu/*
javax/media/opengl/glu/gl2es1/*
jogamp/opengl/glu/* jogamp/opengl/glu/error/*
jogl-glu-gldesktop.jar stays.
CORE (jogl.core.jar):
+ com/jogamp/opengl/util/*
+ jogamp/opengl/util/*
+ com/jogamp/opengl/util/glsl/*
+ jogamp/opengl/util/glsl/*
DEBUG/TRACE: Removed Debug/Trace pipelines of common profiles (won't work anyways)
- [Debug|Trace]GL2ES1
- [Debug|Trace]GL2ES2
- [Debug|Trace]GL2GL3
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GLDrawableFactory.createOffscreenDrawable(..) for common OffscreenBackend (dropping pbuffer/software); Flip FBO w/ GLSL texture renderer.
- Implementation is GLProfile agnostic
- Shall work on ES2, GL2, .. etc
- Use GLDrawableFactory.createOffscreenDrawable(..) for common OffscreenBackend (dropping pbuffer/software)
- Leave offscreen selection to common factory code, favoring FBO
- Flip FBO w/ GLSL texture renderer
- Faster on low CPU machines
- Enabled if GL2ES2 and FBO offscreen
|
| | |
| | |
| | |
| | | |
missing GLU code
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
operating w/o it; ShaderState: Remove notion of GL context attachment, use pass-through or object association; GLArrayData/GLUniformData: Add basic GLSL location methods
- GLArrayData/GLUniformData: Add basic GLSL location methods
- GLArrayData
- add: setLocation(..) for attribute location/index retrieval (post link) and binding (pre link)
- GLUniformData
- add: setLocation(..) for attribute location/index retrieval (post link)
- GLArrayData/ImmModeSink: Remove implicit dependency on ShaderState - allow operating w/o it
- GLArrayData
- add: 'public void associate(Object obj, boolean enable)', allows setting ShaderState usage
- ShaderState: Remove notion of GL context attachment, use pass-through or object association
- ownsAttribute(..) associates the attribute w/ ShaderState
- removed GL context ShaderState attachment
Tested:
- ImmModeSink w/ GLSL/ES2 w/ and w/o ShaderState
- GLArrayData* w/ and w/o ShaderState
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
getOffscreenContextReadBuffer(), .. ; Add GLFBODrawable API entries for multi buffering (no impl. yet); GLJPanel 1st simplification using offscreen drawable
- Cleanup GLContext special entries: getOffscreenContextPixelDataType(), getOffscreenContextReadBuffer(), .. ;
- add: getDefaultReadBuffer() (-> exposed via GLBase as well)
- add: isGLOrientationFlippedVertical()
- add: getDefaultPixelDataType()
- removed impl: getOffscreenContextPixelDataType()
- removed impl: getOffscreenContextReadBuffer()
- removed impl: offscreenImageNeedsVerticalFlip()
- Add GLFBODrawable API entries for multi buffering (no impl. yet);
- TODO: Add implementation code in GLFBODrawableImpl
- GLJPanel 1st simplification using FBO
- Use above new GL/GLContext entries
- Fix: getNativeSurface() and getHandle()
- TODO:
- Remove distinction of 'pbuffer' and 'software',
- Use GLDrawableFactory.createOffscreenDrawable(..)
- Use GL for FBO swapping
|
| |/
|/| |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
jME3, ticked2ride, jake2 update ..); Cleanup html5.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GLCapabilities on X11 (feature complete)
To allow custom GLCapabilities, we had to use native parenting on X11 w/ a new child window.
The desired visualID chosen by the users GLCapabilities is passed to the new child window.
The redraw drops must be caused by the original GDK or the new child GDK window.
Now we use a plain X11 child window similar to NEWT's X11 window and NewtCanvasSWT,
which doesn't expose this bug.
(Note: SWTAccessor/GLCanvas still contains the uncommented GDK code path for further inspection, if desired)
Also added SWTNewtEventFactory to test event handling on the SWT GLCanvas w/ GearsES2.
TestSWTJOGLGLCanvas01GLn tests custom GLCapabilities now.
SWTEDTUtil has been moved to private: com.jogamp.newt.swt -> jogamp.newt.swt.
|
| |
| |
| |
| | |
successfull claim; Also fix intendations of block.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
remove just introduced setVisible(false) and adapt to setEDTUtil() changes. ; Enhance Bug 643 unit test: Also test NEWT EDT and pre-visible GLWindow.
- SWT GLCanvas/NewtCanvasSWT: Check isVisible() @ validation
- NewtCanvasSWT remove just introduced setVisible(false) and adapt to setEDTUtil() changes
- Enhance Bug 643 unit test: Also test NEWT EDT and pre-visible GLWindow.
|
| |
| |
| |
| | |
Simplify DefaultEDTUtil impl. and fix concurrency leak w/ 'shouldStop'
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
executed on Windows
Turns out that the NEWT Windows impl. didn't properly validated the client region @ WM_PAINT
and hence 'exhausted' the message pipeline, i.e. never reached an IDLE state.
The latter caused SWT to never reach a point where deferred asyncExec(..) Runnables
got processed.
Besides this SWT effect, this also caused a NEWT window on Windows to always repaint itself (?).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
waitForVisible(.., fastFail:=false); waitForSize(..) @ setSize; reparent definePosition(..);
- surfaceLockCount-- if native lock fails
In case native lock fails, not only remove the windowLock but also decr. surfaceLockCount (proper roll back) - was a BUG!
- waitForVisible(.., fastFail:=false)
Don't fail fast if visibility wasn't reached.
- waitForSize(..) @ setSize
Wait for size change - otherwise an SWT child won't reach desired size.
- reparent definePosition(..);
Position might not get updated by WM events (SWT parent apparently)
- Windows WindowDriver: Cleanup code a bit.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
defineSize(..); Don't set persitent undecorated flag if child window at creation; Use local 'screen' directly.
- Don't issue native resize if invisible, simply use defineSize(..)
Invisible windows may not promote size change natively,
hence simply setting the size via defineSize(..) is appropriate.
Latter setVisible(true) will take size into account.
- Don't set persitent undecorated flag if child window at creation
Even if a window is a child at creation, it maybe reparented to top-level
where the default behavior is to be expected.
Undecorated top-level window shall require explicit setUndecorated(true).
- Use local 'screen' directly.
No need to make code more complicate ..
|
| |
| |
| |
| | |
i.e. SWTEDTUtil set and parented; Recognize pending resize.
|
| |
| |
| |
| |
| |
| | |
even if on EDT thread.
DEBUG: Name EDTUtil impl, e.g. Default, AWT and SWT
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NewtCanvasSWT asyncExec(..) bug w/ native parenting
The unit test shows, that while using JOGL's SWT GLCanvas Display's asyncExec(..) works properly,
but w/ NewtCanvasSWT on Windows does not.
NewtCanvasSWT differs w/:
- Using native parenting [Newt GLWindow to SWT Canvas]
- Processing native events in own NEWT EDT, w/ own Windows dispatch hook [For the child GLWindow only]
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
DisposeListener; Run GL tasks on current thread w/o restrictions
Fix dispose bug, check for isDisposed() and add DisposeListener
- Don't issue SWTAccessor.setRealized(..), since it's called implicit via super.dispose()
- Check isDisposed() ..
- add DisposeListener to act on parent's disposal (Shell, Composition, ..)
Run GL tasks on current thread w/o restrictions
+ * The current thread seems to be valid for all platforms,
+ * since no SWT lifecycle tasks are being performed w/ this call.
+ * Only GL task, which are independent from the SWT threading model.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
3.7.1 -> 4.3.0-M3): gtk-freebsd-x86_64 is still on 3.7.1
|