summaryrefslogtreecommitdiffstats
path: root/src/newt
Commit message (Collapse)AuthorAgeFilesLines
* Bug 1374: NEWT/AWT: Annotation regarding general High-DPI for even non ↵Sven Gothel2020-01-172-0/+18
| | | | | | | | | | | | | | | 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.
* Bug 1423: NEWT Child Window on OSX: Don't use parent derived location in ↵Sven Gothel2020-01-161-15/+20
| | | | | | fullscreen mode WindowDriver OSX: useParent(..) -> useParentLocation(..) and add !isFullscreen() as a criteria to use the parent derived location.
* NEWT: Enhance FullScreen.run DEBUG output a bit; NEWTDemoListener ignore ↵Sven Gothel2020-01-162-2/+10
| | | | input if not visible.
* Bug 1422: NewtCanvasSWT: Handle case of !OSX && DPIUtil.getScalingFactor() > 1Sven Gothel2020-01-161-7/+17
| | | | | | | | NewtCanvasSWT.SWTNativeWindow's surfaceSize in pixel units shall only return scaled-up windowUnits using SWTAccessor.deviceZoomScaleUp(..) for !OSX and potentially auto scaled-up pixelUnits to passthrough (OSX). See detailed API doc to NewtCanvasSWT.newtScaleUp(..)
* Bug 1422: Use own deviceZoomScaleUp(..) disregarding higher-toolkit's ↵Sven Gothel2020-01-161-7/+21
| | | | | | | | | | | | | | | | | | | 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).
* NEWT.Window: Refine string representation, renamed append(StringBuilder) -> ↵Sven Gothel2020-01-164-89/+162
| | | | | | | toString(..), added toSimpleString(..) This also revised commit f56adf14deadd4ee8f434ea1293e27bcafdf2a90 Window API addition of 'append(StringBuilder)', which has been renamed to 'toString(StringBuilder)' as aligned to out other classes.
* Bug 1422: Emulate DPI Scaling on non-native DPI autoscale platforms (!MacOS)Sven Gothel2020-01-151-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | Bug 1422 shows that it seems to be desired to emulate DPI scaling where the native toolkit does not implmement the same. On GTK, DPIUtil.mapDPIToZoom (int dpi) reads: double zoom = (double) dpi * 100 / 96; int roundedZoom = (int) Math.round (zoom); return roundedZoom; While having dpi calculated as: dpi = 96 * GDK.gdk_monitor_get_scale_factor(monitor); Well, this seems to exist to allow 96 dpi fixed layout to 'look' OK on high-dpi screens. However, you get in trouble if you layout high-dpi aware, i.e. using percentages etc. There is one exception: If DPIUtil.useCairoAutoScale() is true, scalingFactor is 1f and hence the scaling emulation dropped. 'DPIUtil.setUseCairoAutoScale((sx[0]*100) == scaleFactor || OS.isGNOME);'
* Bug 1421: NEWT OSX Invisible: Refine 'Fake invisible child window' ↵Sven Gothel2020-01-151-1/+2
| | | | | | | off-viewport position Ensure it stays out of sight by moving it to 2x width/height of viewport. Otherwise one could see the child window moving from lower-right to upper-left ;-)
* Bug 1421: NEWTCanvasSWT: No action on SWT.Activate, use SWT.FocusIn. Also ↵Sven Gothel2020-01-151-83/+119
| | | | | | remove all SWT listener on dispose. Additionally print more details about the newtChild's state in DEBUG mode.
* NEWT.Window: Add 'StringBuilder append(StringBuilder sb)' supporting ↵Sven Gothel2020-01-153-6/+26
| | | | building custom efficient presentations
* Bug 1421: NEWT OSX Invisible: Implement 'Fake invisible child window'Sven Gothel2020-01-153-13/+40
| | | | | | | | | | | | | | | | | | | 'Fake invisible child window' is implemented by simply moving the window out of sight (viewport). - orderOut0 needs to use '[mWin orderWindow: NSWindowBelow relativeTo:..' parentWindow instead of '[mWin orderBack:..', otherwise the whole parent application gets invisible w/ SWT ;-) - NewtNSWindow may also needs to use parent's Screen instance if moved offscreen, as the own Screen is invalid (zero size) in this case. - WindowDriver: Adding special treatment for 'Fake invisible child window' (tagged as such): -- reconfigureWindowImpl: setWindowClientTopLeftPointAndSize0(..) will be called using the viewport's max position -> out of sight. -- screenPositionChanged: ignore the 'new' position -- sizeChanged: ignore the 'new' size This sensitive NEWT change set shall benefit other toolkits being used as parentWindow besides SWT, as this behavior is the same across MacOS.
* Bug 1421: NEWT OSX Invisible: Fix orderOut0 re commit ↵Sven Gothel2020-01-151-2/+3
| | | | | | | | | | d92dc518eb891f2d125a8136efd6ed603d74a6e9 We also cannot use 'mWin orderWindow: NSWindowOut relativeTo:..]' as it also removes the child-NSWindow from its parent like 'orderOut'. Hence only use 'orderBack' to keep the relationship inplace. Fake invisible child window is in progress, i.e. moving it out of the overal viewport (all screens).
* NEWT OSX MacWindow.c: Add parentWindow to DBG_PRINTSven Gothel2020-01-151-16/+25
|
* NEWT OSX/IOS WindowDriver: Minor cleanup of local var usage (prefer reuse); ↵Sven Gothel2020-01-142-19/+19
| | | | reconfig: Only orderOut w/ valid window-handle
* Bug 1421: NEWT OSX Invisible: Refining child window visibility setting, ↵Sven Gothel2020-01-142-6/+28
| | | | | | | | | | | | | | | | | | | 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).
* Bug 1421 Related: Handle SWT Events: Activate (focus), Show and Hide.Sven Gothel2020-01-131-0/+9
| | | | | Show and Hide handling resolves TabFolder layout, i.e. hiding the 'hidden' and showing the current tab.
* Bug 1421, Bug 1358, Bug 969, Bug 672: Fix NEWT's coordinate conversion on ↵Sven Gothel2020-01-136-167/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* NativeWindow Point.set*(..): Return instance for scaling (chaining)Sven Gothel2020-01-121-2/+1
|
* NEWT JVM_JNI8: Adapt to native library separation (head, drm) of commit ↵Sven Gothel2020-01-091-2/+9
| | | | | | | | | b91c680fb93a03720ff9fcb39cf052cfe8d40e76 See commit b91c680fb93a03720ff9fcb39cf052cfe8d40e76 To support static libraries JEP 178, we have to provide JNI_OnLoad_<libname> etc. Hence change and add function entries accordingly.
* Bug 1358: Merely simplifying the non MacOS getClientAreaInPixels() code pathSven Gothel2020-01-061-2/+6
| | | | | | This also demonstrates that on non MacOS, SWT's scale-factor is artificially imposed on the actual pixel-units, as SWT's getClientArea() is simply returning: DPIUtil.autoScaleDown(getClientAreaInPixels())
* Bug 1421: Tackle wrong position of TabFolder, SashForm etcSven Gothel2020-01-061-16/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | getClientArea() on MacOS produces a 'difficult' result regarding the position, which usually is returned as zero. Using a zero position issues the bug w/ SashForm, where the offset doesn't seems to be covered by the native NSView nor an SWT parent Composition. Then using the getLocation() as is (i.e. the view's frame position) may also cause issues with the TabFolder, as it includes the tab's trimming. Here the native NSView 's position includes the tab's trimming, gladly the parent (TabFolder or a Composition)'s clientArea includes this offset. Therefor, as a testbed - on OSX, getClientArea2(..) returns - position: getLocation() - getParent().getClientArea().position - size: getSize() This at least works OK'sh using - no special layout parent - TabFolder - SashForm ++++ Unit test TestGLCanvasSWTNewtCanvasSWTPosInTabs: Adding 'addComposite' to test matrix. 'addComposite' wraps our GLCanvas or NewtCanvasSWT into a Composite instead of adding it directly into the layouting parent. It demonstrates an issue with the new test 'test32_NewtCanvasSWTTabSashGLWComp', i.e. the NewtCanvasSWT is shown on the left as the SashForm's offset is being dropped. Summary: - No more issues with High-DPI pixelScale observed! - GLCanvas is being most well layouted, no issues in tests - NewtCanvasSWT may show severe positioning issues -> test32_NewtCanvasSWTTabSashGLWComp - NewtCanvasSWT always shows a small positioning offset into the lower-right corner w/ overlapping - NewtCanvasSWT overall positioning is not perfectly understood - NewtCanvasSWT misses to hide the NEWT child when changing tabs in TabFolder
* Bug 1421: Minor commentingSven Gothel2020-01-061-2/+1
|
* Bug 1421: Minor cleanup / commentingSven Gothel2020-01-061-9/+8
|
* Bug 1421: Move Bug 1362 'setBackground(..)' fix before potential ↵Sven Gothel2020-01-061-4/+4
| | | | 'setNEWTChild(..)'
* SWT GLCanvas: Fix NPE in DEBUG mode; NewtCanvasSWT: Resurect comment in ↵Sven Gothel2020-01-061-1/+2
| | | | setBounds(..)
* Bug 1358: MacOS NEWT WindowDriver / NewtCanvasSWT High-DPI:Sven Gothel2020-01-041-7/+14
| | | | | | | | | | | | | | | | | 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].
* Bug 1358: NewtCanvasSWT High-DPI: Propagate pixelScale to NEWT-Child and ↵Sven Gothel2020-01-041-3/+39
| | | | | | | | | utilize it for convertTo*Units(..) Detected pixelScale on SWT should be propagated to the NEWT Child using 'newtChild.setSurfaceScale(pixelScale)' to allow an impact. Also utilize computed pixel for converTo*Units(..) implementation.
* Bug 1358: NewtCanvasSWT High-DPI: Use window-units where required instead of ↵Sven Gothel2020-01-041-8/+8
| | | | | | | | pixel-units Commit ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0 did one thing wrong: Using the pixel-unit size for NEWT child window operations where window-units are required.
* Bug 1393: MacOS: getLocationOnScreen w/ JAWT Parent: Use parent's unblocking ↵Sven Gothel2020-01-021-1/+13
| | | | | | | | | | | | | | | 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.
* Bug 1156: Seperate DRM/GBM NEWT native library from main head NEWT native ↵Sven Gothel2019-12-2512-13/+33
| | | | | | | | | | | | | | | | 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.
* Bug 1156: NEWT WindowDriver: Handle case with requested ↵Sven Gothel2019-12-091-2/+2
| | | | CapabilitiesImmutable not being GLCapabilitiesImmutable
* Bug 1156: NEWT Window: Better handling of fixed console case: Not resizable ↵Sven Gothel2019-12-0914-30/+142
| | | | | | | | | | | | | | | | | | | | | | | and not repositionable. Our two fixed size and position console cases 'bcm.egl' and 'egl.gbm' (drm.gbm) only operate in a console like fullscreen mode. We should earmark and expose this behavior, as well as handle it by not waiting for a position / size and not attempting to change position and size. Reducing WindowImpl.minimumReconfigStateMask to bare minimum values: STATE_MASK_VISIBLE | STATE_MASK_FOCUSED; New WindowImpl.mutableSizePosReconfigStateMask extends WindowImpl.minimumReconfigStateMask, representing previous values: STATE_MASK_VISIBLE | STATE_MASK_FOCUSED | STATE_MASK_FULLSCREEN | STATE_MASK_RESIZABLE | STATE_MASK_REPOSITIONABLE; All WindowDriver implementations previously using WindowImpl.minimumReconfigStateMask are now using WindowImpl.mutableSizePosReconfigStateMask but the explicit console driver named above. I would have liked to add the STATE_BIT_FULLSCREEN to the current stateMask to notify this semantics, however this would have lead to more code changes as our fullscreen mode assumes to be 'on top' of the normal mode. Here the normal mode is essentially fullscreen and no back/forth fullscreen setting is useful or allowed. Therefore, both fixed size & position console driver won't expose themselves as being in fullscreen mode.
* Bug 1393: Apply 12eed5d38616d23b6e8e2e5b497dfc2f54d90c90 to IOS, avoiding ↵Sven Gothel2019-12-081-4/+6
| | | | AppKit/EDT deadlock for parent screen location lookup
* Bug 1393: Resolve EDT + AppKit Deadlock with native parenting: Fetch parent ↵Sven Gothel2019-12-081-4/+6
| | | | screen position directly w/o locking.
* NEWT WindowImpl: Wording in commentSven Gothel2019-12-081-1/+1
|
* Bug 1156: DRM/GBM NEWT: Clarify drmModeSetCrtc(..)'s x/y parameter and ↵Sven Gothel2019-12-072-160/+84
| | | | | | earmark spanning across monitors drmModeSetCrtc(..)'s x/y parameter are the surface's offset to be scanned out from one CRT!
* Bug 1412: Fix commit a8c2de110a2254af137a3d99007cc77e3ecd8078Sven Gothel2019-12-062-6/+11
|
* Bug 1412 - JNI: NEWT Check & Handle Exception after calling back into Java ↵Sven Gothel2019-12-061-0/+1
| | | | (NewtCommon.c)
* Bug 1413 - NEWT X11Window: NewtWindows_getFrameExtends(..) may hang on ↵Sven Gothel2019-12-063-18/+28
| | | | | | | | | | | XPeekEvent(..) The wait loop uses XPeekEvent(dpy, &e), which can block indefinite if queue is empty. Replace with timeout only _and_ only wait on CreateWindow0(..) not when queried via X11Display dispatch loop on events when it is assumed the information has been propagated already.
* Bug 1412 - JNI: NEWT Check & Handle Exception after calling back into Java ↵Sven Gothel2019-12-064-7/+57
| | | | (X11Display + X11Window)
* Bug 1410: Fix NEWT PointerIcon Lifecycle (destroy and clean references @ ↵Sven Gothel2019-12-062-10/+35
| | | | | | | | | | | 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.
* Fix regression of commit 2b899a55e365aa03aeb234187600526777c1a9acSven Gothel2019-12-061-1/+1
| | | | This bug never allowed a PointerIconImpl to be destroyed via PointerIconImpl.destroy()
* Bug 1409: GNU/Linux DRM Console: Clear stdin before exit and don't act on ↵Sven Gothel2019-12-053-3/+60
| | | | | | | | | stdin in vsync-wait-loop User input during test from the console will also end up in stdin of the console after the java application has been closed. This is not only annoying, but also a security concern, as the input gets executed if containing a CR. Further, the vsync-wait-loop shall ignore stdin.
* PointerIcon new instances are always valid ..Sven Gothel2019-12-052-7/+15
| | | | Move native handle check to pre-destruction call in PointerIconImpl.destroyOnEDT(..), unifying single destruction and all.
* Bug 1405, Bug 1406, Bug 1408: Resolution: Call ↵egl-gbmSven Gothel2019-12-051-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ReleasePrimitiveArrayCritical(..) in GetPrimitiveArrayCritical(..) code path! Now that was quite a miss, causing the bugs in the first place! The freeze was caused in the JVM, as this open GetPrimitiveArrayCritical(..) disabled the GC. This was reported via '-Xcheck:jni'. Depending on the system/jvm, the freeze may happen early or only after a while. This code path was not executed with new property 'newt.disable.PointerIcon' set, but from there to finding the missing critical release - a journey: - jstack showed "main" #1 prio=5 os_prio=0 cpu=275.71ms elapsed=51.93s allocated=9710K defined_classes=472 tid=0x00007f7084015000 nid=0x1a39 waiting on condition [0x00007f70897c2000] java.lang.Thread.State: RUNNABLE at jogamp.opengl.es3.GLES3Impl.dispatch_glUniformMatrix4fv1(Native Method) at jogamp.opengl.es3.GLES3Impl.glUniformMatrix4fv(GLES3Impl.java:2585) at jogamp.opengl.es3.GLES3Impl.glUniform(GLES3Impl.java:10713) -- said that this thread was no more running, waiting on condition .. -- glUniformMatrix4fv1 was given an array! - '-Xcheck:jni' gave: Warning: Calling other JNI functions in the scope of Get/ReleasePrimitiveArrayCritical or Get/ReleaseStringCritical -- Now it is clear that the lack of releasing the critical array, returning to Java and then calling other JNI methods caused the Warning - and eventually the freeze.
* LinuxKeyEventTracker: Factor out 'sendKeyEvent(..)' call with null check.Sven Gothel2019-12-051-12/+12
|
* NEWTDemoListener: Fix NPESven Gothel2019-12-051-4/+7
|
* Bug 1156: NEWT DRM/GBM PointerIcon: Use hotX/hotY drmModeSetCursor2(..), ↵Sven Gothel2019-12-054-30/+35
| | | | hence pass PointerIconImpl through
* Bug 1408: NEWT DRM/GBM WindowDriver: Adding glFinish() before ↵Sven Gothel2019-12-041-0/+1
| | | | | | | eglSwapBuffers(..) just in case .. This is the poor man's SYNC: glFenceSync () with glWaitSync(). However, this change did not resolve Bug 1408. Earmarked to be removed!
* Bug 1408: NEWT DisplayImpl PointerIcon: Property 'newt.disable.PointerIcon' ↵Sven Gothel2019-12-041-1/+7
| | | | disables PointerIcon usage in general.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 05:03:46 +0000