aboutsummaryrefslogtreecommitdiffstats
path: root/src/test
Commit message (Collapse)AuthorAgeFilesLines
* Bug 1393: Run orderFront0(=setVisible) async off-thread on AppKit after sync ↵Sven Gothel2019-09-091-2/+10
| | | | | | | | | | | | | | | | | AppKit NSWindow creation MacOS 10.14.6 + OpenJDK11U produces occasional freezes on AppKit Main Thread Latest manual tests after resolving Bug 1389 disclosed a few occasional freezes using NEWT + Java11. These are related to probable AWT changes since Java8, as these do not occur with Java8. Fix: Spun off orderFront0(=setVisible) async off-thread on AppKit after sync AppKit NSWindow creation. This fix also aligns the macos createWindow code with the new simplified ios implementation, see commit 004c67c73a0309158c30929cd0d6513e23f34803
* Buig 1389: Fix SIGSEGV on OpenJDK11 on [NSApplicationAWT sendEvent:]Sven Gothel2019-09-081-5/+1
| | | | | | | | | | | | | | | | | | | | | | Culprit of the crash and the non propagated action on NSApp main-thread was _simply_ our OSXUtil_KickNSApp() 'kick alive' NSApplicationDefined NSEvent sent to the NSApp. Java11's NSApp code overrides sendEvent and handles NSApplicationDefined + subtype=ExecuteBlockEvent using the given data1 as a function pointer. 8-O ExecuteBlockEvent defined as 0, which we have sent. Simply passing subtype=8888 avoids this side-effect. Whether it is still required to KickNSApp() is another question. +++ Further, make code a bit more robuts regarding the offscreenSurfaceLayer at JAWTWindow invalidate. I.e. if still not detached, do the late cleanup there. This just in case the OSX Context callback to disassociate the drawable has been missed.
* Bug 1391 Bug 1392: Implement GLRendererQuirks DontChooseFBConfigBestMatch ↵Sven Gothel2019-09-072-34/+82
| | | | | | | | | and No10BitColorCompOffscreen Further enhance unit tests TestGLProfile03NEWTOffscreen, i.e. test all meta profile types on all offscreen drawable types (fbo, pbuffer and bitmap). Align unit test name numbers of TestGLProfile01NEWT to TestGLProfile03NEWTOffscreen.
* NEWT iOS: Support Multi-Touch Events, PixelScale, ..Sven Gothel2019-07-081-1/+1
| | | | | | | | | | | | | | | | | Note: Two subsequent commit will add some required change in the native UIWindow/UIView creation methods to actually make the NEWT view being displayed ;-) The demo 'com.jogamp.opengl.demos.ios.Hello' demonstrated a standard NEWT application running on iOS. Previous NativeWindow wrap-around demo is preserved in 'com.jogamp.opengl.demos.ios.Hello1'. Tested on ipad 11'inch arm64 and x86_64 simulation: - Using GearsES2 demo - PixelScale 1f, 2f and 0f - last two using max pixel scale - Touch w/ GearsES2 works: -- 1 finger rotate -- 2 finger drag -- 2 finger pinch-zoom gesture detection
* iOS: Initial working commit supporting iOS (ipad pro 11)Sven Gothel2019-06-2311-95/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | using our OpenJFK 9 x86_64 and arm64 build. Test demo class is 'com.jogamp.opengl.demos.ios.Hello', residing in the new demo folder 'src/demos/com/jogamp/opengl/demos/ios/Hello.java'. This commit does not yet include a working NEWT specialization for iOS, but it shall followup soon. Instead this commit demonstrates JOGL operating on native UIWindow, UIView and CAEAGLLayer as provided by Nativewindow's IOSUtil. Test Video https://www.youtube.com/watch?v=Z4lUQNFTGMI +++ Notable bug: The FBO used and sharing the COLORBUFFER RENDERBUFFER memory resources with CAEAGLLayer to be displayed in the UIView seemingly cannot handle GL_DEPTH_COMPONENT16, GL_DEPTH_COMPONENT24 or GL_DEPTH_COMPONENT32 depth buffer - none at all (Device + Simulation). Therefor the default demo GLEventListener chosen here don't require a depth buffer ;-) This issue can hopefully be mitigated with other means than using a flat FBO sink similar to FBO multisampling.
* AWTRobotUtil Cleanup: Use specific argument types (AWT, NEWT, ..)Sven Gothel2019-04-1041-208/+197
| | | | | | | Most fixed, some marked as FIXME left still .. Also fixed AWTRoboUtil regression of last commit(s), where AWTRobotUtil.addClosingListener(..) called to itself causing a StackOverflowError.
* Bug 1362: Final general lifecycle fixes of unit testsSven Gothel2019-04-104-36/+79
| | | | | | | SWT unit tests must wait while issuing 'display.readAndDispatch()' so essential event dispatching won't get blocked. Previous AWTRobotUtil cleanup and these patches ensure proper lifecycle checks.
* Cleanup AWTRobotUtil ..: Add 'Runnable waitAction' also to waitForFocus and ↵Sven Gothel2019-04-1032-163/+207
| | | | closeWindow, etc ..
* Cleanup AWTRobotUtil 3: TestUtil.WindowClosingListener must be publicSven Gothel2019-04-091-1/+1
|
* Cleanup AWTRobotUtil 2: Align signatures of waitForVisible(..) and ↵Sven Gothel2019-04-0995-447/+452
| | | | waitForRealized(..)
* Cleanup AWTRobotUtil: Extract GLTestUtil + NewtTestUtil; all three based on ↵Sven Gothel2019-04-0932-287/+536
| | | | TestUtil
* Bug 1362: Minimal action required: setBackground of the parent canvas before ↵Sven Gothel2019-04-091-12/+2
| | | | | | | reparenting! Bug 1362 fix or workaround: Seems SWT/GTK3 at least performs lazy initialization Minimal action required: setBackground of the parent canvas before reparenting!
* Bug 1362: Minimal action required: setBackground + fillRectangle of some ↵Sven Gothel2019-04-091-5/+9
| | | | | | | space in canvas ONCE before reparenting! Bug 1362 fix or workaround: Seems GTK3 at least performs lazy initialization Minimal action required: setBackground + fillRectangle of some space in canvas ONCE before reparenting!
* Bug 1362: TestSWTAccessor02NewtGLWindow demonstrates a fix by letting the ↵Sven Gothel2019-04-091-0/+11
| | | | | | | | | | | | | Canvas PAINT! This commit shows the very little change set required to allow working on SWT >= 4.10 + GTK3, i.e. adding the PAINT listener to Canvas and letting it paint. Almost too ridiculous? I stumbled over it by creating this test in the first place when copying the 01 test -> 02 and adding the native parenting. Possible explanation: The parent Canvas may need to paint once at least due to some lazy initialization within SWT or GTK3?!
* Bug 1362: Unit tests: Report SWT and GTK VersionSven Gothel2019-04-092-0/+4
|
* Bug 1362: Add two self contained unit tests to validate SWT >= 4.10 + GTK3 ↵Sven Gothel2019-04-092-0/+447
| | | | | | | | | | | | | issues TestSWTAccessor01: Simply tests SWTAccessor's returned native window handle. Works on SWT + GTK2 and SWT + GTK3. TestSWTAccessor02NewtGLWindow: Uses same returned native window handle and tests a GLWindow.reparentWindow(..) operation all rolled out and implemented here ad-hock (comparable to NewtCanvasSWT). This shall allow simplified debugging. Testing: - SWT + GTK2: Works - SWT + GTK3: Bug reproduced
* TestVersionSemanticsNOUI: Adapt to upcoming NON_BACKWARD_COMPATIBLE version ↵Sven Gothel2019-04-031-50/+2
| | | | 2.4.0
* Bug 1366 - Use String.format((Locale)null, "..." ..) avoiding Locale output ↵Sven Gothel2019-03-308-9/+17
| | | | for System related Operations
* NewtCanvasJFX.NativeWindow: Delegate required child window canvas positionSven Gothel2019-03-214-74/+15
| | | | | | | | | | NewtCanvasJFX.NativeWindow shall pass through NewtCanvasJFX's Canvas position to properly position the NEWT child window inside the top level Window. NewtJFXReparentingKeyAdapter demonstrating manual reparenting demonstrates this case. TestGearsES2NewtCanvasAWT's default behavior is to use a surrounding border for the NEWTCanvasAWT child, similar to TestNewtCanvasJFXGLn.
* TestNewtCanvasJFXGLn: Adding NEWTDemoListener and ↵Sven Gothel2019-03-201-0/+34
| | | | NewtJFXReparentingKeyAdapter functionality
* Tests: Adding API Doc for test utilizing NEWTDemoListener and derivationsSven Gothel2019-03-208-14/+84
|
* Adding NativeWindowHolder extends NativeSurfaceHolder; API Doc for ↵Sven Gothel2019-03-203-22/+238
| | | | | | | | | NEWTDemoListener NativeWindowHolder abstracts access to is-a or has-a parent component's NativeWindow like NewtCanvasAWT, NewtCanvasJFX and NewtCanvasSWT Adding API Doc for NEWTDemoListener.
* JavaFX: Add proper class doc for implementation and unit testSven Gothel2019-03-201-32/+52
|
* JavaFX: Adding JavaFX Support for NEWT utilizing native Window parenting via ↵Sven Gothel2019-03-192-0/+516
| | | | | | | | | | | | | | | | | | | | | NewtCanvasJFX NewtCanvasJFX, a JavaFX Canvas Node, allows attaching a native NEWT Window to the JavaFX Node's native Window (if attached). The mechanism is similar to NewtCanvasAWT. Current implementation supports placing the NEWT Window into the JavaFX scene of the native window correctly, as well as the following different lifecycles - attach NewtCanvasJFX to already visible group->scene->window - attach NewtCanvasJFX to not yet visible or attached group->scene->window - attach NEWT Window before or after NewtCanvasJFX's visibility The above is covered by unit test: TestNewtCanvasJFXGLn This is the initial commit for JavaFX support and has been tested on - OpenJDK 8 + OpenJFX 8 - GNU/Linux X11
* Version Semantics Test: Bump for 2.4.0 -> 2.3.xSven Gothel2018-01-151-4/+4
| | | | We are still on the 2.3.x branch for the next release
* TestGearsES2NEWT: Adding programmatic Debug|Trace pipelineSven Gothel2015-10-121-0/+37
|
* Version Semantics Test: Bump for 2.3.2 -> 2.4.xSven Gothel2015-10-121-2/+40
|
* Bug 1249: Revert TestParenting01NEWT durationPerTest back to 600 (otherwise ↵Sven Gothel2015-10-091-1/+1
| | | | breaks test)
* Bug 1249 - NEWT X11: setVisible(*) _NET_WM_STATE_HIDDEN update not received ↵Sven Gothel2015-10-092-53/+89
| | | | | | | | | | | | | | | | | | | | | | at ConfigureNotify event (2) On gnome shell WM, sometimes KDE WM, it has been observed that the _NET_WM_STATE_HIDDEN update (visible or invisible) is not received at ConfigureNotify event. Turns out the state is finally updated at FocusOut! This change tests _NET_WM_STATE_HIDDEN visibility hint for mapped window also for FocusIn and FocusOut events, besides the ConfigureNotify event. Further more, NormalState to restore a hidden but mapped window did not work, so it is no more being sent. We limit us here to _NET_ACTIVE_WINDOW. 2 unit tests are prepared to test this issue: - TestGLWindows00NEWT - TestParenting01NEWT
* Bug 1249 - NEWT X11: setVisible(false) IconicState not listening to ↵Sven Gothel2015-10-083-103/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _NET_WM_STATE_HIDDEN; setVisible(true) not restoring from _NET_WM_STATE_HIDDEN Using Gnome Shell 3.14.4-1~deb8u1 disclosed an issue w/ our newly utilized IconicState/_NET_WM_STATE_HIDDEN, i.e. visibleChanged(false) was never received. This is a regression of commit 2d837a7a7130702ad36b694875613fae77c7ef06, which utilizes WM_CHANGE_STATE_IDX + IconicState for visibility on top-level windows. This bug consist out of _two_ isssue: 1) setVisible(false) IconicState not listening to _NET_WM_STATE_HIDDEN Here, we 'listen' to _NET_WM_STATE_HIDDEN when receiving ConfigureNotify if supported _and_ XMapWindow has been issued. In such case existence/non-existence of _NET_WM_STATE_HIDDEN determines visibility. Otherwise, we have wait for MapNotify/UnmapNotify. The 'XMapWindow has been issued' criteria is tracked by new field 'JavaWindow.isMapped' and set/cleared when we actually issue XMapWindow/XUnmapWindow! 2) setVisible(true) not restoring from _NET_WM_STATE_HIDDEN It has been observed that restoring IconicState/_NET_WM_STATE_HIDDEN via XMapWindow or even NormalState may not work reliably on WMs. See <https://stackoverflow.com/questions/30192347/how-to-restore-a-window-with-xlib> Hence we restore from this WM state via NormalState _and_ _NET_ACTIVE_WINDOW. Both strategies seem to work well on KDE as well as on Gnome.
* Bug 1223: Add '-traceMouse' commandline argument to check whether mouse ↵Sven Gothel2015-10-051-0/+8
| | | | events are still received after manual maximize
* Merge remote-tracking branch 'xranby/junit'Sven Gothel2015-10-052-2/+2
|\
| * Fix: junit/jogl/awt/TestBug1225EventQueueInterruptedAWT and ↵Xerxes Rånby2015-10-042-2/+2
| | | | | | | | | | | | | | junit/jogl/util/texture/TestTextureIONEWT replacing import junit.framework.* with import org.junit.* fixed the "Stub!" Exception seen when runing the junit tests from inside Eclipse
* | Bug 1206 - Security: Clear exposed framebuffer after creation and before ↵Sven Gothel2015-10-053-8/+98
|/ | | | | | | | | | | | | | | | | | | | | | | | | visibility Experimenting w/ no GLEventListener attached to an GLAutoDrawable, e.g. GLWindow (onscreen), GLJPanel (fbo offscreen), indeed on some GL implementations the default framebuffer is uninitialized and hence shows garbage. GLDrawableHelper.setViewportAndClear(..) - Clear framebuffer after setting viewport - Called from: - public final void init(..) - public final void reshape(..) - Method is used independent of GLEventListener, hence this simplifies implementation: removes 'setViewport' criteria for init, display, reshape: it is always performed! Note: We only attempt to help against leaking un-initialized framebuffer content not against user-app faults, we do not clear a 2nd-buffer (double-buffering). Note: We may still be late at resize, i.e. small noisy flickering might be visible. This might be due to lack of proper vsync.
* Bug 1245: Adding Unit Test, similar to ↵Sven Gothel2015-10-042-9/+251
| | | | | | | | | | | | TestBug816JTabbedPanelVisibilityB849B878AWT TestBug1245JTabbedPanelCrashAWT passed as expected on GNU/Linux, Debian8, amd64 w/: - proprietary NV - GL_RENDERER = Gallium 0.4 on AMD ARUBA GL_VERSION = 3.0 Mesa 10.3.2 GL_VENDOR = X.Org
* Merge remote-tracking branch 'xranby/master'Sven Gothel2015-10-031-1/+2
|\
| * Fix: ↵Xerxes Rånby2015-10-031-1/+2
| | | | | | | | | | | | | | | | | | | | com.jogamp.opengl.test.junit.jogl.acore.TestGLProfile04NEWTOffscreenNoARBCtx java.lang.AssertionError: Property 'jogl.disable.openglarbcontext' set, but created w/ ARB at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertFalse(Assert.java:64) at com.jogamp.opengl.test.junit.jogl.acore.GLProfile0XBase.validateOnlineOffscreen(GLProfile0XBase.java:920)
* | Bug 1206: Test TestGearsES2NEWT: Versatile 'demoType' allows also no ↵Sven Gothel2015-10-031-6/+12
| | | | | | | | GLEventListener at all
* | Bug 1244: MovieSimple: String format %d implicit conversion from boolean to ↵Xerxes Rånby2015-10-031-1/+1
|/ | | | | | int fails using OpenJDK 1.8 Replace %d with %b
* Bug 1237: Adopt GlueGen's clarification of IOUtil.getResource(..), commit ↵Sven Gothel2015-10-0319-63/+63
| | | | | | | | d78bb1be0a6290cb94918b21865a023c01825048 - Skip relative lookup for IOUtil.ClassResources using 'asset' only (from JAR file) - Tested w/ jar file and build-dir, see scripts/tests.sh 'USE_BUILDDIR'
* Bug 1225: Unit test shall not fail if AWT is not alive, simply report and ↵Sven Gothel2015-09-291-2/+5
| | | | return - assume failure is recorded
* Bug 1225: Unit test timeout := 3minutesSven Gothel2015-09-291-2/+2
|
* Bug 1225: Unit test shall not fail if AWT is not alive, ignore it via assumeSven Gothel2015-09-291-1/+3
|
* Bug 1225: Make unit test more robuts, notify if JRE 1.7.0 issue w/ ↵Sven Gothel2015-09-281-51/+119
| | | | | | | | | | interrupted AWT-EDT The reporter claims that an interrupt on the AWT-EDT shall not disturb neither AWT nor JOGL's GLCanvas and rendering shall continue. - This seems to be true for JRE 1.8.0_60 - This seems to be false for JRE 1.7.0_45. This JRE's AWT-EDT even dies occasionally when interrupted.
* Bug 1125: Unit test to validate that Thread.interrupt() does not disturb ↵Sven Gothel2015-09-281-0/+305
| | | | continued rendering of AWT and GLCanvas
* TestGearsES2NEWT: Print bounds @ window resized/moved instead of just x/ySven Gothel2015-09-261-2/+2
|
* Bug 1223 OSX: GLWindow loses focus after maximizing - AnalysisSven Gothel2015-09-261-0/+32
| | | | | | | | | | | | | TestGearsES2NEWT reacts on key-press 'n', opening another GLWindow. Procedure: [1] Pressing 'n' (2nd GLWindow) and manual re-focus 1st GLWindow [2] Pressing 'm' (single, alt, shift) on 1st GLWindow maximizes it Focus is still on 1st GLWindow! [3] Pressing ctrl-m un-maximizes .. Focus is still on 1st GLWindow!
* Bug 1214: Fix Deadlock in screenPositionChanged(..); Use ↵Sven Gothel2015-09-261-14/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | screenPositionChanged(..) in size[Screen]PosInsetsChanged(..) on OSX; Cleanup OSX Code - Fix Deadlock in screenPositionChanged(..) Defer requires to spawn whole child-window action to another thread since we may come from native 'NewtWindow::windowDidMove()' on MainThread. - Use screenPositionChanged(..) in size[Screen]PosInsetsChanged(..) on OSX Move callback WindowImpl::sizePosInsetsChanged(..) to OSX's WindowDriver::sizeScreenPosInsetsChanged(..), since we need to use screenPositionChanged(..) to calculate child window relative position to parent. I.e. we receive the location on screen. - Cleanup OSX Code - Native JNI entries shall handle NULL windowHandle -> return - Clarify usage of 'getWindowHandle()' and use 'isNativeValid()' if appropriate. - Don't re-use cached getWindowHandle() for non-blocking off-thread actions, since handle may become invalid. - Clarify getLocationOnScreen*(..) implementation code, i.e. separate getLocationOnScreenByParent(..) semantics.
* Bug 1214 - NEWT MacOSX: Detect auto-resize of Window when it is larger than ↵Sven Gothel2015-09-252-4/+203
| | | | | | | | | | | screen - On OSX (similar to X11) a created window with size > screen will get resized to fit screen size implicitly. - Fix detects insets, position and size after onscreen window creation. - Patch also merges insets and size change java callback
* TestGearsES2*AWT / NewtDemoListener: Show pixel-scale in title bar.Sven Gothel2015-09-182-39/+163
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 14:32:57 +0000