| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
makeCurrent() call
Command SetNSViewCmd sets NSOpenGLContext's NSView via [NSOpenGLContext setView:]
on the main-thread as enforced since XCode 11 using SDK macosx10.15, see Bug 1398.
This command is injected into OSX's main-thread @ NSOpenGLImpl.makeCurrent(long) only if required,
i.e. issued only for a newly bound NSView and skipped for surface-less or offscreen 'surfaces'.
This operation must be performed w/o blocking other tasks locking the NativeSurface on main-thread to complete.
Since [NSOpenGLContext setView:] acquires the CGLContext lock on the main-thread,
it can't be locked by the calling thread until this task has been completed.
Command issuer NSOpenGLImpl.makeCurrent(long) will not acquire the CGLContext lock if this command is pending.
contextMadeCurrent(true) cures the potential unlocked CGLContext by issuing
a whole GLContext.release() and GLContext.makeCurrent() cycle while waiting for this command to be completed in-between.
This GLContext cycle also ensures an unlocked NativeSurface.getLock() in-between,
allowing potentially blocked other tasks on the main-thread to complete and hence this queued command to execute.
Notable test provoking critical multithreading issues is com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NewtCanvasSWT.
Notable test exposing issues with an unlocked CGLContext is com.jogamp.opengl.test.junit.jogl.glsl.TestGLSLShaderState02NEWT.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
default test behavior
SWT and OSX's UI TK have their strict threading policy we require to comply with, e.g. see Bug 1398 lately.
It doesn't help using our own MainThread vehicle to move the unit test on the OS main thread,
as this removes potential causes of deadlocks - which we intend to find and resolve.
This patch removed using MainThread altogether from our ant unit testing recipe
as well from our manual test scripts.
Unit tests are no more executed on the 'main thread'.
SWT tests are patched to comply with SWT's UI threading policy.
We also catch violations within NewtCanvasSWT and our SWT GLCanvas
to provide same behavior on all platforms.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
blocking
Set NSOpenGLContext's NSView via [NSOpenGLContext setView:]
on the main-thread as enforced since XCode 11 using SDL macosx10.15, using Runnable SetNSViewCmd.
This operation must be performed async w/o blocking to allow
other tasks locking the NativeSurface on main-thread to complete.
Further, since [NSOpenGLContext setView:] acquired the CGLContext lock,
it can't be locked until this task has been completed.
Worst case scenario for a late [NSOpenGLContext setView:] issuance
might be corrupt initial frame(s) displayed.
Since all concurrent locking is performed within JOGL,
the unlocked CGLContext window risk is only academic.
However, if native 3rd party toolkits take share control,
we might have a situation.
+++
SetNSViewCmd is issued @ makeCurrent() now as opposed to createContext(..)
and associateDrawable(true). The latter was actually late as well,
as it also happened after makeCurrent when updating the drawable
association. It also missed setting a null NSView when detached!
release() will also set a null NSView if called after associateDrawable(false).
SetNSViewCmd will only be issued if the NSView has been changed,
i.e. first makeCurrent() or changing the drawable.
If issued, makeCurrent() will not lock the underlying CGLContext
and hence allow SetNSViewCmd to perform - see above.
+++
NSViewDescriptor class structure replaces the less convenient method 'getNSViewHandle(..)',
exposing all collected drawable characteristics as fields.
NSViewDescriptor also respects a ProxySurface's OPT_UPSTREAM_SURFACELESS mode,
which results in not using any underlying NSView - similar to OPT_UPSTREAM_WINDOW_INVISIBLE.
This change ensures that all surfaceless GL operations will not use any NSView.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
native DPI toolkit aware platforms (Linux, Windows)
NEWT + NewtCanvasAWT:
Maybe create "interface ScalableSurface.Upstream {
void pixelScaleChangeNotify(final float[] curPixelScale, final float[] minPixelScale, final float[] maxPixelScale); }"
to allow downstream to notify upstream ScalableSurface implementations like NEWT's Window to act accordingly.
+++
AWT GLCanvas: Add remark where to add the potential pixel scale.
|
|
|
|
| |
input if not visible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compensation like 'DPIUtil.useCairoAutoScale()'
We can't use DPIUtil's 'autoScaleUp(..)' method on non-native DPI scaling platforms
as it uses a scale-factor of 1f if the higher toolkit compensates, i.e. 'DPIUtil.useCairoAutoScale()'.
Since NEWT uses X11 and GDI directly, which are not DPI scale-aware,
we have to drop the semnatics of 'DPIUtil.useCairoAutoScale()'
and merely use the actual 'deviceZoom'.
This was proposed by Marcel Au in the first place.
At least I understand these semantics by now.
+++
Additionally NewtCanvasSWT.SWTNativeWindow needs to return the 'deviceZoomScaleUp(..)'
values for returning its size in window- and pixel-units (surface).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commenting on child-window orderOut
Actual small change is to have child-NSWindow to use '[myWindow orderWindow: NSWindowAbove relativeTo:..'
instead of 'orderFront' in creation and use the simple 'orderFront' to set a top-level NSWindow visible.
Adding comment why we can't use 'orderOut' on child-NSWindow setting it invisible,
this is due to OSX 10.7 changes and testing detaching the child-window from its parent
causes havoc w/ SWT at least.
Hence we only issue 'mWin orderWindow: NSWindowOut relativeTo:..]' and the result is
having the child-NSWindow below the application.
This in turn will make it visible again when moving the application around,
as this child-NSWindow will no more follow the position.
Suggestion is to have this 'fake invisible' child-NSWindow to be moved
out of the overal viewport (all screens).
|
|
|
|
| |
independent UI interaction coding
|
|
|
|
|
|
| |
deadlocks on OSX and Windows
Essentially same code path as NewtCanvasSWT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacOS (fixes NewtCanvasSWT on SWT positioning)
Newt's OSX Window consist out of NSView wrapped up within its own NSWindow.
It's position is being set via its NSWindow's client-area position on screen (frame),
which we derive from NSView's client-area position.
When NEWT reparents into a new 'window',
on OSX it uses the parent's NSView and its NSWindow
to attach its own NSView and NSWindow as a subview and childwindow.
SWT's OSX implementation uses NSView's for each Compositor,
but an individual NSWindow is only established for the Shell (Window).
An oversight in Nativewindow and NEWT's coordinate translation:
'top-left view <-> top-left screen'
by missing the 'view <-> window' translation caused this whole issue.
The oversight occured as NEWT's 'view <-> window' translation
had no impact due to its 1-view to 1-window mapping.
Fixing the coordinate translation resolves the mess
for SWT and for potential other toolkits on OSX.
NewtCanvasSWT behaves same on OSX as on X11 etc finally.
|
| |
|
|
|
|
|
|
| |
TestGLCanvasSWTNewtCanvasSWTPosInTabs (2/2)
Complete merging unit tests.
|
|
|
|
| |
regardless of High-DPI
|
|
|
|
| |
layout using NewtCanvasSWT on MacOSX with High-DPI Retina
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even w/ commit fb211581fefc994d1458a2a74801dfb937170f39, propagating the SWT pixelScale to NEWT-Child,
hasPixelScale was never updated via updatePixelScale() through native callback [NSView viewDidChangeBackingProperties]!
[NSView viewDidChangeBackingProperties] not being called on [created] child windows (NewtCanvasSWT)
confused the overal pixelScale state, i.e. no hasPixelScale update via updatePixelScale(..).
This change explicitly queries OSXUtil.GetWindowPixelScale(handle) (commit e6d53e29f05a6928192f6c4a988b2aa558be8d65)for:
1) updateMaxScreenPixelScaleByWindowHandle(..), which now updates the actual hasPixelScale after native creation
and for
2) setSurfaceScale(..), which directly calls updatePixelScale(..) with the queried actual pixelScale
instead of relying on the native callback [NSView viewDidChangeBackingProperties].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lib lookup
New property 'jogl.ffmpeg.lib' may be set to 'internal',
setting PREFER_SYSTEM_LIBS:=false (default it true)
Non system internal libraries are named 'internal_<basename>',
e.g. 'internal_avutil'.
System default libraries are named '<basename>',
e.g. 'avutil'.
If PREFER_SYSTEM_LIBS is true (default),
we lookup the default library first,
then the versioned library names and last the internal library.
If PREFER_SYSTEM_LIBS is false,
we lookup the internal library first,
then the versioned library names and last the default library.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specialization
On MacOS, commit 12eed5d38616d23b6e8e2e5b497dfc2f54d90c90 replaced all
parent.getLocationOnScreen(..) calls with OSXUtil.GetLocationOnScreen(parentHandle, ..)
avoiding the EDT + Appkit Deadlock with native parenting.
On MacOS AWT and JAWT are using offscreen CALayer since Java >= 1.7.0,
therefor the MacOSXJAWTWindow's native window handle can't be used to gather
the screen position via OSXUtil.
However, the JAWT Window specialization MacOSXJAWTWindow implements a non-locking code-path
and we can decide to use it by querying the general interface OffscreenLayerOption.
|
|
|
|
|
|
|
|
|
|
|
|
| |
its destroyedShares
Picking up Tom Nuydens suggestion to utilize a WeakIdentityHashMap instead of a IdentityHashMap,
allowing destroyed GLContext to be removed from the GLContextShareSet through the GC.
TestSharedContextVBOES2NEWT5 demonstrates the use-case, having one master context
and several slaves being spawn off, killed and new sets to be spawn off.
Here the GLContextShareSet shall not hard-reference the destroyed and user-unreferenced context,
but allowing the system to GC 'em.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLProfile.computeProfileImpl(..) as of Bug 1084 is not the culprit here and its hardware criteria filter works.
The issue is commit 99a064327bf991318841c858d21d13e55d6b39db of Bug 1203,
in particular the change in GLProfile re:
"Merge computed EGL-Profile-Map (1) and Desktop-Profile-Map (2)
per device, instead of just using the last computation,
preserving and favoratizing the Desktop-Profile-Map."
Here the Desktop-Profile-Map overwrites the EGL-Profile-Map and hence
the software mapping gets used.
Indeed, this is a regression cause by the work of Bug 1203.
+++
Resolution is to revert the explicit 'union mapping'
and rely on an enhanced 'GLContextImpl.remapAvailableGLVersions(fromDevice, toDevice)' function.
Here the EGLDrawableFactory _already_ maps the EGL device's GL Versions to the 'host' device (e.g. X11).
This has to be refined so that the remap will not overwrite the 'host' device's already detected GL Versions.
That alone is enough, so that GLProfile can simply use the 'mappedEGLProfiles' of the 'host' device if detected, which already is a merged mapping of X11 host- and EGL sub-device.
In case no 'mappedEGLProfiles' are available, we simply use the 'mappedDesktopProfiles'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
library
DRM/GBM is enabled for Linux in general.
Nativewindow's 'nativewindow_drm' DRM/GBM native library is already seperated.
NEWT get its 'newt_drm' DRM/GBM native library.
NEWT's main head native library is renamed from 'newt' -> 'newt_head'
and is earmarked for further seperation similar to Nativewindow's.
At least a 'newt_wayland' will probably followup when support is added.
Goal is to remove DRM/GBM dependency for Linux X11 operation
as well as removing X11 dependency for Linux DRM/GBM operation.
|
|
|
|
|
|
|
|
|
|
| |
TestShutdownCompleteNEWT revealed that EGLDrawableFactory won't be properly
re-created within subsequent GLProfile/GLDrawableFactory initSingleton()
after a GLProfile.shutdown() call.
Hence after the shutdown() call, subsequent GLProfile have no EGLDrawableFactory available and hence may not have a default device existent in case no desktop-factory is available.
Allow EGLDrawableFactory to be re-created after a shutdown().
|
|
|
|
| |
screen position directly w/o locking.
|
|
|
|
| |
in test case
|
|
|
|
|
|
|
| |
clean ExclusiveContextThread
No, this does not resolve the issue - but is the proper test case.
ExclusiveContextBase10 also gets the preVis test.
|
|
|
|
|
|
|
|
|
|
| |
NVIDIA 440.36 using FBO
Tested with com.jogamp.opengl.test.junit.jogl.tile.TestTiledPrintingGearsNewtAWT,
which crashes in native makeCurrent of NV driver gl-core when using SurfacelessCtx.
Therefor we had to revert the commit 4fe9e1dfa67f4e5d614f48c02ad88e4cdd1ed415
enabling SurfacelessCtx with NV driver >= 430.40.
|
|
|
|
|
|
|
|
|
|
|
| |
closing)
Commit d5ba4cae824087879a4857e20961a95da04eaebb clarified and simplified the lifecycle of a PointerImpl instance, i.e. drop its resurrection in
PointerImpl.validateHandle() in favor of a hard exception.
This caused detection of subsequent PointerImpl lifecycle issues,
as instances were not fully destroyed on Display closing and
references not null'ed in Display and Screen instances.
|
| |
|
|
|
|
|
|
|
|
| |
commit 453f80e38bcb0945e7eac27a5917dce9bdc6446b added disabling the tracker,
however the NEWT usage didn't cover all mouse tracker null pointer.
Further, let's initialize and spawn off the threads only at first getSingleton() call
not at class initialization earlier.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding new classes DRMLib (gluegen of drm + gbm), DRMUtil and DRMMode GBMDummyUpstreamSurfaceHook
to new package jogamp.nativewindow.drm, allowing full awareness of DRM + GBM within NativeWindow for JOGL + NEWT.
DRMMode replaces the previous native code of collecting drmMode* attributes: active connector, used mode, encoder etc
and also supports multiple active connectors.
DRMUtil handles the global static drmFd (file descriptor), currently only the GNU/Linux DRM device is supported.
GBMDummyUpstreamSurfaceHook provides a simple dummy GBM surface.
NativeWindow provides the new nativewindow_drm.so and nativewindow-os-drm.jar,
which are included in most 'all' jar packages.
build property: setup.addNativeEGLGBM -> setup.addNativeDRMGBM
Changes NativeWindowFactory:
- TYPE_EGL_GBM -> TYPE_DRM_GBM while keeping the package ID of '.egl.gbm' for NEWT (using EGL)
- Initializing DRMUtil at initialization
Changes EGLDrawableFactory:
- Using native GBM device for the default EGL display creation instead of EGL_DEFAULT_DISPLAY.
This resolves issues as seen in Bug 1402, as well in cases w/o surfaceless support.
- GL profile mapping uses surfaceless when available for GBM,
otherwise uses createDummySurfaceImpl (dummy GBM surface via GBMDummyUpstreamSurfaceHook)
- createDummySurfaceImpl uses a dummy GBM surface via GBMDummyUpstreamSurfaceHook
- DesktopGL not available with GBM, see Bug 1401
NEWT's DRM + GBM + EGL Driver
- Using DRMLib, DRMUtil and DRMMode, removed most native code but WindowDriver swapBuffer
- ScreenDriver uses DRMMode, however currently only first connected CRT.
- WindowDriver aligns position and size to screen, positions other than 0/0 causes DRM failure
- WindowDriver reconfigure n/a
NEWT TODO:
- DRM Cursor support (mouse pointer)
- Pointer event handling
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- EGLSurface: Factor out 'eglCreate[Platform]WindowSurface'
NEWT egl.gbm.WindowDriver
-- Properly use GBM fourcc format and use as visualID
for GBM surface creation and EGL config selection
-- Create eglSurface within this class
-- Hook up GBM/DRM page flip (not working yet, no visible artifacts - no swap)
- ProxySurfaceImpl.surfaceSwap() call upstreamSurface's implementation if available
TODO: 'Permission denied' calling:
- drmSetMaster (optional)
- drmModeSetCrtc
- drmModePageFlip
|
| |
|
|
|
|
|
|
| |
GBM driver is now under egl/gbm subpackage and has been replaced by bcm_vc_iv boilerplate.
Native code is reentrant capable and cleaned up.
TODO: EGLDisplayUtil work with SharedResourceRunner
|
|
|
|
| |
Also issue the orderFront0 call within createWindow1 (aligned with IOS code)
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[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.
|
| |
|
|
|
|
| |
java.part.test.all was erroneously removed, redefined.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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.
|