summaryrefslogtreecommitdiffstats
path: root/src/test/com/jogamp
Commit message (Collapse)AuthorAgeFilesLines
* Bug 1422: Emulate DPI Scaling on non-native DPI autoscale platforms (!MacOS)Sven Gothel2020-01-154-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | Bug 1422 shows that it seems to be desired to emulate DPI scaling where the native toolkit does not implmement the same. On GTK, DPIUtil.mapDPIToZoom (int dpi) reads: double zoom = (double) dpi * 100 / 96; int roundedZoom = (int) Math.round (zoom); return roundedZoom; While having dpi calculated as: dpi = 96 * GDK.gdk_monitor_get_scale_factor(monitor); Well, this seems to exist to allow 96 dpi fixed layout to 'look' OK on high-dpi screens. However, you get in trouble if you layout high-dpi aware, i.e. using percentages etc. There is one exception: If DPIUtil.useCairoAutoScale() is true, scalingFactor is 1f and hence the scaling emulation dropped. 'DPIUtil.setUseCairoAutoScale((sx[0]*100) == scaleFactor || OS.isGNOME);'
* TestGLCanvasSWTNewtCanvasSWTPosInTabs: Only use 1 Animator to easy example codeSven Gothel2020-01-151-24/+14
| | | | | Otherwise one would want to pause the Animator instance for the hidden GLWindow, otherwise such animator with zero visible drawables will become a CPU hog.
* Bug 1421: Conclude OSX: Forward SHOW and HIDE events to NewtCanvasSWT ↵Sven Gothel2020-01-151-2/+50
| | | | | | | instances if 'below notification threshold' 'below notification threshold' here is simply being a child SWT Control of like a Composition or SashForm etc where these events won't get propagated.
* NewtCanvasSWT Tests: Add NEWTDemoListener giving weight to toolkit ↵Sven Gothel2020-01-132-0/+21
| | | | independent UI interaction coding
* TestSWTAccessor02NewtGLWindow: Setup SWT EDTUtil for NEWT, avoiding ↵Sven Gothel2020-01-131-38/+30
| | | | | | deadlocks on OSX and Windows Essentially same code path as NewtCanvasSWT
* Bug 1421, Bug 1358, Bug 969, Bug 672: Fix NEWT's coordinate conversion on ↵Sven Gothel2020-01-131-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | MacOS (fixes NewtCanvasSWT on SWT positioning) Newt's OSX Window consist out of NSView wrapped up within its own NSWindow. It's position is being set via its NSWindow's client-area position on screen (frame), which we derive from NSView's client-area position. When NEWT reparents into a new 'window', on OSX it uses the parent's NSView and its NSWindow to attach its own NSView and NSWindow as a subview and childwindow. SWT's OSX implementation uses NSView's for each Compositor, but an individual NSWindow is only established for the Shell (Window). An oversight in Nativewindow and NEWT's coordinate translation: 'top-left view <-> top-left screen' by missing the 'view <-> window' translation caused this whole issue. The oversight occured as NEWT's 'view <-> window' translation had no impact due to its 1-view to 1-window mapping. Fixing the coordinate translation resolves the mess for SWT and for potential other toolkits on OSX. NewtCanvasSWT behaves same on OSX as on X11 etc finally.
* Bug 1421: Tackle wrong position of TabFolder, SashForm etcSven Gothel2020-01-061-44/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | getClientArea() on MacOS produces a 'difficult' result regarding the position, which usually is returned as zero. Using a zero position issues the bug w/ SashForm, where the offset doesn't seems to be covered by the native NSView nor an SWT parent Composition. Then using the getLocation() as is (i.e. the view's frame position) may also cause issues with the TabFolder, as it includes the tab's trimming. Here the native NSView 's position includes the tab's trimming, gladly the parent (TabFolder or a Composition)'s clientArea includes this offset. Therefor, as a testbed - on OSX, getClientArea2(..) returns - position: getLocation() - getParent().getClientArea().position - size: getSize() This at least works OK'sh using - no special layout parent - TabFolder - SashForm ++++ Unit test TestGLCanvasSWTNewtCanvasSWTPosInTabs: Adding 'addComposite' to test matrix. 'addComposite' wraps our GLCanvas or NewtCanvasSWT into a Composite instead of adding it directly into the layouting parent. It demonstrates an issue with the new test 'test32_NewtCanvasSWTTabSashGLWComp', i.e. the NewtCanvasSWT is shown on the left as the SashForm's offset is being dropped. Summary: - No more issues with High-DPI pixelScale observed! - GLCanvas is being most well layouted, no issues in tests - NewtCanvasSWT may show severe positioning issues -> test32_NewtCanvasSWTTabSashGLWComp - NewtCanvasSWT always shows a small positioning offset into the lower-right corner w/ overlapping - NewtCanvasSWT overall positioning is not perfectly understood - NewtCanvasSWT misses to hide the NEWT child when changing tabs in TabFolder
* Bug 1421, Bug 1358, Bug 969, Bug 672: Deleting merged tests (obsolete)Sven Gothel2020-01-062-734/+0
|
* Bug 1421, Bug 1358, Bug 969, Bug 672: Generalization of test case ↵Sven Gothel2020-01-061-110/+389
| | | | | | TestGLCanvasSWTNewtCanvasSWTPosInTabs (2/2) Complete merging unit tests.
* Bug 1421, Bug 1358, Bug 969, Bug 672: Generalization of test case ↵Sven Gothel2020-01-052-69/+118
| | | | | | | | | | | | | TestGLCanvasSWTNewtCanvasSWTPosInTabs (1/2) Testing the TabFolder and a SashForm in the 2nd tab covering both SWT layout use cases on both out SWT support classes SWT GLCanvas and NewtCanvasSWT. Merging TestBug1421NewtCanvasSWTPosInTabs + TestBug672NewtCanvasSWTSashFormComposite into TestGLCanvasSWTNewtCanvasSWTPosInTabs. TestBug672NewtCanvasSWTSashFormComposite exposes that SWT GLCanvas still requires work for proper High-DPI scaling on OSX!
* Bug 1421: NewtCanvasSWT child on layouted SWT parent only occurs on MacOS, ↵Sven Gothel2020-01-051-5/+7
| | | | regardless of High-DPI
* Bug 1421: Demo wrong NEWT Child window position within an SWT TabFolder ↵Sven Gothel2020-01-051-0/+238
| | | | layout using NewtCanvasSWT on MacOSX with High-DPI Retina
* Bug 1393: MacOS: getLocationOnScreen w/ JAWT Parent: Use parent's unblocking ↵Sven Gothel2020-01-021-9/+9
| | | | | | | | | | | | | | | specialization On MacOS, commit 12eed5d38616d23b6e8e2e5b497dfc2f54d90c90 replaced all parent.getLocationOnScreen(..) calls with OSXUtil.GetLocationOnScreen(parentHandle, ..) avoiding the EDT + Appkit Deadlock with native parenting. On MacOS AWT and JAWT are using offscreen CALayer since Java >= 1.7.0, therefor the MacOSXJAWTWindow's native window handle can't be used to gather the screen position via OSXUtil. However, the JAWT Window specialization MacOSXJAWTWindow implements a non-locking code-path and we can decide to use it by querying the general interface OffscreenLayerOption.
* Bug 1312: GLContextShareSet: Utilize WeakIdentityHashMap for shareMap and ↵Sven Gothel2019-12-313-5/+282
| | | | | | | | | | | | its destroyedShares Picking up Tom Nuydens suggestion to utilize a WeakIdentityHashMap instead of a IdentityHashMap, allowing destroyed GLContext to be removed from the GLContextShareSet through the GC. TestSharedContextVBOES2NEWT5 demonstrates the use-case, having one master context and several slaves being spawn off, killed and new sets to be spawn off. Here the GLContextShareSet shall not hard-reference the destroyed and user-unreferenced context, but allowing the system to GC 'em.
* Gears* tests: Obey verbose flagsSven Gothel2019-12-312-16/+41
|
* Bug 1156 Regression (Bug 1417): Probe whether 'eglGetPlatformDisplay(..)' is ↵Sven Gothel2019-12-251-0/+1
| | | | | | | | | | | | | | | | | | available before using commit f4281b5ee80d7674134bfee357695a98382884a3 for Bug 1156 (DRM/GBM) introduced the call to 'eglGetPlatformDisplay(..)' for known EGL-platforms. However, 'eglGetPlatformDisplay(..)' is only available for EGL versions >= 1.5 or 'eglGetPlatformDisplayEXT(..)' if EGL extension 'EGL_EXT_platform_base' is available. This patch adds a singular EGL version probe and a secondary extension fallback test at first call using EGL_NO_DISPLAY on both EGL_VERSION and EGL_EXTENSION eglQueryString(..) calls. If 'eglGetPlatformDisplay*(..)' is not available, simply use 'eglGetDisplay(..)'. This regression also impacted Bug 1417 (Android bringup using current SDK + NDK), i.e. disabled most Android devices as their EGL version is often 1.4.
* Bug 852: TestCPUSourcingAPINEWT Reference the bug entry and add a little ↵Sven Gothel2019-12-091-0/+5
| | | | reminder
* Bug 1416 - Allow EGLDrawableFactory re-creation after shutdown() - be functionalSven Gothel2019-12-093-5/+35
| | | | | | | | | | TestShutdownCompleteNEWT revealed that EGLDrawableFactory won't be properly re-created within subsequent GLProfile/GLDrawableFactory initSingleton() after a GLProfile.shutdown() call. Hence after the shutdown() call, subsequent GLProfile have no EGLDrawableFactory available and hence may not have a default device existent in case no desktop-factory is available. Allow EGLDrawableFactory to be re-created after a shutdown().
* Bug 1156: NEWT Window: Better handling of fixed console case: Not resizable ↵Sven Gothel2019-12-091-2/+8
| | | | | | | | | | | | | | | | | | | | | | | and not repositionable. Our two fixed size and position console cases 'bcm.egl' and 'egl.gbm' (drm.gbm) only operate in a console like fullscreen mode. We should earmark and expose this behavior, as well as handle it by not waiting for a position / size and not attempting to change position and size. Reducing WindowImpl.minimumReconfigStateMask to bare minimum values: STATE_MASK_VISIBLE | STATE_MASK_FOCUSED; New WindowImpl.mutableSizePosReconfigStateMask extends WindowImpl.minimumReconfigStateMask, representing previous values: STATE_MASK_VISIBLE | STATE_MASK_FOCUSED | STATE_MASK_FULLSCREEN | STATE_MASK_RESIZABLE | STATE_MASK_REPOSITIONABLE; All WindowDriver implementations previously using WindowImpl.minimumReconfigStateMask are now using WindowImpl.mutableSizePosReconfigStateMask but the explicit console driver named above. I would have liked to add the STATE_BIT_FULLSCREEN to the current stateMask to notify this semantics, however this would have lead to more code changes as our fullscreen mode assumes to be 'on top' of the normal mode. Here the normal mode is essentially fullscreen and no back/forth fullscreen setting is useful or allowed. Therefore, both fixed size & position console driver won't expose themselves as being in fullscreen mode.
* Bug 1415: MacOS: Disable multiple Window creation on ExclusiveContextThread ↵Sven Gothel2019-12-082-0/+15
| | | | in test case
* Bug 1415: ExclusiveContextBase00+10: Utilize one Animator per Window for ↵Sven Gothel2019-12-082-185/+248
| | | | | | | clean ExclusiveContextThread No, this does not resolve the issue - but is the proper test case. ExclusiveContextBase10 also gets the preVis test.
* Bug 1393: Make window position check more tolerant (2x insets or 64 pixels, ↵Sven Gothel2019-12-083-14/+33
| | | | | | | | | | | whichever is greater) Certain WM's may modify the windowing position 'a little', which has been experienced on one X11 server during invisible setting. The insets were removed and its value added to the position! We could argue that this is an issue in our windowing code, however, the WM is free to reposition a window. Refines commit b8db98376069a72ad40b7ef2fe2d9003aea2b091
* Bug 1406: demos.Launcher0: More code path reduction: useMultiplePointerIcon ↵Sven Gothel2019-12-041-1/+1
| | | | must be enabled via -pointerIcon
* Bug 1393: MacOS: Wait for window position setting on main-thread (blocking)Sven Gothel2019-11-211-1/+1
| | | | Also issue the orderFront0 call within createWindow1 (aligned with IOS code)
* Bug 1393: Adding test cases setting visibility before enabling exclusive ↵Sven Gothel2019-09-161-18/+78
| | | | | | | | | context thread animator MacOS Java11 freezes occur on 3rd NEWT window creation (orderFront) after enabling exclusive context thread animator. Here we add set visibility upfront which does not trigger the freeze on the AppKit main thread. Note: OpenJDK8 works flawlessly. For some reason, the exclusive context thread enabled animator interferes when 'orderFront' is issued.
* Bug 1393: Add window position validation in TestDisplayLifecycle*NEWTSven Gothel2019-09-112-15/+45
| | | | | | | | The OSX fixes for bug 1393 spun off certain tasks like position/size gathering async to AppKit, hence we should validate whether both are valid. Further the TestDisplayLifecycle02NEWT had one bug, it retrieved 'screen.getViewportInWindowUnits()' while it was not yet initialized.
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 15:30:02 +0000