aboutsummaryrefslogtreecommitdiffstats
path: root/src/newt/classes/jogamp
Commit message (Collapse)AuthorAgeFilesLines
* Bug 1156: LinuxKeyEventTracker, LinuxMouseTracker: Robostness (+NEWT fix)Sven Gothel2019-11-306-41/+65
| | | | | | | | commit 453f80e38bcb0945e7eac27a5917dce9bdc6446b added disabling the tracker, however the NEWT usage didn't cover all mouse tracker null pointer. Further, let's initialize and spawn off the threads only at first getSingleton() call not at class initialization earlier.
* Bug 1156: LinuxKeyEventTracker, LinuxMouseTracker: Adding property to ↵Sven Gothel2019-11-302-14/+42
| | | | | | | | | | | disable each LinuxKeyEventTracker also disable the eventX reading by default, but can be enabled via new property. The 'return bug' (crash due to underlying console) is indeed not occuring when using a VT w/o running console application underneath. As Xerxes showed, one may use chvt to a free known VT or openvt.
* Bug 1156: LinuxKeyEventTracker: Add '/dev/input/by-path/*-event-kbd' and ↵Sven Gothel2019-11-291-42/+75
| | | | more documentation
* Bug 1156: DRM/GBM: Add full PointerIcon (Cursor) SupportSven Gothel2019-11-294-39/+201
| | | | | | | | | | | | DRM allows 64x64 pixel cursor images, using GBM_FORMAT_ARGB888 only. Notable: GBM_FORMAT_ARGB888 == PixelFormat.BGRA8888 Having fixed mouse and keyboard input with previous commit, the demo com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT shows via key press - i -> pointer visible/invisible - c -> pointer icon change
* Bug 1156: LinuxKeyEventTracker: Fix 64bit InputEvent and attempt to only use ↵Sven Gothel2019-11-292-54/+123
| | | | | | | | | | | | | keyboard event files The time structure on 64bit machines uses two 8 byte long values instead of two 4 bytes int values on 32bit machines. The insufficient read on 64bit machines caused an IllegalArgument exception. This fix considers 32 or 64 bit operation. Class renamed: LinuxEventDeviceTracker -> LinuxKeyEventTracker, as it tracks key events specifically. Now the EventDeviceManager tries to only use /dev/input/by-id/*-event-kbd keyboard event files, which reduces the handling on kbd event files only.
* Bug 1156 - Implement DRM/GBM Support for JOGL(EGL) and NEWTSven Gothel2019-11-283-91/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding new classes DRMLib (gluegen of drm + gbm), DRMUtil and DRMMode GBMDummyUpstreamSurfaceHook to new package jogamp.nativewindow.drm, allowing full awareness of DRM + GBM within NativeWindow for JOGL + NEWT. DRMMode replaces the previous native code of collecting drmMode* attributes: active connector, used mode, encoder etc and also supports multiple active connectors. DRMUtil handles the global static drmFd (file descriptor), currently only the GNU/Linux DRM device is supported. GBMDummyUpstreamSurfaceHook provides a simple dummy GBM surface. NativeWindow provides the new nativewindow_drm.so and nativewindow-os-drm.jar, which are included in most 'all' jar packages. build property: setup.addNativeEGLGBM -> setup.addNativeDRMGBM Changes NativeWindowFactory: - TYPE_EGL_GBM -> TYPE_DRM_GBM while keeping the package ID of '.egl.gbm' for NEWT (using EGL) - Initializing DRMUtil at initialization Changes EGLDrawableFactory: - Using native GBM device for the default EGL display creation instead of EGL_DEFAULT_DISPLAY. This resolves issues as seen in Bug 1402, as well in cases w/o surfaceless support. - GL profile mapping uses surfaceless when available for GBM, otherwise uses createDummySurfaceImpl (dummy GBM surface via GBMDummyUpstreamSurfaceHook) - createDummySurfaceImpl uses a dummy GBM surface via GBMDummyUpstreamSurfaceHook - DesktopGL not available with GBM, see Bug 1401 NEWT's DRM + GBM + EGL Driver - Using DRMLib, DRMUtil and DRMMode, removed most native code but WindowDriver swapBuffer - ScreenDriver uses DRMMode, however currently only first connected CRT. - WindowDriver aligns position and size to screen, positions other than 0/0 causes DRM failure - WindowDriver reconfigure n/a NEWT TODO: - DRM Cursor support (mouse pointer) - Pointer event handling
* Bug 1156: GBM: Bring up incl GL rendering (TODO: GBM working page flip / sync)Sven Gothel2019-11-233-23/+86
| | | | | | | | | | | | | | | | | - EGLSurface: Factor out 'eglCreate[Platform]WindowSurface' NEWT egl.gbm.WindowDriver -- Properly use GBM fourcc format and use as visualID for GBM surface creation and EGL config selection -- Create eglSurface within this class -- Hook up GBM/DRM page flip (not working yet, no visible artifacts - no swap) - ProxySurfaceImpl.surfaceSwap() call upstreamSurface's implementation if available TODO: 'Permission denied' calling: - drmSetMaster (optional) - drmModeSetCrtc - drmModePageFlip
* Bug 1156: GBM: Fixing native GBM code, surviving initializationSven Gothel2019-11-222-10/+16
|
* Bug 1156: NEWT: NewtFactory.getCustomClass(..) RobustnessSven Gothel2019-11-223-15/+3
| | | | | getCustomClass(..) shall throw all required exceptions upstream. Previous essential NEWT driver exception information got suppressed if failing, only disclosed in debug mode.
* Bug 1156: EGL-GBM: Cleanup Code & Replace Newt GBM implementationSven Gothel2019-11-216-270/+467
| | | | | | GBM driver is now under egl/gbm subpackage and has been replaced by bcm_vc_iv boilerplate. Native code is reentrant capable and cleaned up. TODO: EGLDisplayUtil work with SharedResourceRunner
* gbm/WindowDriver: make it compile and linkXerxes Rånby2019-11-211-4/+6
|
* add native gbm implementation for drm and gbm initialization.Erik De Rijcke2019-11-212-134/+4
|
* add gbm java & build modificationsErik De Rijcke2019-11-213-0/+398
|
* Bug 1393: MacOS: Wait for window position setting on main-thread (blocking)Sven Gothel2019-11-211-17/+4
| | | | Also issue the orderFront0 call within createWindow1 (aligned with IOS code)
* Bug 1393: MacOS: Implement AppKit EDTUtil operating solely on main-threadSven Gothel2019-09-162-1/+362
| | | | | | Introducing boolean property 'newt.macos.useAppKitEDTUtil', which defaults to 'false'. If enabled, the new AppKitEDTUtil is being used, operating on the AppKit main thread. This is used to ease debugging Bug 1393, minimizing thread context switches.
* NEWT Cleanup: WindowImpl: Drop unused 'defer' argument (state change only): ↵Sven Gothel2019-09-104-16/+11
| | | | insetsChanged + insetsVisibleChanged
* NEWT Cleanup: WindowImpl::visibleChanged(ZZ): Remove unused 'defer' ↵Sven Gothel2019-09-1010-32/+32
| | | | argument. Method only changes state.
* Bug 1393: MacOS/iOS: Issue updateSizePosInsets0 async to AppKit Main-ThreadSven Gothel2019-09-092-5/+22
| | | | | | Additionally, setPointerIcon0 must also be made async on AppKit (instead of wait), we have to assume/hope the user won't pull the PointerIconImpl instance in-between ;-) Hence removing the comment regarding the lifecycle.
* Bug 1393: Run orderFront0(=setVisible) async off-thread on AppKit after sync ↵Sven Gothel2019-09-092-36/+49
| | | | | | | | | | | | | | | | | 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
* Bug 1363: Java 11: JAWTUtil: Use sun.awt.SunToolkit.awtLock/Unlock and ↵Sven Gothel2019-09-041-58/+4
| | | | | | | | | | | | | | | disableBackgroundErase (impl. semantics) Commit 13c6bbbde5ea476d60e0a2f04a5172d3302d0edd simply removed the AWT commonly used SunToolkit lock/unlock methods, which was incorrect. It lead to certain resources access collisions as access has to be synchronized using the same reentry lock across AWT and NativeWindow/JOGL. We utilize the new com.jogamp.common.util.UnsafeUtil of GlueGen commit 07c1885e9a3d1f3a3853414648c06fb3864bc69f to disable the IllegalAccessLogger while fetching the methods/fields and making them accessible. JAWUtil also hosts access to SunToolkit's disableBackgroundAccess(Component) aligning the code for GLCanvas, NewtCanvasAWT and AWTCanvas.
* Bug 1363: Java 11: Resolve unsupported JAWTUtil.getMonitorDisplayID(..)Sven Gothel2019-08-191-3/+3
| | | | | | | | | | | | | | | | | Previous commits removed access to OSX's GraphicsDevice.getCGDisplayID() on Java9+, avoiding illegal reflective access. Here we JAWTUtil.getMonitorDisplayID(..) simply returns null if Java9 or !OSX, so the sole NewtFactory caller falls back to the alternative working solution. Orig patch Wade Walker: This was used on Mac OS only to create a MonitorDevice in NewtFactoryAWT. But there was a fallback method for creating MonitorDevice, and testing with TestGearsES2GLJPanelAWT shows that the fallback method seems to give identical results on Mac, so changed to just use the fallback method (which is now the only method) everywhere. This gets rid of an illegal reflective access.
* NEWT iOS WindowDriver: Remove unused orig UIWindow/UIView creation pathSven Gothel2019-07-081-48/+0
| | | | See commit 004c67c73a0309158c30929cd0d6513e23f34803
* NEWT iOS WindowDriver: native UIWindow/UIView creation changeSven Gothel2019-07-081-13/+56
| | | | | | | | Astonishingly, the original code path doesn't show up the CAEAGL View/Layer (only the red test background) even though t is 1:1 equal to this alternative calls. Keeping the original path intact for future validation, another round of hours of analysis. The original code path will be removed in the next commit.
* NEWT iOS: Support Multi-Touch Events, PixelScale, ..Sven Gothel2019-07-081-2/+16
| | | | | | | | | | | | | | | | | 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 / MacOS: PixelScale UpdateSven Gothel2019-07-084-38/+47
| | | | | | | | | | - IOSUtil/OSXUtil: Return float value and refine name to GetScreenPixelScale* - WindowDriver's updateMaxScreenPixelScaleByDisplayID(..) and updateMaxScreenPixelScaleByWindowHandle(..) will only update the maxPixelScale, as actual user pixelSize change should not be triggered here. A user pixelSize adaption to the changed underlying scale capabilities (e.g. switch monitor) should be supported by the implemented WindowDriver's: updatePixelScale(..) called by native code.
* NEWT WindowImpl.doPointerEvent: Use native short[] for pNamesSven Gothel2019-07-083-16/+13
| | | | | | and not int[], this avoid copying in case given pNames are normalized. This is benecifical for X11, Windows and the upcoming iOS touch/pointer support.
* iOS: Initial working commit supporting iOS (ipad pro 11)Sven Gothel2019-06-234-0/+1554
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Bug 1370: Call from Main-Thread: NW's OSXUtil.CreateNSWindow0(..) and NEWT's ↵Sven Gothel2019-04-051-20/+23
| | | | | | | | | | | | | | | | | | | | | | 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.
* Bug 1367: Adapt to TempFileCache & TempJarCache ChangesSven Gothel2019-04-031-1/+1
|
* Bug 1348: Fix X11 XI MultitouchSven Gothel2019-03-273-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge pull request #104 from gohai/bcm-fix-overscan-offsetSven Gothel2019-03-271-0/+7
|\ | | | | Fix overlay/underlay position mismatch in X11UnderlayTracker (bug 1315)
| * Fix overlay/underlay position mismatch in X11UnderlayTracker with overscan ↵gohai2017-03-051-0/+7
| | | | | | | | | | | | enabled With the overscan enabled by the Raspberry Pi firmware, which seems to be the default for some attached displays, the underlayWindow size will be e.g. 1888x1048 (retrieved from X11), whereas the overlayWindow size remains at 1920x1080 (retrieved from the Broadcom VC IV implementation). This causes the overlay window to be visually offset by a few pixels. Correct this by applying an offset when the two don't match. (Both displays are assumed to have the same center.)
* | Merge pull request #103 from gohai/bcm-fix-mouse-buttonSven Gothel2019-03-271-8/+8
|\ \ | | | | | | Fix mouse button reporting in X11UnderlayTracker
| * | Fix mouse button reporting in X11UnderlayTrackergohai2017-02-161-8/+8
| |/
* | Merge pull request #102 from Yodoga/feature_multitouch_x11_1348Sven Gothel2019-03-271-0/+14
|\ \ | | | | | | add touch event support for x11 server
| * | add touch event support for x11 serverDanny Koernig2016-11-171-0/+14
| |/
* | Merge pull request #97 from gohai/bcm-fix-viewportwuSven Gothel2019-03-261-2/+2
|\ \ | | | | | | Fix viewport height in BCM VC IV ScreenDriver
| * | Bug 1254: Fix viewport height in BCM VC IV ScreenDrivergohai2016-04-041-2/+2
| |/ | | | | | | This should fix https://jogamp.org/bugzilla/show_bug.cgi?id=1254, which leads to windowed sketches not being centered in Processing.
* / JavaFX: Adding JavaFX Support for NEWT utilizing native Window parenting via ↵Sven Gothel2019-03-191-0/+358
|/ | | | | | | | | | | | | | | | | | | | | 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
* Bug 1267 - OSX El Capitan: Animated NEWT GLWindow flickers at resizeSven Gothel2015-11-152-2/+15
| | | | | | | | | | | | OSX El Capitan 10.11.1 using JRE 1.8.0_66: Animated NEWT GLWindow flickers at resize. While at live resize the animation thread renders into the live resized NSView which causes flickering on OSX 10.11. Resolution is to pause animation during live resize and resume at its end.
* Remove deprectated classes and methodsSven Gothel2015-10-151-35/+0
|
* WindowImpl.quirks: Access default -> protected, also fix API doc comment.v2.3.2Sven Gothel2015-10-101-3/+3
|
* Bug 1249: NEWT/X11 Visibility: Listening to more events for updated state; ↵Sven Gothel2015-10-101-38/+116
| | | | | | | | | | | | | | | | | 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-092-46/+112
| | | | | | | | | | | | | | | | | | 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 1247: Align NEWT AWT driver w/ GLCanvas (not fixing any issues)Sven Gothel2015-10-091-18/+40
|
* Bug 1249 - NEWT X11: setVisible(false) IconicState/_NET_WM_STATE_HIDDEN: ↵Sven Gothel2015-10-091-1/+2
| | | | | | | | | | | Handle case where KDE unmaps the window Update our internal JavaWindow.isMapped according to MapNotify and UnmapNotify. This takes care of a situation (KDE) where a window is unmapped during IconicState. For unmapped windows we cannot interprete _NET_WM_STATE_HIDDEN and we have to issue XMapWindow for restoring the window.
* Bug 1249 - NEWT X11: setVisible(*) _NET_WM_STATE_HIDDEN update not received ↵Sven Gothel2015-10-091-7/+41
| | | | | | | | | | | | | | | | | | | | | | 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-14/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _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 1238 - Fix NPE for Window-Icon's PNGPixelRect for unresolved location; ↵Sven Gothel2015-10-034-34/+56
| | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | 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'
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-21 16:25:00 +0000