| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
c47bc86ae2ee268a1f38c5580d11f93d7f8d6e74)
- Change non static accesses to static members using declaring type
- Change indirect accesses to static members to direct accesses (accesses through subtypes)
- Add final modifier to private fields
- Add final modifier to method parameters
- Add final modifier to local variables
- Remove unnecessary casts
- Remove unnecessary '$NON-NLS$' tags
- Remove trailing white spaces on all lines
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crashes the app
The 'magic' MyNSOpenGLContext::dealloc (MacOSXWindowSystemInterface-calayer.m)
of force destroying the underlying CGLContextObj of it's associated
NSOpenGLContext as introduced as a remedy of Bug 691 is plain wrong.
It was added in commit f6e6fab2a7ddfb5c9b614cb072c27ff697629161
to mitigate the experience behavior of delayed GL context
destruction when creating/destroying them multiple times
as exposed in unit test TestGLCanvasAddRemove01SwingAWT.
While this 'hack' worked for some reason on some OSX versions,
it caused a 'access/modify after free' issue exposed under some circumstances
and crashes the application.
The actual culprit of the delayed GL context destruction is different.
The offthread CALayer detachment and hence final destruction
issued on the main-thread is _not_ issued immediately
due to some referencing holding by NSApp.
Issuing an empty event on the NSApp (thread) will wake up the thread
and release claimed resources.
This has been found while realizing that the GL context
are released if the mouse is being moved (duh!).
This issue is also known when triggering stop on the NSApp (NEWT MainThread),
same remedy has been implemented here for a long time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
surface DPI ; Add NEWT Window.getPixelsPerMM(..) to query surface DPI
With HiDPI and surface scale, we need knowledge of the native surface's pixel-scale
matching the monitor's pixel-per-millimeter value.
Preserving the queried native pixel-scale and exposing it via
ScalableSurface.getNativeSurfaceScale(..) to compute surface DPI.
Add NEWT Window.getPixelsPerMM(..) to query surface DPI.
Surface DPI is demonstrated in GraphUI's GPUUISceneGLListener0A .. and TestRulerNEWT01, etc ..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
entry, fixed NewtCanvasAWT use-case
We require the requested pixelScale in NewtCanvasAWT if the NEWT window (child)
is not yet realized, so the JAWTWindow can receive the request,
since realized/current pixelScale is still 1.
Remove return value (requested pixel scale):
- public int[] setSurfaceScale(final int[] result, final int[] pixelScale);
+ public void setSurfaceScale(final int[] pixelScale);
Add API hook to query requested pixel scale:
+ int[] getRequestedSurfaceScale(final int[] result);
Unique name for get[Current]*:
- public int[] getSurfaceScale(final int[] result);
+ public int[] getCurrentSurfaceScale(final int[] result);
|
|
|
|
|
|
|
|
|
|
|
|
| |
which also fixed JAWTWindow getSurfaceScale() issue on Windows
Let setSurfaceScale(..) return the validated requested values
and getSurfaceScale(..) always the current values.
This removes complication and solves a bug w/ JAWTWindow on Windows,
where we used 'drawable' as an indicator for 'previous locked' state.
The latter is not true since on Windows 'drawable' is set to null in unlock,
getWindowHandle() should be taken instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSX impl.
Add ScalableSurface interface
- To set pixelScale before and after realization
- To get pixelScale
- Implemented on:
- NEWT Window
- Generic impl. in WindowImpl
- OSX WindowDriver impl.
- Also propagetes pixelScale to parent JAWTWindow if offscreen (NewtCanvasAWT)
- AWT WindowDriver impl.
- JAWTWindow / OSXCalayer
- AWT GLCanvas
- AWT GLJPanel
- NEWTCanvasAWT:
- Propagates NEWT Window's pixelScale to underlying JAWTWindow
- WrappedSurface for pixelScale propagation
using offscreen drawables, i.e. GLJPanel
- Generic helper in SurfaceScaleUtils (nativewindow package)
- Fully implemented on OSX
- Capable to switch pixelScale before realization,
i.e. native-creation, as well as on-the-fly.
- Impl. uses int[2] for pixelScale to support
non-uniform scale.
Test cases:
- com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT
- com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2AWT
- com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2GLJPanelAWT
- com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NewtCanvasAWT
- Press 'x' to toggle HiDPI
- Commandline '-pixelScale <value>'
- Added basic auto unit test (setting pre-realization)
|
|
|
|
| |
EGLUpstreamSurfaceHook) to generalize ProxySurfaceImpl.getUpstreamSurface()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NativeWindow; [AWT|SWT]NewtEventFactory use NativeSurfaceHolder as source, fixes pixel unit conversion
- Add new NativeSurfaceHolder interface to GLDrawable and NativeWindow, allowing NativeSurface access (pixel unit conversion)
A NativeSurfaceHolder is e.g.:
- NativeWindow (is-a)
- NEWT [GL]Window
- GLDrawable (has-a)
- [AWT|SWT]GLCanvas
- [AWT|SWT]NewtEventFactory use NativeSurfaceHolder as source, fixes pixel unit conversion
|
|
|
|
|
|
|
|
|
|
|
| |
NativeWindow, i.e. getWindow[Width|Height]() -> get[Width|Height]()
We have distinguished pixel- and window units in commit f9a00b91dcd146c72a50237b62270f33bd0da98e
and introduced NativeWindow.getWindow[Width|Height]() and NativeSurface.getSurface[Width|Height]().
To have a unique naming scheme, we could rename all method using 'Window',
but for simplicity and since there will be no 'semantic override'
just use the simple version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NEWT Support / Fix JAWT getPixelScale deadlock
- NativeWindow/Surface/NEWT API DOC: Define Coordinate System of Window and Screen
- OSXUtil: Add getPixelScale(..) via Screen index and 'windowOrView'
- JAWTWindow/JAWTUtil.getPixelScale(..): Use pre-fetched AWT GraphicsConfiguration to solve AWT-TreeLock (deadlock)
- [Virtual] Viewport of MonitorDevice and Screen:
- Properly calculate and expose [virtual] viewport in window and pixel units
- OSX Monitor viewports in pixel units are 'reconstructed'
- Window/Viewport to Monitor selection shall be perfomed via window units (unique)
- OSX NEWT Window create/init (native): Use given size and coordinates even in fullscreen mode
Don't override by quering NSScreen coordinates, trust given values.
- Fix test cases, i.e. usage of pixel- and window-units
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refine commit f9a00b91dcd146c72a50237b62270f33bd0da98e
- Using comment tag 'FIXME HiDPI' to locate remaining issues
- Fix remaining 'getPixel*(..)' -> 'getSurface*(..)'
- UpstreamSurfaceHook
- Fix usage (one by one) of
- NativeWindow: getWindowWidth() / getWindowHeight()
- NativeSurface/GLDrawable: getSurfaceWidth() / getSurfaceHeight()
- mention window- or pixel units in API doc where required
- use 'setSurfaceSize(..)' where appropriate to match 'getSurface*()'
- GLFBODrawable
- GLOffscreenAutoDrawable
- UpstreamSurfaceHook.MutableSize
- NativeWindow's Point: Add API doc and 'Point scaleInv(..)'
- NativeSurface
Simplify new conversion methods and use single in-place storage
- 'int[] getWindowUnitXY(int[], int[])' -> 'int[] convertToWindowUnits(int[], int[])'
- 'int[] getPixelUnitXY(int[], int[])' -> 'int[] convertToPixelUnits(int[], int[])'
- NEWT Screen/Monitor
- Assume screen/window units
- TODO: Refine semantics - Monitor resolution probably is in pixel units ?!
- Including the Rectangle/Monitor association etc etc
- NEWT Window
- Add setSurfaceSize(..) for convenience
- Add 'Point convertToWindowUnits(final Point pixelUnitsAndResult)', etc ..
- All window ops are using window units (size, pos, ..),
but methods operating on the surface/drawable: windowRepaint(..) ..
- TODO: Consider changing method names 'window*(..)' to 'surface*(..)'
actually operating on surface/drawable
- Window.windowRepaint(..)
- GLAutoDrawableDelegate.windowResizedOp(..) (maybe all similar methods in here)
- NEWT Mouse/Pointer Events
- Using pixel units
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add HiDPI for AWT GLCanvas w/ OSX CALayer
Core API Change:
To support HiDPI thoroughly in JOGL (NativeWindow, JOGL, NEWT)
we need to separate window- and pixel units.
NativeWindow and NativeSurface now have distinguished
access methods for window units and pixel units.
NativeWindow: Using window units
- getWindowWidth() * NEW Method *
- getWindowHeight() * NEW Method *
- getX(), getY(), ...
NativeSurface: Using pixel units
- getWidth() -> getSurfaceWidth() * RENAMED *
- getHeight() -> getSurfaceHeight() * RENAMED *
GLDrawable: Using pixel units
- getWidth() -> getSurfaceWidth() * RENAMED, aligned w/ NativeSurface *
- getHeight() -> getSurfaceHeight() * RENAMED, aligned w/ NativeSurface *
Above changes also removes API collision w/ other windowing TK,
e.g. AWT's getWidth()/getHeight() in GLCanvas
and the same method names in GLDrawable before this change.
+++
Now preliminary 'working':
- AWT GLCanvas
- AWT GLJPanel
Tested manually on OSX w/ and w/o HiDPI Retina:
java com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2AWT -manual -noanim -time 1000000
java com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2GLJPanelAWT -manual -noanim -time 1000000
+++
TODO:
- NEWT
- Change Window.setSize(..) to use pixel units ?
- OSX HiDPI support
- Testing ..
- API refinement
|
|
|
|
| |
JAWTUtil and JAWTWindow
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AppContextInfo to mitigate related bugs, e.g. Bug 983
Bug 1004, as well as Bug 983, are caused by issueing certain AWT tasks
from a Thread which ThreadGroup is not mapped to a valid sun.awt.AppContext (AppContext).
The 'certain AWT tasks' are all quering the current EventQueue instance,
which is associated to the AppContext.
This operation will fail and cause a NullPointerException.
This workaround simply gathers a ThreadGroup
which is mapped to the desired AppContext.
This AppContext ThreadGroup is being used to launch a new Thread
which is then mapped to an AppContext and hence can issue
all AWT commands.
+++
In the Bug 1004 scenario, JAWTWindow is constructed
from within the AWT EDT, which ThreadGroup does belong to the AppContext.
Here the issue is that an AWT operation was invoked from the OSX main thread,
which itself does not belong to the AppContext.
The workaround as described above solves this issue.
+++
For Bug 983 the scenario is different, since JAWTWindow is _not_
constructed from a thread which ThreadGroup is mapped to the AppContext.
[It is also not constructed on the AWT-EDT].
It is recommended to have Java3D gathering the AppContextInfo itself early
and issues the JAWTWindow creation on an eligible thread using
AppContextInfo.invokeOnAppContextThread(..)
similar to JAWTWindow.attachSurfaceLayer(..).
This will allow removing the more intrusive remedy
of Java3D commit bdda2ac20bfef85271da764d1989ec3434d5c67a
and simply issuing the crucial commands on a proper thread.
+++
The more intrusive workaround of above commit
does not work in general at least for Bug 1004 (OSX and Applets).
While forcing the mapping of the 'alien' thread-group
to the AppContext work for the 1st launch w/ the 1st AppContext,
a second launch w/ a new AppContext will fail.
Here we did update the new AppContext knowledge in AppContextInfo,
however a NPE is received in getEventQueue() .. since the AppContext
is gathered after patching, but the EventQueue is still null.
Further more, using static knowledge of AppContext/ThreadGroup mapping
violates at least the Applet lifecycle. Here we can have one ClassLoader
with multiple AppContext - i.e. Applets.
|
|
|
|
| |
DefaultGraphicsDevice.getUniqueID(..) shall perform 'intern()' only once.
|
|
|
|
| |
headless)
|
|
|
|
| |
SurfaceUpdatedListener: Mark methods final, use volatile 'isEmpty' to bail out early @ surfaceUpdated.
|
|
|
|
| |
UpstreamSurfaceHookMutableSizePos to take position into account; WrappedWindow: invalidate and destroy - display device could be opened.
|
|
|
|
| |
AbstractGraphicsDevice/NativeWindow
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deadlock due to AWTTreeLock acquisition while add/remove AWT listener
The AWTTreeLock is acquired by Component.removeHierarchyListener
and as for _every_ AWT component, modifications shall happen on the AWT-EDT.
IMHO the user shall offload AWT modifications to the AWT-EDT
similar to what JOGL's GLCanvas and NEWTCanvasAWT does.
However, since JAWTWindow also represents a NativeWindow instance
we shall offload AWTTreeLock methods ourselves!
|
|
|
|
| |
EGLDrawableFactory.mapAvailableEGLESConfig(..): Clarify
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simplify JAWTComponentListener's HierarchyListener:
- Don't interfere w/ Component's visibility anymore!
This shall reduce sideeffects.
Utilize 'isShowing' in each Component specialization, i.e. GLCanvas.
- On SHOWING_CHANGED if a parent caused a change
of the tracked components showing state,
propagate it to the offscreen-layer!
- Remove all other complicated states!
GLCanvas, GLJPanel:
- Instead of 'isVisible()' use 'showing state',
since only the 'showing state' reflects 'true' visibility
throughout the hierarchy.
- Add HierarchyListener and track volatile showing state
to be used instead of 'isVisible'.
Using a cached showing state is more efficient
than quering 'isShowing()' all the time!
NewtCanvasAWT:
- Use 'isShowing()' instead of 'isVisible(), see above
|
|
|
|
| |
obsolete 'getPrivateGraphicsConfiguration()'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Conversion Utilities (Allowing 'arbitrary' PointerIcon data input)
Commit fe28bc125429b38cdcd016746081f4a6d521c6fd added the notion of toolkit agnostic PixelFormat and conversion utilities,
utilized and further tested by this patch.
+++
- PointerIcon is a PixelRectangle
and hence holds the decoded data.
This allows on-the-fly conversion if required
as well as recreation w/o PNG re-decoding.
- Using array-backed PointerIcon data where possible,
allowing better performance when converting PixelFormat etc.
- NEWT Display adds 'createPointerIcon(final IOUtil.ClassResources pngResource...'
method to support agnostic PointerIcon creation.
- NEWT Display adds methods to allow users to avoid PixelFormat and
Buffer NIO type forced conversion:
- PixelFormat getNativePointerIconPixelFormat()
- boolean getNativePointerIconForceDirectNIO()
+++
PNGImage -> PNGPixelRect
Deleted: com.jogamp.opengl.util.texture.spi.PNGImage
Added: com.jogamp.opengl.util.PNGPixelRect
(We hope nobody was using PNGImage directly since it was a service-plugin for TextureIO)
PNGPixelRect is a PixelRectangle
PNGPixelRect actually is implemented OpenGL agnostic,
however - since our PNGJ support lives under package 'jogamp.opengl.util.pngj'
it cannot be moved up (yet).
PNGPixelRect now handles all PixelFormat for the target format
and also added support for grayscale+alpha (2 channels).
The latter is force-converted to RGB* - similar to paletted.
Further more, PNGPixelRect allows simply passing an OutputStream to write the PNG data.
Used by: TextureIO and NEWT
+++
- OffscreenSurfaceLayer's setCursor(..) uses the agnostic PixelRectangle
instead of a PNG resource.
- AWTMisc uses the PixelRectangle to produce the AWT Cursor
and converts it to the required format.
Hence same pixels are used for NEWT and AWT pointer/cursor icon.
- TestGearsES2Newt and NewtAWTReparentingKeyAdapter 'tests'
iterate over 3 custom PointerIcon when pressed 'c'.
- JOGLNewtAppletBase uses the new custom PointerIcon
'newt/data/crosshair-lumina-trans-32x32.png', which is included in NEWT (213 bytes only).
-
|
|
|
|
|
|
|
| |
OffscreenLayerSurface PointerIcon/Visibility tasks async on AWT-EDT
setCursor(..) and hideCursor(..) must happen on the AWT-EDT w/o blocking,
otherwise we may deadlock the NEWT-EDT.
|
|
|
|
|
|
|
|
|
|
| |
OffscreenLayerSurface (OSX CALayer) w/ JAWTWindow Path
Add setCursor(..) and hideCursor() to OffscreenLayerSurface interface,
impl. in JAWTWindow w/ AWT.
This allows an OSX NEWT Window using CALayer (i.e. NewtCanvasAWT)
to have setPointerIcon(..) and setPointerVisible(..) functionality!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
visibility state not restored @ detach
Commit ebed9f0322e2a2279a525e04ee3875c9034a7f45 (fix for Bug 906) causes a regression
to fix for Bug 816, Bug 849 and Bug 889 (OSX CALayer Positioning and JAWTWindow visibility).
The commit adds the JAWTComponentListener instance 'jawtComponentListener'
to the component before it's assignment (duh!).
+++
Further more, detaching the JAWTComponentListener shall restore
the component's original 'local visibility state', which might got overridden
by it's 'hierarchyChanged' implementation.
+++
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NW.getLocationOnScreen(..) for X11 and Windows ; Allow unit test to run on all platforms.
- Reuse SWTAccessor.isOS_TYPE (public now)
- Impl NW.getLocationOnScreen(..) for X11 and Windows reusing existing native code
- Allow unit test to run on all platforms.
Note: NewtCanvasSWT unit tests require a 'wait for realized' while SWT dispatching.
Otherwise the 'sash unit test' will fail since realiziation happens later, at least on X11.
Hence extended AWTRobotUtil.waitForRealized(..) to use a 'waitAction'
which is used here w/ special SWT dispatch Runnable.
AWTRobotUtil.waitForRealized(..) operates on time-delta instead of iteration-counter,
allowing above 'waitAction' Runnable.
AWTRobotUtil.waitForRealized(..) removed 2nd 'glad.isRealized()' loop ..
|
|
|
|
| |
properly removeClosingListener() (and replace boolean state)
|
|
|
|
|
|
|
|
|
|
| |
JAWTWindow.destroy() - GLCanvas Recreation Case
In case a JAWTWindow owner recreates itself, destroying JAWTWindow must detach the
Component- and HierarchyListener from the AWT component!
Test TestBug816GLCanvasFrameHoppingB849B889AWT
shows properly detaching listener at jawtWindow destruction.
|
|
|
|
|
|
|
|
|
| |
moves between two JFrame
When JAWTWindow's visibility tracker updates component's local visibility,
it should read it's local visibility state instead 'trusting' the passed state.
Make JAWTWindow's visibility tracker DEBUG output more brief for readability.
|
|
|
|
| |
for analysis.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(again) on 'addNotify(..)' - GLCanvas in JtabbedPane disappear
Regression of commit e33e6374e0be0454f7e9732b5f897f84dbc3c4dc (Fix for Bug 729 and Bug 849) !
+++
JAWTWindow's HierarchyListener doesn't set component visible (again) on 'addNotify(..)'
It only renders the component invisible after removeNotify() which is performed implicit anyways ..
Case java.awt.event.HierarchyEvent.DISPLAYABILITY_CHANGED
shall perform similar as our java.awt.event.HierarchyEvent.SHOWING_CHANGED impl.
+++
Tested on Gnu/Linux X11 and OSX incl. re-test Bug 729 and Bug 849 unit tests.
|
|
|
|
| |
Signed-off-by: Harvey Harrison <[email protected]>
|
|
|
|
| |
Signed-off-by: Harvey Harrison <[email protected]>
|
|
|
|
| |
Signed-off-by: Harvey Harrison <[email protected]>
|
|
|
|
| |
NativeWindow's util types.
|
|
|
|
| |
allowing user to set custom tile size for performance evaluation/tweak
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
JAWTWindow snoops HierarchyEvents for SHOWING_CHANGED to
track local component's visibility state as well as it's global visibility state.
The later is determined by it's parent's visibility change.
If 'removeNotify()' is called, component's visibility is reset to it's local visibility state.
Fixes OSX CALayer component's visibility if parent's visibility changes (Bug 729).
Fixes continuous GL rendering if parent is invisible (Bug 849).
|
|
|
|
|
|
|
|
|
|
| |
top-level heavyweight Window, fixes [J]Dialog use case.
Top-level heavyweight Window's position is it's position on screen, hence stop traversing.
Thx to Emmanuel Puybaret for pointing this out.
Adding Dialog and JDialog unit tests as inspired by Emmanuel Puybaret.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A once visible CALayer (GLCanvas) must be able to become invisible w/o destruction,
e.g. as required by CardLayout's switching cards.
See unit test for Bug 532: 'TestAWTCardLayoutAnimatorStartStopBug532'
Out native 'fixCALayerLayout(..)' takes the visible state as tracked by JAWTWindow's ComponentListener
and sets our CALayer (root and sub) hidden state accordingly.
Now MacOSXJAWTWindow's layoutSurfaceLayerImpl(..) always calls down to 'fixCALayerLayout(..)'
due to update the visibility state.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'inner CALayer' is the outter AWT Window client space (content).
+++
Pseudo-Code:
p0 = c.locationOnScreen();
p0 -= c.getOutterComp.getPos();
p0 -= c.getOutterComp.getInsets();
Where 'locationOnScreen()' is:
p0 = 0/0;
while( null != c ) {
p0 += c.getPos();
}
+++
JAWTWindow.getLocationOnScreenNonBlocking(..) validated against
AWT's Component.getLocationOnScreen() - OK for all use-cases.
(Validation enabled w/ DEBUG)
All unit tests manually validated on OSX 10.7 w/ jdk7u40.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JRootPane for last position offset; AWTMisc.getInsets(..) add special JRootPane case.
Please note that we use JAWTWindow.getLocationOnScreenNonBlocking(..) to determine the
location on the screen 'only' b/c we cannot allow AWT to aquire the tree-lock!
The latter would be the case if using AWT's 'getLocationOnScreen()'.
If anybody has a more reliable implementation to achieve the same .. please provide your patch!
The following fix has been performed to fix the last issue w/ vZome.
- JAWTWindow.getLocationOnScreenNonBlocking(..) shall use JRootPane for last position offset
- w/ vZome, the frame's position was 0/0 (invalid), instead JRootPane's position is good.
Use JRootPane's position and stop traversing here (LW top-level).
- AWTMisc.getInsets(..) add special JRootPane case.
+ * Exception is JRootPane.
+ * Return it's parent's Window component's insets if available,
+ * otherwise return JRootPane's insets.<br>
+ * This is due to <i>experience</i> that <i>some</i> JRootPane's
+ * do not expose valid insets value.
-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
position from AWT component's location on screen. Track fixedFrame size of root CALayer; Add Split layout to unit test, add [manual] Applet tests.
- Fix JAWTWindow's getLocationOnScreenNonBlocking()
Skip JRootPane while traversing up to root Container.
JRootPane would duplicate the top-level container's offset (Window insets).
- Derive CALayer position from AWT component's location on screen. Add Split layout to unit test, add [manual] Applet tests.
AWT >= 7u40:
- AWT position is top-left w/ insets, where CALayer position is bottom/left from root CALayer w/o insets.
- Use getLocationOnScreenNonBlocking() to get location-on-screen w/o insets.
- Native code: flip origin
AWT < 7u40 still uses fixed position 0/0 for root and sub layer.
- Track fixedFrame size of root CALayer - MyCALayer:
- Override layoutSublayers to validate root and sub-layer pos/size
- Override setFrame to use fixedFrame, if set (similar to MyNSOpenGLLayer)
- Add Split layout to unit test, add [manual] Applet tests.
- Thx to 'jimthev' and 'Manu' for providing Applet unit tests
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of component-count, support all int types ; Add type 'BufferedImageInt' preserving the custom image-type, add note about TYPE_CUSTOM
- createBufferedImage(..) use BufferedImage type value instead of component-count, support all int types
- Support all integer data image-type, hence we need to pass image-type instead of component count (collision).
- Also pass 'properties' to allow configuring all BufferedImage parameters (just in case)
- Return BufferedImageInt to allow user to query the used image-type, see below.
- Add type 'BufferedImageInt' preserving the custom image-type, add note about TYPE_CUSTOM
- Simply extends BufferedImage w/ custom image-type, since BufferedImage's type is TYPE_CUSTOM
due to our custom storage type (see API doc comment).
Unit tests:
- Testing all integer image-type's in
- TestTiledPrintingGearsSwingAWT
- TestTiledPrintingNIOImageSwingAWT
- Disable all AA print-hints, all AWT text visible on X11.
Probably has a regression on Windows / OSX .. TBD.
|