| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
X11Window.c's 'NewtWindows_getFrameExtends(..)'
retrieves the insets via XGetWindowProperty on _NET_FRAME_EXTENTS.
Right after window creation this method fails as the WM did not yet
provide the information as the window has not yet been mapped.
Implementation needs to retry for a certain amount of time (250ms)
and maximum number of attempts (96 XEvent).
This issue surfaced while validating fix for Bug 1393,
testing TestDisplayLifecycle02NEWT also on X11.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
insetsChanged + insetsVisibleChanged
|
|
|
|
| |
argument. Method only changes state.
|
|
|
|
|
|
|
|
| |
To allow proper testing of whether all AppKit calls are performed on its Main-Thread where required,
we inject the libMainThreadChecker.dylib when property 'nativewindow.debug.OSXUtil.MainThreadChecker' is set.
See <https://developer.apple.com/documentation/code_diagnostics/main_thread_checker?language=objc>
Lib-Name: /Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib
|
|
|
|
|
|
| |
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
|
|
|
|
| |
unnecessary JNI calls
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
RemovalCriteria as all Test definitions may be used for anything.
|
|
|
|
|
|
|
| |
X11GLXGraphicsConfiguration having a valid XVisualInfo
Therefor X11GLXGraphicsConfiguration::GLXFBConfig2GLCapabilities(..) also needs to clean the GLGraphicsConfigurationUtil.BITMAP_BIT
from drawableTypeBits and if all removed, drop the FBConfig.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
reusable [GL]CapabilitiesImmutable list filter
To implement fix for Bug 1392, we have to remove certain GLCapabilitiesImmutable from the availability list.
These filter provide a a clean reusable utility for the fix.
|
|
|
|
| |
BuggyColorRenderbuffer enables NoFullFBOSupport
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
failure on unsupported GL data format/type
GLPixelBuffer.GLPixelAttributes::convert(GL, int, boolean) failed on unsupported GL data format/type
On Mesa/AMD for GLPBuffer chosen GLCaps used rgba 10/10/10/2
and the GLContext set default values:
GL_IMPLEMENTATION_COLOR_READ_FORMAT: 0x1908 GL_RGBA
GL_IMPLEMENTATION_COLOR_READ_TYPE: 0x8368 GL_UNSIGNED_INT_2_10_10_10_REV
GLPixelBuffer.GLPixelAttributes::getPixelFormat(int format, int type)
currently does not handle the type GL_UNSIGNED_INT_2_10_10_10_REV
and hence returned a null PixelFormat.
Therefor the ctor GLPixelAttributes failed and threw the exception:
"Caught GLException: Could not find PixelFormat for format and/or type:
PixelAttributes[fmt 0x1908, type 0x8368, null]"
This fix has the GLContext default values pre-validated in the convert(..) method
and to use default GL_RGBA and GL_UNSIGNED_BYTE fallback values if not supported.
This is most important to be future proof.
Later we may shall add these 32bit coding 2+10+10+10 and its reverse.
|
|
|
|
|
|
|
|
|
|
| |
avoiding further unnecessary warnings
Access to said internal non-exported methods is essential.
See commit c5431f46b7bf64f109315ec78461859dd88f202a.
Further added verbose DEBUG output where applicable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
profile && has core profile
On Mesa, if requesting a 3.1 compat profile, we receive a 4.5 core profile.
This is natural due to constraints within glXCreateContextAttribsARB,
i.e. GLX_CONTEXT_PROFILE_MASK_ARB is only a available for versions >= 3.2
and these are not available on Mesa.
Tested with Mesa 18.3.6 of Debian 10 Buster,
which also confirms Bug 1385 fix of limitating GL3CompatNonCompliant
to Mesa < 18.2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
version/profile, also ..
also, if requested version is within GL3CompatNonCompliant valid range, i.e. < 3.1,
the detected actual version will be clipped for valid mapping to the requested data.
Here it might be essential to know, that all versions are being 'scanned'
via mapGLVersions from high to low.
Therefor Version 3.0 would be tried before 2.0
and both will be mapped to the clipped actual version 3.0.
The true actual version could be the maximum, however,
using the very same would lead to trying an invalid unavailable GLProfile.
|
|
|
|
|
|
|
| |
requested profile bit is set; Query GL_CONTEXT_PROFILE_MASK for hasCtxProfileBits
and finally guess the GL profile bit if none could be determined:
'isESReq ? GLContext.CTX_PROFILE_ES : GLContext.CTX_PROFILE_COMPAT'
|
|
|
|
|
|
| |
OpenGL version open, don't assume the profile
The profile should be queried at runtime like the version in these situations.
|
|
|
|
| |
max; Add OpenGL version 4.6
|
|
|
|
|
|
|
|
|
| |
variables and clip at 180 line width
This cleanup became necessary to re-analyse the code after quite some time.
Using clear immutable input input parameters for the requested OpenGL version+profile
and mutable current state 'has'.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow GLRendererQuirks to be overridden by user properties,
allowing to either force (inject) a quirk by a user property
or to ignore a quirk by a user property.
This helps:
- debugging certain quirk behavior (See Bug 1383)
- allowing a user to customize the quirk setting
+++
This patch also refines the quirk: GLNonCompliant -> GL3CompatNonCompliant,
i.e. constraints its semantics to GL3 compatible context.
+++
This patch also removed useless code of GLRendererQuirk,
i.e. the 'int[] quirk' array arguments which are nonsense
or wasteful, as we operate with bitmasks.
|
|
|
|
| |
Original author is 'Tof'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
Changed getPixelScale to use standard method, even on Mac
Previously it used a Mac-specific method, but the new standard method of
device.getDefaultConfiguration().getDefaultTransform() seems to work on
Mac, so use it instead to avoid illegal reflective access warnings.
Orig patch by Wade Walker.
|
|
|
|
|
|
|
|
|
|
|
|
| |
[illegal reflective access]
Use non-reflective method to get the pixel scale on Java9+
It's now possible to use GraphicsConfiguration.getDefaultTransform()
instead of using reflection to get the pixel scale, which eliminates an
illegal reflective access warning.
Orig patch by Wade Walker
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[illegal reflective access]
Avoid illegal reflective access to sun.awt.SunToolkit.awtLock/Unlock on Java9+
Apparently these give a performance benefit on X11 by avoiding taking
the AWT global lock, and instead only taking a Java lock defined in
sun.awt.SunToolkit. But this has thrown a warning since Java 9, and will
soon be illegal. If a performance problem remains on X11, we'll need to
find another solution.
Orig patch by Wade Walker.
This patch only skips utilizing said API on Java9+
while maintaining orig code path for Java8.
|
|
|
|
|
|
|
|
| |
We were reading a variety of surface type definitions from
sun.java2d.opengl.OGLUtilities using reflection, which has thrown
warnings since Java 9 and which soon will become illegal. For now, just
hard-coded these types to remove the warnings that happen during static
initialization. Eventually the entire Java2D class will have to be
revamped if we want to be able to actually use it.
|
| |
|
| |
|
|
|
|
|
|
|
| |
and remove the redColor default background (debug only).
IOSUtil.CreateUIWindow(..) also gets its 'visible' attribute,
to be true only for demo Hello1 code - false for intended Proxy Surface Hook.
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Adding the missing JogAmp copyright tag on certain files.
Currently in debate whether 'JogAmp Community' is a legal Copyright tag in the first place,
we might need to add (or replace it with) my authorship.
However, as authorship is well documented via the git repository,
this should be no real world issue.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notable bug as mentioned before:
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).
This workaround re-binds the used color renderbuffer for EAGLLayer presentation
at the end of the FBO drawable instantiation.
FBO DEPTH buffer works now as demonstrated w/ GearsES2.
We have to issue one more test now, using a demo using an FBO itself.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initial commit bba73bc096250a3c7fc036d84b1ea054d1b70b06 hacked
its path using a context global EGLLayer instance attachement.
The hack was good for the first demo, however, it forbid using
other FBObjects etc on the way.
Properly specifying FBObject.Attachment.StorageDefinition,
allowing the user to inject code for selected FBO attachements
to define their storage. This might be useful for different
platforms as well - however, it is OS agnostic and instance specific now.
In this sense, GLFBODrawableImpl, hosting FBObject,
has a more specific instance of FBObject.Attachment.StorageDefinition
for color-renderbuffer. It is passed along newly created color renderbuffer.
GLDrawableFactoryImpl.createGLDrawable uses a derived interface,
OnscreenFBOColorbufferStorageDefinition which is defined in
IOSEAGLDrawableFactory and return by its getter.
GLDrawableFactoryImpl.createGLDrawable is therefor platform agnostic again.
Bottom line is, as more platforms will be added, these semi-public interfaces
have to adapt to suit them all ..
All this due to iOS architecture for 'onscreen rendering' using a FBO
which shares its color renderbuffer storage with the EAGLLayer,
associated with the UIView. A bit weird maybe in first sight,
but efficient for creating cheap hardware design ;-)
Only criticism here is that Apple didn't bother using EGL and an extension.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
alphaRequested + add appropriate API doc
|