| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
NativeWindow X11 Error Handler: If quiet do not print message on stderr.
|
|
|
|
| |
XOpenDisplay/XCloseDisplay
|
| |
|
| |
|
| |
|
|
|
|
| |
Was intended to fix bug 515, which it doesn't. However, NIO usage is fine in this case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DisplayRelease0; Using 'EDT' suffix for display arguments
CloseDisplay in same order as creation (ATI)
- This enhanced the erroneous bug 515 (b54497155815852744adb657816cb4057948dae2) situation
with closing the display connections. However, some SIGSEGV still slipped through.
Adding DisplayRelease0
- Intended for cleaning up resources. Currently a NOP.
Using 'EDT' suffix for display arguments
- To mark the semantics of the display connection, which may be for window or EDT now.
|
|
|
|
| |
https://jogamp.org/bugzilla/show_bug.cgi?id=515
|
|
|
|
| |
commit cfb9e118e020707842e6b5136b07f5ab149540c1
|
| |
|
|
|
|
| |
ensuring init after UI Lock
|
|
|
|
|
|
|
|
|
|
|
| |
happens on AWT-EDT
We will use the default implicit call of GLProfile.initSingleton(false).
(This is the same case as for AWT applets as.)
We shall create extra test cases for AWT + GLProfile.initSingleton(true)
to test it's stability. However .. to nail down our test instability w/ AMD's fglrx driver
we move to the default behavior.
|
|
|
|
| |
sub-class calls
|
|
|
|
|
|
|
|
|
|
| |
fluctuating NEWT tests
Add GLProfile.initSingleton(true) call for fluctuating NEWT tests
- Some of these tests even fail in the <init> state, i.e. cause a JVM stack dump
around an early GLX createContext method only when issued via Jenkins.
The Ubuntu 11.04/64bit Jenkins node runs 2 nodes (32 and 64 bit).
TODO: Find cause.
|
| |
|
| |
|
|
|
|
|
| |
This fixes the _XSend X11 error on GLX commands using AMD driver .. proper cause unknown,
but probably a race or condition or threading issue (Display usage by diff threads).
|
| |
|
|
|
|
| |
4a75b64107e157ff1db3991cf89bf8d856ddc0e6
|
|
|
|
|
|
|
| |
shell.dispose()
This fixes the _XSend X11 error on GLX commands using AMD driver .. proper cause unknown,
but probably a race or condition or threading issue (Display usage by diff threads).
|
|
|
|
|
|
|
|
|
|
|
|
| |
9ed513e9a9616f6028084df4c650c8caf31ea49d
In case of exessive destroy/create (the NEWT reparenting test cases),
some dpyEDT events are slipping through the event dispatcher.
This fix uses issues more XSync on both Display connection in case of 'requestFocus'
and 'closeWindow'.
'requestFocus' also uses the dpyEDT to issue the XSetInputFocus(..), since it's EDT related.
|
| |
|
|
|
|
| |
boolean, see Collection::add/remove
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
GL context ; GLArrayDataClient-GLSL: Check if ShaderState is attached.
ShaderState Usage/Test: Add setShaderState(GL) for pre-use attachment to the GL context
- test cases utilize ShaderState before useProgram() was invoked,
hence we need an API entry to attach the ShaderState explictly
GLArrayDataClient-GLSL: Check if ShaderState is attached.
- catch error case of non bound ShaderState to GL context
|
|
|
|
|
|
|
|
|
| |
use System.err ; TestParenting02AWT: use GearsES2
JAWTWindow.getLocationOnScreen()
- Add proper JAWT lockSurface()
- Turns out that the parent location query of a NEWT child
to an [J]AWT window didn't lock the window
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Java 7's javah requires all referenced classes to be classpath,
even if they're just method parameters and never instantiated.
Java 6's version of javah didn't require this.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
libxcb 1.7 bug 20708
See https://jogamp.org/bugzilla/show_bug.cgi?id=502
Since the libX11/xcb code doesn't seem to be fixed anytime soon
a better usable workaround is required than using a system property
to enable 'over locking'.
It turns out that the race condition is related to the parallel
X11 Display connection usage of GLX/OpenGL and event dispatching.
This workaround utilizes 2 X11 Display handles, one for windowing/OpenGL
and one for event dispatching.
This approach allows us to cont. multithreading use w/o locking the display
and works on both implementations, the old bug-free libX11 and the 'new' buggy one.
Downside is the little resource overhead of the 2nd X11 Display connection .. well.
- Removes the property: 'nativewindow.x11.mt-bug'
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ShaderState.getShaderState(gl)
This removes the dependency of a GLSL GLDataArray object to a specific ShaderState
and enables sharing of this VBO data, i.e. via a shared context.
Test: TestSharedContextVBOES2NEWT
|
|/ |
|
|
|
|
| |
ctrl-c) ; Generics Coding
|
| |
|
|
|
|
| |
extended by super class
|
| |
|
|
|
|
| |
58469fd2343039c195a88d0b171ba9af2dce40be
|
| |
|
|
|
|
|
|
| |
cstr and add interleaved seg.
vboTarget is required in case of interleaved segments to allow eg. interleaved indices.
|
|
|
|
| |
GLDataArrayHandler throws an exception in cstr if not VBO, but VBO usage is determined later
|
|
|
|
| |
VBO/attribute binding wasn't updated (VBO data written, shader change/switch attribute on same location) ; Optimized interleaved GLSL VBO binding, hence split up GLArrayHandler syncData/enableState
|
| |
|
| |
|
| |
|
|
|
|
| |
NativeWindow/Newt Version since we use *all* targets
|
| |
|