| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
union(List<Rectangle*>) public; Fix union/intersection 'off-by-1' for pos2.
|
|
|
|
|
|
| |
native header and code files)
Part-1 in commit e96aeb6e9acd2b1435f5fad244a1488e74a3a6d6
|
|
|
|
| |
Add 64-bit nativeHandle (Windows HMONITOR), add PixelScale for Windows
|
|
|
|
| |
callbacks ..
|
|
|
|
| |
(Windows 10)
|
|
|
|
| |
deadlock)
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"org.eclipse.swt.internal.cocoa.NSGraphicsContext.saveGraphicsState()" because "context" is null
On MacOS 12+ and SWT 4.26 while not using AWT (-Djava.awt.headless=true, -XstartOnFirstThread),
we recently get the following Exception from SWT (suppressed):
java.lang.NullPointerException: Cannot invoke "org.eclipse.swt.internal.cocoa.NSGraphicsContext.saveGraphicsState()" because "context" is null
at org.eclipse.swt.widgets.Widget.drawRect(Widget.java:764)
at org.eclipse.swt.widgets.Canvas.drawRect(Canvas.java:170)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:6287)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Display.applicationNextEventMatchingMask(Display.java:5565)
at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5965)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSApplication.nextEventMatchingMask(NSApplication.java:92)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3983)
at com.jogamp.opengl.test.junit.util.SWTTestUtil$WaitAction$1.run(SWTTestUtil.java:52)
at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:183)
at org.eclipse.swt.widgets.Display.syncExec(Display.java:5250)
at com.jogamp.opengl.test.junit.util.SWTTestUtil$WaitAction.run(SWTTestUtil.java:63)
at com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextVBOES2SWT3.test02AsyncEachAnimator(TestSharedContextVBOES2SWT3.java:376)
This is not observed if running using AWT (-Djava.awt.headless=false).
|
|
|
|
| |
we see click-count 2 on MacOS 12
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NSWindow on MacOS main-thread
Destroy NSWindow on MacOS main-thread, avoiding spurious more rare SIGSEGV on MacOS 13/aarch64
This closes the MacOS 12+ SIGSEGV JAWT (CALayer) crash fix, see commits:
- 4009198e34b50bba9582be24f33eaf83b94a2cb8
- 3c4cf1f37dc27d8d527804d195361a2287575147
- d969f473fdc72c6ca95f1796ff5af3f0c8bd51b6
- 81f395975c06a66183ad36cc43e8dc9bc7f4545b
- b8977465b2fb8452c2560a5d2561b2561472edf0
- 470a0ff3a2efbe43404d5f80a403efb38005598a
- 9829550f5bcb586f94f98f6d3c39f4d78fd78f3b
|
|
|
|
|
|
| |
operations and zero source references upfront.
Have user being aware of disposal then triggered and not later when performed on MacOS main-thread
|
|
|
|
| |
complete null checks in detachSurfaceLayerImpl(), setSurfaceScale()
|
|
|
|
| |
OSXUtil.FixCALayerLayout() on main thread and hence fetch and validate getAttachedSurfaceLayer() when needed
|
| |
|
|
|
|
|
|
|
|
| |
attach command, essential if attach hasn't been done yet @ detach
Otherwise a pending attach would still pass through after DetachGLLayerCmd releases the sync-lock from AttachGLCmd.
DetachGLCmd also tests 0 != nsOpenGLLayer
|
| |
|
|
|
|
| |
offscreenSurfaceLayer for pending off-thread operation and immediately zero reference marking its future destruction.
|
|
|
|
|
|
| |
taken from the GLContextShareSet map
The objects were more sticky on my MacOS 12 x86_64 machine, this double GC w/ sleep 100ms resolved it.
|
|
|
|
| |
names when in use, make Android d8 (Dex'ing) happy
|
| |
|
| |
|
|
|
|
| |
here > 10.14.0 (Mojave)
|
|
|
|
| |
in madeCurrent
|
|
|
|
| |
supported (MacOS only)
|
| |
|
|
|
|
| |
null com.jogamp.newt.swt.NewtCanvasSWT.access$200(com.jogamp.newt.swt.NewtCanvasSWT)
|
| |
|
|
|
|
| |
display.readAndDispatch() wait action (experimental)
|
|
|
|
| |
to avoid "cannot register existing type 'GdkDisplayManager'" and subsequent SIGSEGV
|
|
|
|
| |
disposed (manual test case)
|
|
|
|
| |
Cannot invoke "com.jogamp.newt.Window.getDelegatedWindow()" because the return value of "com.jogamp.newt.swt.NewtCanvasSWT.access$200(com.jogamp.newt.swt.NewtCanvasSWT)" is null
|
| |
|
|\
| |
| | |
Add new class location of SWT's gtk_widget_get_window
|
| |
| |
| |
| |
| |
| |
| | |
In SWT version 4.20, some gtk methods moved to a new gtk3 subpackage so add
check and find it in there. Note, this new package was not exported until
SWT 4.23 (aka 3.119.0 or v4950) so intervening versions will not work when
using OSGi class loading.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
request regarding GLX extensions
https://github.com/sgothel/jogl/pull/107
Return either glXQueryClientString or glXQueryExtensionsString when getting the GLX extensions
ndjojo:
glXQueryExtensionsString will make a request for glXQueryServerString if needed and will append the necessary client-side extensions.
This doc, under the section "Using GLS Extensions", also suggests checking the glXQueryExtensionsString before using GLX extensions.
+++
aschleck:
For some more context this came up with the release of Mesa 20.3.0,
which has client support for GLX_EXT_swap_control but no server support.
The current JOGL behavior of appending the client extensions to the server extensions is incorrect.
They should instead be intersected (with client-only extensions then appended) as the doc Nicole linked above says,
which is precisely what glXQueryExtensionsString does.
With the current extension querying behavior JOGL thinks glXSwapIntervalEXT is available under Mesa/llvmpipe
even though it is not, causing a segfault at JOGL initialization time.
I originally filed this as a Mesa bug (https://gitlab.freedesktop.org/mesa/mesa/-/issues/4128)
along with some code that repro'd JOGL's checking behavior but it became apparent that Mesa is fine and the checking behavior is incorrect.
|
|\ \
| | |
| | | |
Return either glXQueryClientString or glXQueryExtensionsString when getting the GLX extensions
|
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GLContext.isGL3bcAvailable() check
Julien Gouesse resolved this odd issue, where a requested GL2 profile was mapped to GL3bc but is not implemented,
see <https://forum.jogamp.org/InternalError-XXX0-profile-2-GL2-gt-profileImpl-GL3bc-not-mapped-td4041754i20.html#a4042018>.
I exploded his patch a little to reuse the GLContext.getAvailableGLProfileName() result
and simplify the conditional statement.
This might need more testing perhaps, plus analyis why GLContext.getAvailableGLProfileName()
offers GL3bc but is not available via GLContext.isGL3bcAvailable() check.
|
| |
| |
| |
| | |
comparison result
|
| |
| |
| |
| | |
GLContextImpl.MacOSVersion
|
| |
| |
| |
| | |
GLEmitter
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
TSMGetInputSourceProperty(), crashing on MacOS >= 13
Perhaps we want a replacement?
Fallback code uses keyCode, i.e. dropping the current keyboard layout (-> US).
|