| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Callbacks as recommended
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a native dispatch'ed event like key/mouse/touch input
SIGSEGV on use after free of native X11 Display* at XEventsQueued in DisplayDriver.DispatchMessages0.
This potentially happens when an application destroys
the NEWT Window/Display from an action being called directly
from DisplayDriver.DispatchMessages0 (itself), i.e. keyboard or mouse input.
DisplayDriver.DispatchMessages0 stays in the event loop and the next
XEventsQueued call causes a SIGSEGV due to already deleted
display driver connection and hence invalid native X11 Display*.
This issue also exist for other Windowing System drivers,
where the native (dispatch) method sticks to a loop
and still (re)uses the window or display handle.
One is WindowsWindow, where touch events are looped,
but such handler could have closed the window.
Querying the status of a window / display instance before dispatching
is not be good enough
- resource could already be GC'ed, so we also would need to query jobject status
- would imply an addition Java callback
+++
This fix: Having the Java callbacks return
a boolean with the value Window.isNativeValid().
This way the dispatch logic
- can bail out right away w/o using the resource anymore
- must be reviewed by myself due to changed Call{Void->Boolean}*(..)
invocation change.
This review shall resolve potential similar issues.
+++
Tested on X11/Linux/GNU, Windows and MacOS
with new TestDestroyGLAutoDrawableNewtAWT,
which tests all destruction invocation variants.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
size and position via atomic-replacable int arrays
NEWT's Soft-PixelScale supports software pixel-scale by multiplying the underlying surface pixel-size with the scale-factor
and dividing the window position and size by same scale-factor.
Hence the window position and size space is kept virtually steady at virtually assumed DPI 96 at higher actual screen DPI
and the surface size is adjusted.
+++
This window- and pixel-unit separation also includes all callbacks for the native driver implementations,
hence the changes native code - allowing to determine whether window- or pixel-units were given.
|
| |
|
|
| |
insetsChanged + insetsVisibleChanged
|
| |
|
|
| |
argument. Method only changes state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
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.
|
