Re: deadlock between AppKit main thread and AWT event thread in JDK 17

else is > affected. > > So a test case might have helped more than the words. > > "My Java code running on the AWT thread starts a secondary Java run loop" > > I presume you mean using standard API? Doing something like calling > https://docs.oracle.com/en/ja

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

ing up this > mode in a 2ndary run loop in some situations is really an implementation > choice and I wouldn't > know where to expose it even if it were something appropriate to do. > I'd sooner find a way to dispense with it entirely. > In fact there is some provision when doin

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

To avoid this deadlock, the run loop name is required when using the NSObject method performSelectorOnMainThread:withObject:waitUntilDone:modes: JNF calls this method with the “old” run loop name.

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

both threads are running a nested run loop, but the conditions for exiting those run loops are not met. The run loop name used by AWT needs to be part of the public API of the JDK. > On Jun 28, 2021, at 7:16 AM, Michael Hall wrote: > > > >> On Jun 28, 2021, at 9:03 AM,

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

been a source of problems for a long time. I don’t suppose there is any way that Java can respond to these requests without running code on the AWT event thread? > On Jun 28, 2021, at 6:29 AM, Michael Hall wrote: > > > >> On Jun 28, 2021, at 7:51 AM, Alan Snyder wro

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

sounds like a gratuitous change. > On Jun 27, 2021, at 10:24 AM, Alan Snyder wrote: > > I have a program that reliably deadlocks when run on JDK 17, but not on JDK > 16 (although that may be due to timing differences, so it may not imply a new > bug). > > It’s a fairly

deadlock between AppKit main thread and AWT event thread in JDK 17

I have a program that reliably deadlocks when run on JDK 17, but not on JDK 16 (although that may be due to timing differences, so it may not imply a new bug). It’s a fairly complicated situation. On the AWT thread, my program calls native code that displays a native file dialog. My Java code s

Re: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

Ushakov wrote: > >> Set black color for underlying window background to perform correct blending >> operations in metal with window surface destination > >> _Mailing list message from [Alan Snyder](mailto:javali...@cbfiddle.com) on >> [awt-dev](mailto:awt-...@mail.

Re: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

Could the flashing problem be related to the timing problem described in JDK-8209329 ? I have noticed occasional red flashes using Metal, which I suspect are caused by trying to render uninitialized data. (I’m guessing that the red is a debugging

Re: RFR: 8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible

From the CSR review: > No, AFAIK, we don't have any javadoc cocerning these properties. I suppose > it's OK because they control platform specific window properties and rich > client applications heavily depend on them. Without such properties java > client applications use some hacks with JNA

Re: RFR: 8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible

Is this property (and others like it) documented somewhere application developers will look? > On Apr 9, 2021, at 2:57 PM, Alexey Ushakov wrote: > > Implemented apple.awt.windowTitleVisible property to control window title > visibility > > - > > Commit messages: > - 8265005: Int

Re: Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

I use moveToTrash and revealInFinder, but only with JDK 8. In later JDKs I use Desktop.moveToTrash and browseFileDirectory. > On Mar 18, 2021, at 2:20 PM, Michael Hall wrote: > > > >> On Mar 18, 2021, at 3:29 PM, Philip Race wrote: >> >> I think this is because of https://bugs.openjdk.java.

Re: RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code [v7]

t; under the GPL2+CP ... > but there's no thought of delivering it like we deliver jni.h with the binary > JDK distribution. > > -phil. > > On 12/18/20, 4:23 PM, Alan Snyder wrote: >> I use JNF in my own (non-JDK) code, and I assume others do also. >> >> Will

Re: RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code [v7]

I use JNF in my own (non-JDK) code, and I assume others do also. Will the macOS JNI support functions and macros you want to use in the JDK be available for use in non-JDK code?

Re: EA8 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted

> On Dec 16, 2020, at 11:57 PM, Philip Race wrote: > > To anyone who has a mac still running 10.12 - we don't expect Metal to run > (it requires at least 10.13 > and maybe even later by the time it is final) but we would like confirmation > that nothing in Metal > prevents OpenGL running on o

Re: RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code [v6]

I hesitate to butt into this discussion, but it seems like a lot of work is being done that runs the risk of creating regressions. Are people aware that JNF has been open-sourced? Pardon me if this is well known, but I have not seen any discussion of it here. Alan > On Dec 17, 2020, at 6:3

Re: [14] Review Request: 8231438 [macos] The dark mode is not supported yet

Is there a bug report for that? :-) > On Oct 10, 2019, at 10:36 AM, Sergey Bylokhov > wrote: > > On 10/10/19 10:16 am, Alan Snyder wrote: >> The root problem is that the Info.plist for an executable is baked into the >> executable, and because all Java programs run f

Re: [14] Review Request: 8231438 [macos] The dark mode is not supported yet

> On Oct 10, 2019, at 9:53 AM, Sergey Bylokhov > wrote: > > The problem with "NSRequiresAquaSystemAppearance" is that it is ignored for > non-bundled > applications(if java runs from the command line) AFAIK, it is not ignored. The root problem is that the In

Re: [14] Review Request: 8231438 [macos] The dark mode is not supported yet

> On Oct 10, 2019, at 9:53 AM, Sergey Bylokhov > wrote: > > The problem with "NSRequiresAquaSystemAppearance" is that it is ignored for > non-bundled > applications(if java runs from the command line) AFAIK, it is not ignored. The root problem is that the Info.plist for an executable is bake

Re: [14] Review Request: 8231438 [macos] The dark mode is not supported yet

> On Oct 8, 2019, at 6:35 PM, Sergey Bylokhov > wrote: > > On 9/27/19 8:29 am, Alan Snyder wrote: >> It would be presumptuous for the JDK to assume that all Java desktop >> applications on macOS use AWT/Swing, much less a particular Swing LAF, and >> therefore incor

Re: [14] Review Request: 8231438 [macos] The dark mode is not supported yet

. > I need to double-check this. > > On 9/26/19 11:00 pm, Alan Snyder wrote: >> No, it works on a modified JDK 12 whose linked SDK version is 10.14 (or as a >> bundled app with NSRequiresAquaSystemAppearance = NO). >>> On Sep 26, 2019, at 10:52 PM, Sergey Bylokhov >

Re: [14] Review Request: 8231438 [macos] The dark mode is not supported yet

No, it works on a modified JDK 12 whose linked SDK version is 10.14 (or as a bundled app with NSRequiresAquaSystemAppearance = NO). > On Sep 26, 2019, at 10:52 PM, Sergey Bylokhov > wrote: > > On 9/26/19 6:17 pm, Alan Snyder wrote: >> I have a LAF that supports dark mode,

Re: [14] Review Request: 8231438 [macos] The dark mode is not supported yet

I have a LAF that supports dark mode, so I need this new behavior to be configurable. When using my LAF, the (user selected) default appearance should continue to be used. Alan > On Sep 26, 2019, at 5:38 PM, Sergey Bylokhov > wrote: > > Hello. > Please review the fix for JDK 14. > > Bug

Re: creating an ActionEvent with modifiers from an InputEvent

vent and reuse the new constants from the InputEvent, conversion might > be done in the constructor of ActionEvent. > > On 28/10/2018 13:33, Alan Snyder wrote: >> ActionEvent defines four modifier bits for SHIFT, CTRL, META, and ALT that >> coincidentally (not really, but dis

Re: creating an ActionEvent with modifiers from an InputEvent

suit your needs? > > Thank you, > Denis > > On Sun, Oct 28, 2018 at 11:33 PM Alan Snyder <mailto:javali...@cbfiddle.com>> wrote: > ActionEvent defines four modifier bits for SHIFT, CTRL, META, and ALT that > coincidentally (not really, but distinct static var

creating an ActionEvent with modifiers from an InputEvent

ActionEvent defines four modifier bits for SHIFT, CTRL, META, and ALT that coincidentally (not really, but distinct static variables are used, so how would one know for sure?) match modifier bits defined by InputEvent/Event. Oddly, the latter modifier bits were deprecated in JDK 9, as was the me

Re: RFR: [12] JDK-8211301: [macos] support full window content options

edExitedEventsForAllWindows] will > access cocoa components and should be use on Appkit. > > I think that you can move this new code to the block above and drop > shouldWait. > > > On 11/10/2018 09:03, Alan Snyder wrote: >> A reminder... >>> Please review the

Re: RFR: [12] JDK-8211301: [macos] support full window content options

A reminder... > Please review the following change to the macOS AWT: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211301 > Revision: http://cr.openjdk.java.net/~alans/8211301/webrev.00/ > > This change allows applications on macOS to configure windows to use the full > window content view

RFR: [12] JDK-8211301: [macos] support full window content options

Please review the following change to the macOS AWT: Bug: https://bugs.openjdk.java.net/browse/JDK-8211301 Revision: http://cr.openjdk.java.net/~alans/8211301/webrev.00/ This change allows applications on macOS to configure windows to use the full window content view option and the transparent t

questions about JDK-8181910 [macos] Support dark title bars on macOS

I gather that this change was reverted, but why does the bug report [1] not refect that? Also, I believe the proposed change is incorrect, above and beyond its build-breaking feature. (1) It installs the appearances NSAppearanceNameVibrantLight and NSAppearanceNameVibrantDark, which are inappr

[12] RFR: JDK-8146310 [macosx] setDefaultMenuBar does not initialize screen menu bar

Please review this bug fix: http://cr.openjdk.java.net/~alans/8146310/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8146310 The root of the problem is that the code to install the de

Re: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors

Please review this revised webrev, which contains changes to the test program per Sergey’s comments. Thank you. Alan http://cr.openjdk.java.net/~serb/alans/8194327/webrev.02 https://bugs.openjdk.java.net/browse/JDK-8194327

Re: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors

> On Apr 17, 2018, at 6:36 PM, Sergey Bylokhov > wrote: > > It is strange that it is visible only in case of color_panel, maybe it is > possible to simplify the testcase and replace color_panel by some other > NSWIndow? Not strange. The color panel is the only window in the test that support

Re: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors

on the problem list until the NSApplication problem is solved. Regards, Alan > On Apr 10, 2018, at 11:39 AM, Alan Snyder wrote: > > Hi Sergey, > > I can use System Preferences instead of Finder to avoid problems with > pre-existing windows and utility panels coveri

Re: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors

KeyWindow.main() > and pass some flag to it) > > > On 05/04/2018 16:15, Alan Snyder wrote: >> Thank you for your comments. Here is the updated webrev: >> http://cr.openjdk.java.net/~serb/alans/8194327/webrev.01/ >> <http://cr.openjdk.java.net/~serb/alans/8194327/w

Re: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors

Test.java"). > BUILD_JDK_JTREG_LIBRARIES_LIBS_libtest819432 > > On 02/04/2018 19:35, Alan Snyder wrote: >> Please review the following change to the macOS AWT. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 >> Webrev: http://cr.openjdk.java.net/~serb/alans/81

RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors

Please review the following change to the macOS AWT. Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ The goal of this change is to allow a Java desktop application on macOS to properly coexist with a native utility panel, su

[11] Review Request: 8196322: [macosx] When the screen menu bar is used, clearing the default menu bar should permit AWT shutdown

Hello, Please review the following bug fix. Thank you. Alan Bug: https://bugs.openjdk.java.net/browse/JDK-8196322 webrev: http://cr.openjdk.java.net/~serb/alans/8196322/webrev.00/

font attributes

If I run the following code (on macOS), I get no useful information. Font[] fonts = ge.getAllFonts(); for (Font f : fonts) { String family = f.getFamily(); if ("Lato".equals(family)) { Map attributeMap = f.getAttributes(); Object o = attributeMap.get(TextAttribute.WEIGHT); System.err.print

Re: Why was JDK-8188085 closed? (non-English Java apps broken on High Sierra, menubar missing)

What I notice is that on 10.12, the directory /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources contains many DefaultApp.nib files, but on 10.13, there is only one. On 10.12: ./ar.lproj/DefaultApp.nib ./ca.lproj/DefaultApp.nib ./cs.lproj/DefaultApp.nib ./da.lproj/DefaultApp.nib .

Re: no mouse released event after window hidden on macOS

JDK-8171305 > On Dec 14, 2016, at 10:19 AM, Sergey Bylokhov > wrote: > > Hi, Alan. >> >> By my reading of the spec >> , >> this is a bug. >> >> Shoul

no mouse released event after window hidden on macOS

I notice this comment in LWWindowPeer: // TODO: currently, mouse released event goes to the same component // that received corresponding mouse pressed event. For most cases, // it's OK, however, we need to make sure that our behavior is consistent // with 1.6 for cases where component in question

Re: thoughts on multiresolution images

> On Mar 11, 2016, at 6:27 AM, Alexander Scherbatiy > wrote: > > > Hello Alan, > > Thank you for the feedback. > > On 04/03/16 19:59, Alan Snyder wrote: >> I am writing to share some thoughts based on recent experience using >> multiresolution

thoughts on multiresolution images

I am writing to share some thoughts based on recent experience using multiresolution images. My experience was not entirely pleasant. I am using JDK 8, although I see no relevant differences in JDK 9. One of the critical issues using multiresolution images is that the selection of a specific im

Fwd: update on JDK-8046290 (garbage pixels on OS X) -- without the screen shots

Begin forwarded message:From: Alan Snyder <javali...@cbfiddle.com>Subject: update on JDK-8046290 (garbage pixels on OS X)Date: November 29, 2015 at 11:39:12 AM PSTTo: Sergey Bylokhov <sergey.bylok...@oracle.com>Cc: awt-dev@openjdk.java.netI believe I have encountered this previously

design question regarding UI defaults and painting

I am curious about a design decision that was made in the implementation of textured window backgrounds in the Aqua LAF/AWT. In a nutshell, a textured window background is an optional NSWindow background style that involves gradients. Textured windows are requested in Java using a window client

Fwd: creating images using native code

Is this the right place to ask this question? Unless my concerns are misguided, is seems that a public API is needed to replace uses of the internal API. Alan > Begin forwarded message: > > From: Alan Snyder > Subject: creating images using native code > Date: August 11,

creating images using native code

I am currently creating images with data provided by native code by capturing the data in an int array then using that array to construct a DataBufferInt which is used to create a WritableRaster which is used to create a BufferedImage. That seems to work fine, except that looking at the code it

Re: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

I am commenting on your suggestion that I can determine which display the image will displayed on. > On Jul 15, 2015, at 7:42 AM, Alexander Scherbatiy > wrote: > > On 7/15/2015 5:09 PM, Alan Snyder wrote: >> >> It seems you are making an assumption that the cod

Re: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

supporting a HiDPI display. I am assuming this capability already exists to support toolkit images. It would be nice to make that capability available to applications. Alan > On Jul 15, 2015, at 4:07 AM, Alexander Scherbatiy > wrote: > > On 7/14/2015 3:18 AM, Alan Snyder wrote:

Re: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

I have a concern about how custom multiresolution images are supported based on a problem I ran into using the JDK 8 classes, which are similar. The problem is that the selection of a variant image happens during painting. That is a very bad time to actually try to render an image, if one is in

Re: internal API usage: sun.awt.AppContext

s should > work since there will be a class per classloader. > If necessary you can roll your own that just uses the ThreadGroup > as a key to get to a map .. that's what it amounts to. > > -phil. > > On 06/02/2015 10:37 AM, Alan Snyder wrote: >&g

Re: internal API usage: sun.awt.AppContext

Is this the proper forum for asking this question? I have not seen any reply. > On May 28, 2015, at 7:13 PM, Alan Snyder wrote: > > I am using code — a custom Swing look and feel — that uses the > getAppContext(), get(), put(), and remove() methods of sun.awt.AppContext

internal API usage: sun.awt.AppContext

I am using code — a custom Swing look and feel — that uses the getAppContext(), get(), put(), and remove() methods of sun.awt.AppContext to store configuration data. Since the look and feel is registered by UIManager using the same mechanism, this seems like the right way to store configuration

Re: internal API usage: sun.awt.CausedFocusEvent

Thank you. Alan > On May 15, 2015, at 7:13 AM, Anton V. Tarasov > wrote: > > Hi Alan, > > Appropriate RFE is targeted to jdk9: > > https://bugs.openjdk.java.net/browse/JDK-8080395 > > Regards, > Anton. > > On 13.05.2015 20:40,

internal API usage: sun.awt.CausedFocusEvent

I have been using sun.awt.CausedFocusEvent to implement special behavior in response to an explicit user-initiated focus traversal to a component. The main point is that I want to inhibit this behavior for all other kinds of focus gained events. Will there be some way of doing this in JDK9?

selecting an image resolution variant

I’ve run into something that may be an issue. The code to select a variant image in MultiResolutionToolkitImage looks like this: public Image getResolutionVariant(int width, int height) { return ((width <= getWidth() && height <= getHeight())) ? this : resolutionVaria

HiDPI and FontRenderContext

I’m curious about the behavior of FontRenderContext.getTransform() in HiDPI mode. The documentation says it maps points to pixels, but it doesn’t say what kind of pixels. I would have assumed virtual pixels (AWT pixels) for consistency with the rest of the API, but in fact I get a 2x mapping on