> There are two issues here, both macOS specific. > First the original reported one that occurs when running on a shared remote > VNC type desktop on macOS. > Only a single supported display mode is returned and it is also the current > mode. > A program that simply enumerates the reported modes and tries to set them, if > it reaches the native layer, > will fail because macOS reports the same display mode it returned as valid as > now being illegal. > It does not appear to be as simple as a user's permission level since it > occurs with an admin user as well > so it probably is the case that macOS simply does not allow this shared > desktop to be changed although > there's no docs I can find > Ordinarily we would not have tried this since we test if the requested > display mode is the same as the native > one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is > allowed as meaning match > any mode that satisfies W,H,BPP. But this caused it to fail the equals test > so the code is enhanced to check for that > > Second, when creating a test it was discovered that *at least* on the > built-in retina display of a 16" macbook pro, > the system default contig is never in the list of available modes and can be > discovered only by querying the *current* mode > before any modes are changed. This beheaviour is 100% consistent no matter if > the system was just rebooted, has > an external monitor attached as well, or not, activates the discrete card, or > not. > > Since we've had code since at least 2013 that added the default mode I > suspect this has been seen before but nowhere > can I find an explanation. > > It has odd consequences like after you change the display mode, you will no > longer see the default display mode reported, > so the list of available modes is reduced by one. > But for a typical use case which doesn't re-query or more typically caches > the original display mode in order to restore it, it presents a bigger > problem that trying to restore will always fail. > > So the other thing this fix does is detect when we fail to restore the > initial mode and try again in a different way. > Only if that fails do we then throw an exception.
Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4373/files - new: https://git.openjdk.java.net/jdk/pull/4373/files/3a496412..2289c30d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=02-03 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4373.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4373/head:pull/4373 PR: https://git.openjdk.java.net/jdk/pull/4373
