aboutsummaryrefslogtreecommitdiffstats
path: root/make
Commit message (Collapse)AuthorAgeFilesLines
...
* Bug 1362: Test against SWT 4.3 and 4.11Sven Gothel2019-04-052-3/+5
| | | | | 4.3 is still working w/ GTK2 4.11 is not working as described by Wade
* Bug 1362: build/test: Use new SWT 4.10 swt.jar (instead of swt-debug.jar)Sven Gothel2019-04-0512-25/+34
|
* Bug 1362: Replace SWT 4.3.0 -> 4.11.0Sven Gothel2019-04-0546-7035/+839
| | | | | | https://download.eclipse.org/eclipse/downloads/drops4/R-4.11-201903070500/ This binary make/lib drop is only required for build and unit tests.
* Bug 1370: Call from Main-Thread: NW's OSXUtil.CreateNSWindow0(..) and NEWT's ↵Sven Gothel2019-04-052-4/+4
| | | | | | | | | | | | | | | | | | | | | | WindowDriver.createWindow0(..) OSX 10.14.3 Mojave issues a WARNING: NSWindow drag regions should only be invalidated on the Main Thread! This will throw an exception in the future. The complaint about NativeWindow (NW)'s OSXUtil.CreateNSWindow0(..) might be valid, which does create a NS Window instance w/ NSView and framebuffer initialized. However, the complaint about NEWT's WindowDriver.createWindow0(..) is not, since the initialization incl framebuffer happened later on the main thread. Regardless, encapsulated both construction fully to run on the Main-Thread. +++ Originally the Main-Thread design spec was like: Must run on Main-Thread when or after making visible. Oh well.
* TestVersionSemanticsNOUI: Adapt to upcoming NON_BACKWARD_COMPATIBLE version ↵Sven Gothel2019-04-031-2/+2
| | | | 2.4.0
* Windows scripts: Use JDK/JRE 1.8.0_121Sven Gothel2019-04-039-27/+27
|
* Bug 1316: MacOSX: Keep *.dylib (Don't move to *.jnilib)Sven Gothel2019-03-304-53/+9
| | | | | | | | Since Java8 (or even earlier), JRE on OSX uses *.dylib native library suffix instead of *.jnilib when automatically searching and loading them. This is not easily being recognized by JogAmp, since we explicitly name the native libraries with full path when testing with our TempJarCache.
* Bug 1348: Fix X11 XI MultitouchSven Gothel2019-03-271-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I got access to a touchscreen laptop w/ Debian 9, hence I could fix and test the implementation. X11 DisplayDriver.java: - Store and pass through xi_opcode of XI extension, queried at initialization stage X11Window.c Fixes: - Initialize JavaWindow's xiTouchCoords[].id w/ -1, as required to track the pointer - Pass through xi_opcode as stored in X11 DisplayDriver X11Display.c Fixes: - sendTouchScreenEvent: Throw RuntimeException if 0 > actionId (Internal Error: based on xiTouchCoords[].id tracking) - DispatchMessages's windowPointer determination: -- Query potenial XI Event first: IF XI Event, must use XIDeviceEvent's event Window -- Only IF not an XI Event, we can use evt.xany.window as the event window - DispatchMessages's XI Event Handling: -- Always break deviceid search loop if id found, preserving index and time spend Works on my Debian 9 device, tested w/ com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT: - One pointer (finger) press, drag and release (click) - PinchToZoomGesture works - DoubleTabScrollGesture works +++ Potential Issues: JavaWindow's xiTouchCoords[].id accuracy is crucial to pointer tracking during XI_TouchBegin -> XI_TouchUpdate -> XI_TouchEnd. In the normal course of action: - XI_TouchBegin sets the id, assuming it is yet set - XI_TouchUpdate assumes it is set - XI_TouchEnd clears the id, assuming it is set This field in the JavaWindow array only gets reset to -1 once at native window creation. We may need to figure out when to reset this field to -1. If the XI_TouchEnd events would get lost for whatever reason, the above tracking state would be broken.
* Bug 1348: X11 XI Multitouch: Fixes of previous commit ↵Sven Gothel2019-03-272-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 92006e4baef57f1f3fb647dd307aed5989fd4c8d Previous commit 92006e4baef57f1f3fb647dd307aed5989fd4c8d (Note to Danny: I cannot test this now - please re-test and/or review) X11Common::JavaWindow - Owns XI extension's xiOpcode, selected xiTouchDeviceId and tracked XITouchPosition array X11Window::CreateWindow - Query XI extension only once @ window creation and earmark xiOpcode in JavaWindow instance - Fix: Device selection code was "class->type != XITouchClass", but shouldn't it be 'XITouchClass == class->type' (as patched here) - Fix: Free XIQueryDevice returned XIDeviceInfo array via XIFreeDeviceInfo - Earmark deviceid in JavaWindow instance X11Display - Moved global static touch_coordinates to JavaWindow::xiTouchCoords instance X11Display::DispatchMessage - Changed event handling structure similar to https://keithp.com/blogs/Cursor_tracking/ - Fix: Free XGetEventData's optional memory allocation via XFreeEventData - Reuse JavaWindow's queried xiOpcode - Fix: Don't overrise windowPointer, instead validate and require a match. JavaWindow must match! - Fix: Also validate chosen deviceid with JavaWindow's registered device Newt Build: - Added libXi in build recipe and doc
* Bug 1283: Remove shader include filename quotes if exists at start and end onlySven Gothel2019-03-261-4/+4
|
* NewtCanvasJFX: Utilize JFXEDTUtil per default, supporting the Windows PlatformjavafxSven Gothel2019-03-211-0/+2
| | | | | | | | | | | | | On [GNU/Linux] X11 JFXEDTUtil is not required, since X11 can handle multi-threaded native parenting, however, the Windows platform does require JFXEDTUtil. Currently the default is to use JFXEDTUtil, which operates solely on the JavaFX thread for windowing lifecycle and even-dispatch operations. This behavior can be toggled via the boolean property 'jogamp.newt.javafx.UseJFXEDT', which currently defaults to 'true' This behavior might be analyzed in more detail for a fine grained EDTUtil decision.
* JavaFX: Preliminary testing on WindowsSven Gothel2019-03-202-2/+5
|
* JavaFX: Adding JavaFX Support for NEWT utilizing native Window parenting via ↵Sven Gothel2019-03-194-4/+37
| | | | | | | | | | | | | | | | | | | | | 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
* osx test scripts using latest JavaSven Gothel2019-01-232-2/+5
|
* Merge remote-tracking branch 'remotes/xranby/www'Sven Gothel2018-01-152-3/+3
|\
| * make/doc/jogl/spec-overview.html, make/config/jogl/gl-common.cfg: OpenGL ES ↵Xerxes Rånby2015-10-202-3/+3
| | | | | | | | 3.1 -> 3.2
* | Bug 1295: Add linux-aarch64 GNU/Linux AArch64 supportXerxes Rånby2016-12-122-0/+42
| | | | | | | | | | | | | | | | scripts/make.jogl.all.linux-aarch64-cross.sh: New crosscompile script build-common.xml: Add SWT compile hack for isLinuxARM64
* | Bump scripts to jre1.8.0_66Sven Gothel2015-11-169-17/+19
|/
* Cleanup IgnoreExtension for GL3 and GL4 exclusive extensionsSven Gothel2015-10-122-1/+17
|
* TestGearsES2NEWT: Adding programmatic Debug|Trace pipelineSven Gothel2015-10-121-4/+4
|
* Streamline GL* profile interfaces and implementationsSven Gothel2015-10-123-20/+22
| | | | | Only add the required direct interfaces / implementations to interface / class derivations, not polluting overview in IDEs.
* Drop Vendor Extensions: INGR and PGI for all profilesSven Gothel2015-10-121-2/+2
|
* Version Semantics Test: Bump for 2.3.2 -> 2.4.xSven Gothel2015-10-121-0/+0
|
* Bug 1249: NEWT/X11 Visibility: Listening to more events for updated state; ↵Sven Gothel2015-10-101-3/+6
| | | | | | | | | | | | | | | | | Adding QUIRK_BIT_VISIBILITY 1) More visibility detection on post ConfigureNotify events, since the latter may not yet contain the updated visibility state as it whould (WM bug!): - EnterNotify - LeaveNotify - Disabled - Expose - VisibilityNotify 2) Introducing quirks. Setting QUIRK_BIT_VISIBILITY to handle the issue where visibility -> false could not even be set.
* Bug 1247 - TestGearsNewtAWTWrapper fails AWT recreation case removeNotify -> ↵Sven Gothel2015-10-091-3/+3
| | | | | | | | | | | | | | | | | | addNotify, e.g. by moving to other monitor AWTCanvas removeNotify didn't cause 'local' destruction of the NEWT window, allowing a 'recreate' w/ subsequent addNotify. This case has been hacked-into NEWT.AWT.WindowDriver + AWTCanvas: - suppression of window destroy events - keeping fields/states intact in NEWT.AWT.WindowDriver - propagating signals appropriately Note: This is barely a working hack and not a fine piece of software :) This AWT backend driver exists only due to historical reasons. This hack simply proves that JAWTWindow works properly.
* Bug 1249: Revert TestParenting01NEWT durationPerTest back to 600 (otherwise ↵Sven Gothel2015-10-091-2/+2
| | | | breaks test)
* Bug 1249 - NEWT X11: setVisible(*) _NET_WM_STATE_HIDDEN update not received ↵Sven Gothel2015-10-091-1/+8
| | | | | | | | | | | | | | | | | | | | | | 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-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _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 1189: Fix gcc redefinition error, even thought typedef equals - on ↵Sven Gothel2015-10-081-0/+4
| | | | OpenIndiana w/ old'ish gcc
* Bug 1189 - Add OpenGL ES 3.2 and new GL 4.5 Extensions support - Part5: ↵Sven Gothel2015-10-073-0/+15
| | | | GL_ARB_ES3_2_compatibility -> [GL|GLContext].isGLES32Compatible()
* Bug 1189 - Add OpenGL ES 3.2 and new GL 4.5 Extensions support - Part4: Fix ↵Sven Gothel2015-10-071-2/+2
| | | | GLNameResolver: Add all known vendor extensions
* Bug 1189 - Add OpenGL ES 3.2 and new GL 4.5 Extensions support - Part2: ↵Sven Gothel2015-10-0711-12/+83
| | | | | | | | | | | | | | | | | | | | | | | | | Update gluegen configs +# +# Ignored new extensions added in gl2ext.h 2015-10-06 +# see jogl/make/scripts/diff-gl2ext.sh +# FIXME: Refine for 2.4.0 +# +IgnoreExtension GL_KHR_no_error +IgnoreExtension GL_EXT_YUV_target +IgnoreExtension GL_EXT_blend_func_extended +IgnoreExtension GL_EXT_buffer_storage +IgnoreExtension GL_EXT_color_buffer_float +IgnoreExtension GL_EXT_float_blend +IgnoreExtension GL_EXT_multisampled_compatibility +IgnoreExtension GL_EXT_post_depth_coverage +IgnoreExtension GL_EXT_raster_multisample +IgnoreExtension GL_EXT_sparse_texture +IgnoreExtension GL_EXT_texture_filter_minmax +IgnoreExtension GL_EXT_texture_sRGB_R8 +IgnoreExtension GL_EXT_texture_sRGB_RG8 +IgnoreExtension GL_OVR_multiview +IgnoreExtension GL_OVR_multiview2
* Bug 1189 - Add OpenGL ES 3.2 and new GL 4.5 Extensions support - Part1b: ↵Sven Gothel2015-10-071-12/+99
| | | | Update Khronos Headers eglext.h (missed)
* Bug 1189 - Add OpenGL ES 3.2 and new GL 4.5 Extensions support - Part1: ↵Sven Gothel2015-10-078-31/+1210
| | | | Update Khronos Headers
* Bug 1239: Support OSX input via 'avfoundation' ; Use remaining camera ID ↵Sven Gothel2015-10-053-3/+6
| | | | (index) as filename for OSX
* Bug 1206 - Security: Clear exposed framebuffer after creation and before ↵Sven Gothel2015-10-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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-041-1/+2
| | | | | | | | | | | | 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
* Bug 1238 - Fix NPE for Window-Icon's PNGPixelRect for unresolved location; ↵Sven Gothel2015-10-031-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Bug 1199 - Add setting to disable default window icons Bug 1238 - Fix NPE for Window-Icon's PNGPixelRect for unresolved location, i.e. null URLConnections Testing w/ jogl/make/scripts/tests.sh USE_BUILDDIR=1, discloses this issue - since the icons are available in jar only. Handling all unresolved resources, i.e. null URLConnection, is required. Further more, the icon list passed via property 'newt.window.icons' shall be separated by comma as well. This allows passing the list via scripts more conveniently. -Dnewt.window.icons="newt/data/jogamp-16x16.png,newt/data/jogamp-32x32.png" +++ Bug 1199 - Add setting to disable default window icons This patch also allows disabling JogAmp's own window icons by simply defining a non-existing location, i.e. -Dnewt.window.icons="null,null"
* Bug 1237: Adopt GlueGen's clarification of IOUtil.getResource(..), commit ↵Sven Gothel2015-10-031-9/+19
| | | | | | | | 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 1241 - Util's Texture.coords (image coordinates) not updated properlySven Gothel2015-10-021-2/+2
| | | | | | | | | Adding 'imageTarget', i.e. GL target for this texture or its sub-components if cubemap The imageTarget preserves the used 2D image type for the 2D Texture coordinates. Note: 'Texture.updateImage(final GL gl, final TextureData data, final int targetOverride)' needs an overhaul targeted for 2.4.0.
* Bug 1205: Revert clear background to support fix for Bug 1232: NEWT ↵Sven Gothel2015-10-011-4/+4
| | | | | | | | | | Translucency Windows >= 8 Reverting 'clear backrgound' portion of commit f607c0148736fa198fb91b60123824e53366022e. It has been identified, that Windows does initialize onscreen windows (i.e. w/ white/DESKTOP color). This is also required for allowing translucent windows, since clearing the background intefers on Windows >= 8 (undecorated windows).
* Bug 1232 - NEWT Translucent Decorated Windows Not Working On Windows >= 8 ↵Sven Gothel2015-10-017-9/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Lack of Aero / Blur ) Adopting new undocumented user32.dll Windows >= 8 API: - SetWindowCompositionAttribute / AccentState See: - <https://github.com/riverar/sample-win10-aeroglass/blob/master/MainWindow.xaml.cs> - <http://withinrafael.com/adding-the-aero-glass-blur-to-your-windows-10-apps/> - <http://undoc.airesoft.co.uk/user32.dll/SetWindowCompositionAttribute.php> - <http://undoc.airesoft.co.uk/user32.dll/GetWindowCompositionAttribute.php> +++ Cleaning up WindowsDWM.h, use on header file (in stub_includes) for GlueGen and implementation. +++ Merge java implementation within GDIUtil.DwmSetupTranslucency(..), to be utilized by NEWT and JOGL. NEWT issues GDIUtil.DwmSetupTranslucency(..) at creation and when toggling decoration. Toggling decoration on Win >= 8 leads to lost of translucency when returning to decorated window. On Win 7, this may work .. but is also buggy. +++ Followup patch is needed for NEWT to _not_ clear the background!
* Bug 1205 - NEWT Security: Clear framebuffer after creation and before ↵Sven Gothel2015-09-292-5/+6
| | | | | | | | | | | | | | | | | | | visibility (Windows Onscreen) WindowsWindow.c: - WindowUserData.isInCreation set while window at initizalization, i.e. before final size/pos/visibility. Also no visibility until final NewtWindow_setVisiblePosSize(..) call. This is possible since even w/o ShowWindow upfront, UpdateInsets(..) is able to gather accurate values. - Suppress any Java callback while WindowUserData.isInCreation, issue one callback when window is final. Use newly accumulated callback WindowImpl.sizePosInsetsFocusVisibleChanged(..) - While WindowUserData.isInCreation, WM_PAINT triggers WM_ERASEBKGND and WM_ERASEBKGND actually erases background w/ window background color.
* Bug 1233 - Add missing range- and pbo-bound checks on glTexture[Sub]Image[123]D*Sven Gothel2015-09-281-13/+52
| | | | | | | | | | | | | Adding missing range- and pbo-bound checks for: - glTextureImage1DEXT - glTextureImage2DEXT - glTextureImage3DEXT - glTextureSubImage1D - glTextureSubImage1DEXT - glTextureSubImage2D - glTextureSubImage2DEXT - glTextureSubImage3D - glTextureSubImage3DEXT
* Bug 1125: Unit test to validate that Thread.interrupt() does not disturb ↵Sven Gothel2015-09-282-2/+4
| | | | continued rendering of AWT and GLCanvas
* Bug 1232 - NEWT Translucent Decorated Windows Not Working On Windows >= 8 ↵Sven Gothel2015-09-261-2/+2
| | | | | | | | | | | | (Lack of Aero / Blur ) - Wrap GDI::DwmIsCompositionEnabled() in GDIUtil, so it always returns true if Windows >= 8 (even if not manifested) - Nothing we seem to be able to do about the lack of Aero, i.e. blur effect of decorated windows - Undecorated windows work well though ..
* Bug 1222 - NEWT OSX: setAlwaysOnTop() and setAlwaysOnBottom() not workingSven Gothel2015-09-261-1/+1
| | | | | | | | | | | | - The NSWindow level must be set at window creation - Levels are - aontop: kCGMaximumWindowLevel - aonbottom: kCGDesktopIconWindowLevel (w/ input) - normal: NSNormalWindowLevel - Hence we need to recreate the NSWindow if toggling the state, similar to opaque .. etc.
* Bug 1188: Fix setMaximized(..) isReconfigureMaskSupported(..) querySven Gothel2015-09-261-2/+2
| | | | | | | setMaximized(..) isReconfigureMaskSupported(..) was using the state bit-number instead of the state bit-mask! Fixed.
* Bug 1214: Fix Deadlock in screenPositionChanged(..); Use ↵Sven Gothel2015-09-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-251-3/+3
| | | | | | | | | | | 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 12:05:25 +0000