| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 :)
|
|
|
|
|
|
|
| |
Most fixed, some marked as FIXME left still ..
Also fixed AWTRoboUtil regression of last commit(s), where AWTRobotUtil.addClosingListener(..)
called to itself causing a StackOverflowError.
|
|
|
|
|
|
|
| |
SWT unit tests must wait while issuing 'display.readAndDispatch()'
so essential event dispatching won't get blocked.
Previous AWTRobotUtil cleanup and these patches ensure proper lifecycle checks.
|
|
|
|
|
|
|
| |
reparenting!
Bug 1362 fix or workaround: Seems SWT/GTK3 at least performs lazy initialization
Minimal action required: setBackground of the parent canvas before reparenting!
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Canvas PAINT!
This commit shows the very little change set required to allow working on SWT >= 4.10 + GTK3,
i.e. adding the PAINT listener to Canvas and letting it paint.
Almost too ridiculous? I stumbled over it by creating this test in the first place
when copying the 01 test -> 02 and adding the native parenting.
Possible explanation: The parent Canvas may need to paint once at least due to some
lazy initialization within SWT or GTK3?!
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
issues
TestSWTAccessor01: Simply tests SWTAccessor's returned native window handle. Works on SWT + GTK2 and SWT + GTK3.
TestSWTAccessor02NewtGLWindow: Uses same returned native window handle and tests a GLWindow.reparentWindow(..) operation
all rolled out and implemented here ad-hock (comparable to NewtCanvasSWT).
This shall allow simplified debugging.
Testing:
- SWT + GTK2: Works
- SWT + GTK3: Bug reproduced
|
|
|
|
| |
TARGET_PLATFORM_SYSROOT (android)
|
| |
|
|
|
|
|
|
|
| |
isAndroid
We intend to attach a non-matching swt.jar for these build nodes,
to at least pass the javac pass w/o testing on those platforms.
|
|
|
|
|
| |
4.3 is still working w/ GTK2
4.11 is not working as described by Wade
|
| |
|
|
|
|
|
|
| |
https://download.eclipse.org/eclipse/downloads/drops4/R-4.11-201903070500/
This binary make/lib drop is only required for build and unit tests.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
2.4.0
|
| |
|
|
|
|
|
|
|
|
| |
Since Java8 (or even earlier), JRE on OSX uses *.dylib native library suffix
instead of *.jnilib when automatically searching and loading them.
This is not easily being recognized by JogAmp, since we explicitly name
the native libraries with full path when testing with our TempJarCache.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
92006e4baef57f1f3fb647dd307aed5989fd4c8d
Previous commit 92006e4baef57f1f3fb647dd307aed5989fd4c8d
(Note to Danny: I cannot test this now - please re-test and/or review)
X11Common::JavaWindow
- Owns XI extension's xiOpcode, selected xiTouchDeviceId and tracked XITouchPosition array
X11Window::CreateWindow
- Query XI extension only once @ window creation and earmark xiOpcode in JavaWindow instance
- Fix: Device selection code was "class->type != XITouchClass",
but shouldn't it be 'XITouchClass == class->type' (as patched here)
- Fix: Free XIQueryDevice returned XIDeviceInfo array via XIFreeDeviceInfo
- Earmark deviceid in JavaWindow instance
X11Display
- Moved global static touch_coordinates to JavaWindow::xiTouchCoords instance
X11Display::DispatchMessage
- Changed event handling structure similar to https://keithp.com/blogs/Cursor_tracking/
- Fix: Free XGetEventData's optional memory allocation via XFreeEventData
- Reuse JavaWindow's queried xiOpcode
- Fix: Don't overrise windowPointer, instead validate and require a match. JavaWindow must match!
- Fix: Also validate chosen deviceid with JavaWindow's registered device
Newt Build:
- Added libXi in build recipe and doc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On [GNU/Linux] X11 JFXEDTUtil is not required, since X11 can handle multi-threaded native parenting,
however, the Windows platform does require JFXEDTUtil.
Currently the default is to use JFXEDTUtil, which operates solely on the JavaFX thread
for windowing lifecycle and even-dispatch operations.
This behavior can be toggled via the boolean property 'jogamp.newt.javafx.UseJFXEDT',
which currently defaults to 'true'
This behavior might be analyzed in more detail for a fine grained EDTUtil decision.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NewtCanvasJFX
NewtCanvasJFX, a JavaFX Canvas Node, allows attaching a native NEWT Window to the JavaFX Node's native Window (if attached).
The mechanism is similar to NewtCanvasAWT.
Current implementation supports placing the NEWT Window
into the JavaFX scene of the native window correctly,
as well as the following different lifecycles
- attach NewtCanvasJFX to already visible group->scene->window
- attach NewtCanvasJFX to not yet visible or attached group->scene->window
- attach NEWT Window before or after NewtCanvasJFX's visibility
The above is covered by unit test: TestNewtCanvasJFXGLn
This is the initial commit for JavaFX support and has been tested on
- OpenJDK 8 + OpenJFX 8
- GNU/Linux X11
|
| |
|
|\ |
|
| |
| |
| |
| | |
3.1 -> 3.2
|
| |
| |
| |
| |
| |
| |
| |
| | |
scripts/make.jogl.all.linux-aarch64-cross.sh:
New crosscompile script
build-common.xml:
Add SWT compile hack for isLinuxARM64
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
Only add the required direct interfaces / implementations
to interface / class derivations, not polluting overview in IDEs.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding QUIRK_BIT_VISIBILITY
1) More visibility detection on post ConfigureNotify events,
since the latter may not yet contain the updated visibility state
as it whould (WM bug!):
- EnterNotify
- LeaveNotify
- Disabled
- Expose
- VisibilityNotify
2) Introducing quirks.
Setting QUIRK_BIT_VISIBILITY to handle the issue where
visibility -> false could not even be set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
addNotify, e.g. by moving to other monitor
AWTCanvas removeNotify didn't cause 'local' destruction of the NEWT window,
allowing a 'recreate' w/ subsequent addNotify.
This case has been hacked-into NEWT.AWT.WindowDriver + AWTCanvas:
- suppression of window destroy events
- keeping fields/states intact in NEWT.AWT.WindowDriver
- propagating signals appropriately
Note: This is barely a working hack and not a fine piece of software :)
This AWT backend driver exists only due to historical reasons.
This hack simply proves that JAWTWindow works properly.
|
|
|
|
| |
breaks test)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
at ConfigureNotify event (2)
On gnome shell WM, sometimes KDE WM,
it has been observed that the _NET_WM_STATE_HIDDEN update (visible or invisible)
is not received at ConfigureNotify event.
Turns out the state is finally updated at FocusOut!
This change tests _NET_WM_STATE_HIDDEN visibility hint
for mapped window also for FocusIn and FocusOut events,
besides the ConfigureNotify event.
Further more, NormalState to restore a hidden but mapped
window did not work, so it is no more being sent.
We limit us here to _NET_ACTIVE_WINDOW.
2 unit tests are prepared to test this issue:
- TestGLWindows00NEWT
- TestParenting01NEWT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_NET_WM_STATE_HIDDEN; setVisible(true) not restoring from _NET_WM_STATE_HIDDEN
Using Gnome Shell 3.14.4-1~deb8u1 disclosed an issue w/ our newly utilized IconicState/_NET_WM_STATE_HIDDEN,
i.e. visibleChanged(false) was never received.
This is a regression of commit 2d837a7a7130702ad36b694875613fae77c7ef06,
which utilizes WM_CHANGE_STATE_IDX + IconicState for visibility
on top-level windows.
This bug consist out of _two_ isssue:
1) setVisible(false) IconicState not listening to _NET_WM_STATE_HIDDEN
Here, we 'listen' to _NET_WM_STATE_HIDDEN when receiving ConfigureNotify
if supported _and_ XMapWindow has been issued.
In such case existence/non-existence of _NET_WM_STATE_HIDDEN determines visibility.
Otherwise, we have wait for MapNotify/UnmapNotify.
The 'XMapWindow has been issued' criteria is tracked by new field 'JavaWindow.isMapped'
and set/cleared when we actually issue XMapWindow/XUnmapWindow!
2) setVisible(true) not restoring from _NET_WM_STATE_HIDDEN
It has been observed that restoring IconicState/_NET_WM_STATE_HIDDEN
via XMapWindow or even NormalState may not work reliably on WMs.
See <https://stackoverflow.com/questions/30192347/how-to-restore-a-window-with-xlib>
Hence we restore from this WM state via NormalState _and_ _NET_ACTIVE_WINDOW.
Both strategies seem to work well on KDE as well as on Gnome.
|
|
|
|
| |
OpenIndiana w/ old'ish gcc
|
|
|
|
| |
GL_ARB_ES3_2_compatibility -> [GL|GLContext].isGLES32Compatible()
|
|
|
|
| |
GLNameResolver: Add all known vendor extensions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update gluegen configs
+#
+# Ignored new extensions added in gl2ext.h 2015-10-06
+# see jogl/make/scripts/diff-gl2ext.sh
+# FIXME: Refine for 2.4.0
+#
+IgnoreExtension GL_KHR_no_error
+IgnoreExtension GL_EXT_YUV_target
+IgnoreExtension GL_EXT_blend_func_extended
+IgnoreExtension GL_EXT_buffer_storage
+IgnoreExtension GL_EXT_color_buffer_float
+IgnoreExtension GL_EXT_float_blend
+IgnoreExtension GL_EXT_multisampled_compatibility
+IgnoreExtension GL_EXT_post_depth_coverage
+IgnoreExtension GL_EXT_raster_multisample
+IgnoreExtension GL_EXT_sparse_texture
+IgnoreExtension GL_EXT_texture_filter_minmax
+IgnoreExtension GL_EXT_texture_sRGB_R8
+IgnoreExtension GL_EXT_texture_sRGB_RG8
+IgnoreExtension GL_OVR_multiview
+IgnoreExtension GL_OVR_multiview2
|
|
|
|
| |
Update Khronos Headers eglext.h (missed)
|
|
|
|
| |
Update Khronos Headers
|
|
|
|
| |
(index) as filename for OSX
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
visibility
Experimenting w/ no GLEventListener attached to an GLAutoDrawable,
e.g. GLWindow (onscreen), GLJPanel (fbo offscreen),
indeed on some GL implementations the default framebuffer is uninitialized
and hence shows garbage.
GLDrawableHelper.setViewportAndClear(..)
- Clear framebuffer after setting viewport
- Called from:
- public final void init(..)
- public final void reshape(..)
- Method is used independent of GLEventListener,
hence this simplifies implementation: removes 'setViewport' criteria
for init, display, reshape: it is always performed!
Note: We only attempt to help against leaking un-initialized framebuffer content
not against user-app faults, we do not clear a 2nd-buffer (double-buffering).
Note: We may still be late at resize, i.e. small noisy flickering might be visible.
This might be due to lack of proper vsync.
|
|
|
|
|
|
|
|
|
|
|
|
| |
TestBug816JTabbedPanelVisibilityB849B878AWT
TestBug1245JTabbedPanelCrashAWT passed as expected on
GNU/Linux, Debian8, amd64 w/:
- proprietary NV
- GL_RENDERER = Gallium 0.4 on AMD ARUBA
GL_VERSION = 3.0 Mesa 10.3.2
GL_VENDOR = X.Org
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug 1199 - Add setting to disable default window icons
Bug 1238 - Fix NPE for Window-Icon's PNGPixelRect for unresolved location, i.e. null URLConnections
Testing w/ jogl/make/scripts/tests.sh USE_BUILDDIR=1,
discloses this issue - since the icons are available in jar only.
Handling all unresolved resources, i.e. null URLConnection,
is required.
Further more, the icon list passed via property 'newt.window.icons'
shall be separated by comma as well.
This allows passing the list via scripts more conveniently.
-Dnewt.window.icons="newt/data/jogamp-16x16.png,newt/data/jogamp-32x32.png"
+++
Bug 1199 - Add setting to disable default window icons
This patch also allows disabling JogAmp's own window icons
by simply defining a non-existing location, i.e.
-Dnewt.window.icons="null,null"
|
|
|
|
|
|
|
|
| |
d78bb1be0a6290cb94918b21865a023c01825048
- Skip relative lookup for IOUtil.ClassResources using 'asset' only (from JAR file)
- Tested w/ jar file and build-dir, see scripts/tests.sh 'USE_BUILDDIR'
|
|
|
|
|
|
|
|
|
| |
Adding 'imageTarget', i.e. GL target for this texture or its sub-components if cubemap
The imageTarget preserves the used 2D image type
for the 2D Texture coordinates.
Note: 'Texture.updateImage(final GL gl, final TextureData data, final int targetOverride)'
needs an overhaul targeted for 2.4.0.
|
|
|
|
|
|
|
|
|
|
| |
Translucency Windows >= 8
Reverting 'clear backrgound' portion of commit f607c0148736fa198fb91b60123824e53366022e.
It has been identified, that Windows does initialize onscreen windows (i.e. w/ white/DESKTOP color).
This is also required for allowing translucent windows,
since clearing the background intefers on Windows >= 8 (undecorated windows).
|