| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
closing)
Commit d5ba4cae824087879a4857e20961a95da04eaebb clarified and simplified the lifecycle of a PointerImpl instance, i.e. drop its resurrection in
PointerImpl.validateHandle() in favor of a hard exception.
This caused detection of subsequent PointerImpl lifecycle issues,
as instances were not fully destroyed on Display closing and
references not null'ed in Display and Screen instances.
|
|
|
|
| |
This bug never allowed a PointerIconImpl to be destroyed via PointerIconImpl.destroy()
|
|
|
|
|
|
|
|
|
| |
stdin in vsync-wait-loop
User input during test from the console will also end up in stdin of the console after the java application has been closed.
This is not only annoying, but also a security concern, as the input gets executed if containing a CR.
Further, the vsync-wait-loop shall ignore stdin.
|
|
|
|
| |
Move native handle check to pre-destruction call in PointerIconImpl.destroyOnEDT(..), unifying single destruction and all.
|
| |
|
| |
|
|
|
|
| |
hence pass PointerIconImpl through
|
|
|
|
|
|
|
| |
eglSwapBuffers(..) just in case ..
This is the poor man's SYNC: glFenceSync () with glWaitSync().
However, this change did not resolve Bug 1408. Earmarked to be removed!
|
|
|
|
| |
disables PointerIcon usage in general.
|
|
|
|
| |
decoration for PointerIcon operations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PointerIconImpl.validatedHandle() shall not create native resource.
Semantic cleanup for clarity and equal behavior
Align DisplayImpl.createPointerIcon(..) behavior
- return null handle of createPointerIconImplChecked(..) shall be accepted,
no exception for neither of the two creation methods.
PointerIconImpl.validatedHandle() shall not create native resource.
- throws exception if handle is null (about to be used)
- no native creation shall happen here.
Display.PointerIcon.validate(): Removed, not used.
|
|
|
|
| |
swapInterval to optionally skip VSYNC if 0
|
|
|
|
| |
must be enabled via -pointerIcon
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
more documentation
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
| |
getCustomClass(..) shall throw all required exceptions upstream.
Previous essential NEWT driver exception information got suppressed if failing, only disclosed in debug mode.
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
|
|
|
| |
Also issue the orderFront0 call within createWindow1 (aligned with IOS code)
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
insetsChanged + insetsVisibleChanged
|
|
|
|
| |
argument. Method only changes state.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
See commit 004c67c73a0309158c30929cd0d6513e23f34803
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dimensions)
Christian reported this bug and described multiple pathways.
This change usese the following:
- access to getClientAreaInPixels w/ fallback of
- DPIUtil.autoScaleUp(getClientArea())
I hardly have tested this on Linux/GTK, even though I use a High DPI monitor,
maybe just because of it and Eclipse _poor_ state of proper UI presentation.
Christian: Please test this .. if buggy, reopen quick for release 2.4.0
SWT/GTK High-DPI is a PIA:
- GDK_SCALE renders offscreen and scales the image (wow & ugly)
- GDK_DPI_SCALE works at least on the fonts properly
- swt.autoScale is pretty much like: What will be scaled?
It scales some icons in Eclipse, not fonts and result in Eclipse
looks horrible.
Maybe I just made this patch to vent about this poor state of things.
Notable: KDE looks great and uses DPI, firefox some GDK_DPI_SCALE equivalent (OK)
One also wonders why there is only a single scale dimension, where DPI differs x/y!
But enough of my rant :)
|
|
|
|
|
|
|
| |
reparenting!
Bug 1362 fix or workaround: Seems SWT/GTK3 at least performs lazy initialization
Minimal action required: setBackground of the parent canvas before reparenting!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Fix overlay/underlay position mismatch in X11UnderlayTracker (bug 1315)
|
| |
| |
| |
| |
| |
| | |
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.)
|
|\ \
| | |
| | | |
Fix mouse button reporting in X11UnderlayTracker
|
| |/ |
|
|\ \
| | |
| | | |
add touch event support for x11 server
|