Integrated: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI)
On Sun, 27 Sep 2020 22:16:22 GMT, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk. > > Old review request: > https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html > > > (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it > should be fine for > Windows 7, because it does not support different DPI for different monitors) > > > Short description: > In the multi-screen configurations when each screen have different DPI > we calculate the bounds of each monitor by these formulas: > > userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / > scaleX, deviceH / scaleY > devSpaceBounds = userX * scaleX, userY * scaleY, userW * scaleX, > userH * scaleY > > This formula makes the next configuration completely broken: > - The main screen on the left and 100% DPI > - The second screen on the right and 200% DPI > When we translate the bounds of the config from the device space to the > user's space, > the bounds of both screen overlap in the user's space, because we use > bounds of > the main screen as-is, and the X/Y of the second screen are divided by > the scaleX/Y. > > Since the screens are overlapped we cannot be sure how to translate the > user's space >coordinates to device space in the overlapped zone. > As a result => we use the wrong screen >=> got wrong coordinates in the device space > => show top-level windows/popups/tooltips/menus/etc on > the wrong screen > >The proposed solution for this bug is to change the formulas to these: > > userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / > scaleY > devSpaceBounds = userX, userY, userW * scaleX, userH * scaleY > >In other words, we should not transform the X and Y coordinates of the > screen(the top/left corner). This will >complicate the way of how we transform coordinates on the screen: user's > <--> device spaces: > >Before the fix: > > userX = deviceX * scaleX; > deviceX = userX / scaleX; > >After the fix(only the part appeared on this screen should be scaled) > > userX = screenX + (deviceX - screenX) * scaleX > deviceX = screenX + (userX - screenX) / scaleX > >Note that these new formulas are applicable only for the coordinates on > the screen such as X and Y. >If we will need to calculate the "size" such as W and H then the old > formula should be used. > >The main changes for the problem above are: >- Skip transformation of X and Y of the screen bounds: > > http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html >- A number of utility methods in java and native: > http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html > http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html > > > > Long description: > Unfortunately, the changes above are not enough to fix the problem when > different monitors > have different DPI, even if the bounds are *NOT* overlapped. > >- Currently, when we try to set the bounds of the window, we manually > convert it in "java" to the > expected device position based on the current GraphicsConfiguration of > the peer, and then > additionally, tweak it in native using the device scale stored in native > code. Unfortunately > this two scale might not be in sync:(after we use the > GraphicsConfiguration scale in peer, > the config might be changed and the tweak in native will use a different > screen). > > As a fix I have moved all transformation from the peer to the native > code, it will be executed > on the toolkit thread: > See the change in WWindowPeer.setBounds() and awt_Window.cpp > AwtWindow::Reshape > > http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html > > http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html > I think at some point we should delete all transformation in java, and > apply it in the native code only. > > >- We had a special code that tracked the dragging of the window by the > user from one screen to another, > and change the size of the window only when the user stops the drag > operation. I've proposed to use standard Windows > machinery for that via WM_DPICHANGED: > https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged > As a result, Windows will provide the "best" windows bounds on
Re: RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
On Tue, 10 Nov 2020 19:35:58 GMT, Alexey Ivanov wrote: >> I'll fix it and also merge the master, then update the PR. > > In this case, also consider adding a space between the word and the opening > parenthesis in these _coordinates (x, y)_ and _size (w, h)_ and, probably, a > space after comma. Spaces are added. - PR: https://git.openjdk.java.net/jdk/pull/375
Re: RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v5]
> Hello. > Please review the fix for jdk. > > Old review request: > https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html > > > (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it > should be fine for > Windows 7, because it does not support different DPI for different monitors) > > > Short description: > In the multi-screen configurations when each screen have different DPI > we calculate the bounds of each monitor by these formulas: > > userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / > scaleX, deviceH / scaleY > devSpaceBounds = userX * scaleX, userY * scaleY, userW * scaleX, > userH * scaleY > > This formula makes the next configuration completely broken: > - The main screen on the left and 100% DPI > - The second screen on the right and 200% DPI > When we translate the bounds of the config from the device space to the > user's space, > the bounds of both screen overlap in the user's space, because we use > bounds of > the main screen as-is, and the X/Y of the second screen are divided by > the scaleX/Y. > > Since the screens are overlapped we cannot be sure how to translate the > user's space >coordinates to device space in the overlapped zone. > As a result => we use the wrong screen >=> got wrong coordinates in the device space > => show top-level windows/popups/tooltips/menus/etc on > the wrong screen > >The proposed solution for this bug is to change the formulas to these: > > userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / > scaleY > devSpaceBounds = userX, userY, userW * scaleX, userH * scaleY > >In other words, we should not transform the X and Y coordinates of the > screen(the top/left corner). This will >complicate the way of how we transform coordinates on the screen: user's > <--> device spaces: > >Before the fix: > > userX = deviceX * scaleX; > deviceX = userX / scaleX; > >After the fix(only the part appeared on this screen should be scaled) > > userX = screenX + (deviceX - screenX) * scaleX > deviceX = screenX + (userX - screenX) / scaleX > >Note that these new formulas are applicable only for the coordinates on > the screen such as X and Y. >If we will need to calculate the "size" such as W and H then the old > formula should be used. > >The main changes for the problem above are: >- Skip transformation of X and Y of the screen bounds: > > http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html >- A number of utility methods in java and native: > http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html > http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html > > > > Long description: > Unfortunately, the changes above are not enough to fix the problem when > different monitors > have different DPI, even if the bounds are *NOT* overlapped. > >- Currently, when we try to set the bounds of the window, we manually > convert it in "java" to the > expected device position based on the current GraphicsConfiguration of > the peer, and then > additionally, tweak it in native using the device scale stored in native > code. Unfortunately > this two scale might not be in sync:(after we use the > GraphicsConfiguration scale in peer, > the config might be changed and the tweak in native will use a different > screen). > > As a fix I have moved all transformation from the peer to the native > code, it will be executed > on the toolkit thread: > See the change in WWindowPeer.setBounds() and awt_Window.cpp > AwtWindow::Reshape > > http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html > > http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html > I think at some point we should delete all transformation in java, and > apply it in the native code only. > > >- We had a special code that tracked the dragging of the window by the > user from one screen to another, > and change the size of the window only when the user stops the drag > operation. I've proposed to use standard Windows > machinery for that via WM_DPICHANGED: > https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged > As a result, Windows will provide the "best" windows bounds on the new > screen. Note that the code has a >
Integrated: JDK-8244088: [Regression] Switch of Gnome theme ends up in deadlocked UI
On Thu, 29 Oct 2020 13:14:49 GMT, Jayashree S Kumar wrote: > Issue > > https://bugs.openjdk.java.net/browse/JDK-8244088 > > Problem > > While using GTK3 java implementation, User sees a deadlock issue in UI while > trying to switch themes in gnome-tweak-tool. This pull request has now been integrated. Changeset: a7f46919 Author:Jayashree S Kumar Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/a7f46919 Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod 8244088: [Regression] Switch of Gnome theme ends up in deadlocked UI Reviewed-by: serb - PR: https://git.openjdk.java.net/jdk/pull/932
Re: RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
On Tue, 10 Nov 2020 18:40:45 GMT, Sergey Bylokhov wrote:
>> src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line
>> 357:
>>
>>> 355: * @param config the graphics configuration which bounds are
>>> requested
>>> 356: * @return the bounds of the area covered by this
>>> 357: * {@code GraphicsConfiguration} in device space(pixels).
>>
>> Suggestion:
>>
>> * {@code GraphicsConfiguration} in device space (pixels).
>> If changed here, all other similar places should be updated too to keep doc
>> comments consistent.
>
> I'll fix it and also merge the master, then update the PR.
In this case, also consider adding a space between the word and the opening
parenthesis in these _coordinates (x, y)_ and _size (w, h)_ and, probably, a
space after comma.
-
PR: https://git.openjdk.java.net/jdk/pull/375
Re: RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
On Tue, 10 Nov 2020 09:33:22 GMT, Alexey Ivanov wrote:
>> Sergey Bylokhov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 12 commits:
>>
>> - Update WindowSizeDifferentScreens.java
>> - Update ListMultipleSelectTest.java
>> - syncBounds code reformat
>> - javadoc fix for SunGraphicsEnvironment#toDeviceSpace
>> - Merge branch 'master' into JDK-8211999
>> - Apply suggestions from code review
>>
>>Co-authored-by: Aleksei Ivanov
>> <70774172+aivanov-...@users.noreply.github.com>
>> - Merge branch 'master' into JDK-8211999
>> - Update FullscreenWindowProps.java
>> - Merge branch 'master' into JDK-8211999
>> - Fix fullscreen in HiDPI mode
>> - ... and 2 more:
>> https://git.openjdk.java.net/jdk/compare/1a5e6c98...636b7cc4
>
> src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line
> 357:
>
>> 355: * @param config the graphics configuration which bounds are
>> requested
>> 356: * @return the bounds of the area covered by this
>> 357: * {@code GraphicsConfiguration} in device space(pixels).
>
> Suggestion:
>
> * {@code GraphicsConfiguration} in device space (pixels).
> If changed here, all other similar places should be updated too to keep doc
> comments consistent.
I'll fix it and also merge the master, then update the PR.
-
PR: https://git.openjdk.java.net/jdk/pull/375
Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote: >> Change looks ok from a build point of view, but I can't comment on the >> validity and implications of using this key. > > I ran a 3D lighting test that is designed to be a GPU stress test. It's a > worst case, to be sure, but it take 10 times as long to render with the > integrated GPU as it does with the discrete GPU: > > **attenuation.LightingSample: 500 large quads** > discrete GPU: 23.5 fps > integrated GPU: 2.34 fps > > In a more realistic example of drawing a large number of 2D vectors, it runs > 35% slower with the integrated GPU: > > **Vector charting test, oval clip** > discrete GPU: 41.1 fps > integrated GPU: 26.6 fps > > I see similar results in the performance numbers you listed above. > > An application developer who packages up their JDK, for example, using > jpackage, can make the decision for themselves. Application developers who > rely on the JDK as delivered will get whatever we choose as the default. So > we need to be sure that the benefit of doing this justifies the performance > hit. The difference between the two is that, if the integrated card is default then it is possible to force the discrete card if needed, but it is not possible to force the integrated card if discrete is the default. In the end, it is a laptop, it will work longer on an integrated card. - PR: https://git.openjdk.java.net/jdk/pull/1139
Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 13:24:21 GMT, Erik Joelsson wrote: >> This is a review request for the bug particularly fixed some time ago: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html >> >> In that review request it was found that the old fix does not work well in >> all cases, see: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html >> >> The current fix updates an embedded plist.info, so the java will not require >> discrete graphics by default, same as for any other applications. >> >> The discrete card will be used: >> 1. If macOS decided to enable it for some reason >> 2. If the java app sets/uses a full-screen window >> 3. If the user disable "automatic graphics switching" in the system >> preferences >> 4. If an external monitor is connected to the laptop >> >> In other cases, the integrated graphics will be used, which should be fine >> in most cases since this graphic is used/tested in the mbp 13/etc. This is >> not only about rendering performance but also about startup performance, on >> my current new laptop mbp 16 + Cataline 10.15.7 the switching >> discrete/integrated causes unexpected delays up to 10 seconds. >> >> >> Note that the new "metal" pipeline also does not require discrete graphics. >> >> The documentation for NSSupportsAutomaticGraphicsSwitching: >> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching >> >> I'll create a release note after approval. >> >> Performance numbers: >> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html >> Old review request: >> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html > > Change looks ok from a build point of view, but I can't comment on the > validity and implications of using this key. I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU: **attenuation.LightingSample: 500 large quads** discrete GPU: 23.5 fps integrated GPU: 2.34 fps In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU: **Vector charting test, oval clip** discrete GPU: 41.1 fps integrated GPU: 26.6 fps I see similar results in the performance numbers you listed above. An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit. - PR: https://git.openjdk.java.net/jdk/pull/1139
Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote: > This is a review request for the bug particularly fixed some time ago: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html > > In that review request it was found that the old fix does not work well in > all cases, see: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html > > The current fix updates an embedded plist.info, so the java will not require > discrete graphics by default, same as for any other applications. > > The discrete card will be used: > 1. If macOS decided to enable it for some reason > 2. If the java app sets/uses a full-screen window > 3. If the user disable "automatic graphics switching" in the system > preferences > 4. If an external monitor is connected to the laptop > > In other cases, the integrated graphics will be used, which should be fine in > most cases since this graphic is used/tested in the mbp 13/etc. This is not > only about rendering performance but also about startup performance, on my > current new laptop mbp 16 + Cataline 10.15.7 the switching > discrete/integrated causes unexpected delays up to 10 seconds. > > > Note that the new "metal" pipeline also does not require discrete graphics. > > The documentation for NSSupportsAutomaticGraphicsSwitching: > https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching > > I'll create a release note after approval. > > Performance numbers: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1139
Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote: > This is a review request for the bug particularly fixed some time ago: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html > > In that review request it was found that the old fix does not work well in > all cases, see: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html > > The current fix updates an embedded plist.info, so the java will not require > discrete graphics by default, same as for any other applications. > > The discrete card will be used: > 1. If macOS decided to enable it for some reason > 2. If the java app sets/uses a full-screen window > 3. If the user disable "automatic graphics switching" in the system > preferences > 4. If an external monitor is connected to the laptop > > In other cases, the integrated graphics will be used, which should be fine in > most cases since this graphic is used/tested in the mbp 13/etc. This is not > only about rendering performance but also about startup performance, on my > current new laptop mbp 16 + Cataline 10.15.7 the switching > discrete/integrated causes unexpected delays up to 10 seconds. > > > Note that the new "metal" pipeline also does not require discrete graphics. > > The documentation for NSSupportsAutomaticGraphicsSwitching: > https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching > > I'll create a release note after approval. > > Performance numbers: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html I'm still somewhat unsure whether we want to do this in all cases. As mentioned offline, the discrete GPU will be unused (might as well not be there) for almost all Java applications when using a single screen. When the MacBook Pro is running on battery, this seems like a good thing, but when it is plugged in, it seems like we wasting the discrete GPU. It's too bad Apple doesn't provide a way for an application to hint whether they would like to use the discrete GPU if available. I want to run some performance tests with JavaFX, since it will likely impact JavaFX applications. - PR: https://git.openjdk.java.net/jdk/pull/1139
Re: RFR: 8066622 8066637: remove deprecated using java.io.File.toURL() in internal classes
On Sun, 8 Nov 2020 16:58:24 GMT, Phil Race wrote: > You reference a desktop bug that discusses many, many deprecations ... Yep. In my opinion this is a bot problem here and need other place to discuss. > Yet you propose to fix precisely one of these. @prrace: Not really. The way to work with problems differ. Both bugs - maybe these are more quality change requests than bugs - are bullet lists and are created on build process. The different is, I work on single quality tests and remove deprecated code from source base. So in my clean Java build the method java.io.File.toUrl() does not(!) exist. Because java.io.File.toURL() doesn't exist, also two patches are needed for JDK build process (internal I use diff-patch). > And I'd like to hear whether you actually _tested_ splashscreen with your > change ? I see no sign that you did. I'm not sure, what you want to listen. I work with a clean Java build with patch to remove java.io.File.toURL() and change the collateral damages. - PR: https://git.openjdk.java.net/jdk/pull/1108
Re: RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
On Wed, 28 Oct 2020 23:46:55 GMT, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk. >> >> Old review request: >> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html >> >> >> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it >> should be fine for >> Windows 7, because it does not support different DPI for different monitors) >> >> >> Short description: >> In the multi-screen configurations when each screen have different DPI >> we calculate the bounds of each monitor by these formulas: >> >> userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / >> scaleX, deviceH / scaleY >> devSpaceBounds = userX * scaleX, userY * scaleY, userW * scaleX, >> userH * scaleY >> >> This formula makes the next configuration completely broken: >> - The main screen on the left and 100% DPI >> - The second screen on the right and 200% DPI >> When we translate the bounds of the config from the device space to the >> user's space, >> the bounds of both screen overlap in the user's space, because we use >> bounds of >> the main screen as-is, and the X/Y of the second screen are divided by >> the scaleX/Y. >> >> Since the screens are overlapped we cannot be sure how to translate the >> user's space >>coordinates to device space in the overlapped zone. >> As a result => we use the wrong screen >>=> got wrong coordinates in the device space >> => show top-level windows/popups/tooltips/menus/etc on >> the wrong screen >> >>The proposed solution for this bug is to change the formulas to these: >> >> userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / >> scaleY >> devSpaceBounds = userX, userY, userW * scaleX, userH * scaleY >> >>In other words, we should not transform the X and Y coordinates of the >> screen(the top/left corner). This will >>complicate the way of how we transform coordinates on the screen: user's >> <--> device spaces: >> >>Before the fix: >> >> userX = deviceX * scaleX; >> deviceX = userX / scaleX; >> >>After the fix(only the part appeared on this screen should be scaled) >> >> userX = screenX + (deviceX - screenX) * scaleX >> deviceX = screenX + (userX - screenX) / scaleX >> >>Note that these new formulas are applicable only for the coordinates on >> the screen such as X and Y. >>If we will need to calculate the "size" such as W and H then the old >> formula should be used. >> >>The main changes for the problem above are: >>- Skip transformation of X and Y of the screen bounds: >> >> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html >>- A number of utility methods in java and native: >> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html >> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html >> >> >> >> Long description: >> Unfortunately, the changes above are not enough to fix the problem when >> different monitors >> have different DPI, even if the bounds are *NOT* overlapped. >> >>- Currently, when we try to set the bounds of the window, we manually >> convert it in "java" to the >> expected device position based on the current GraphicsConfiguration of >> the peer, and then >> additionally, tweak it in native using the device scale stored in >> native code. Unfortunately >> this two scale might not be in sync:(after we use the >> GraphicsConfiguration scale in peer, >> the config might be changed and the tweak in native will use a >> different screen). >> >> As a fix I have moved all transformation from the peer to the native >> code, it will be executed >> on the toolkit thread: >> See the change in WWindowPeer.setBounds() and awt_Window.cpp >> AwtWindow::Reshape >> >> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html >> >> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html >> I think at some point we should delete all transformation in java, and >> apply it in the native code only. >> >> >>- We had a special code that tracked the dragging of the window by the >> user from one screen to another, >> and change the size of the window only when the user stops the drag >> operation. I've proposed to use standard Windows >> machinery for that via WM_DPICHANGED: >>
Re: RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
On Wed, 28 Oct 2020 23:46:55 GMT, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk. >> >> Old review request: >> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html >> >> >> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it >> should be fine for >> Windows 7, because it does not support different DPI for different monitors) >> >> >> Short description: >> In the multi-screen configurations when each screen have different DPI >> we calculate the bounds of each monitor by these formulas: >> >> userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / >> scaleX, deviceH / scaleY >> devSpaceBounds = userX * scaleX, userY * scaleY, userW * scaleX, >> userH * scaleY >> >> This formula makes the next configuration completely broken: >> - The main screen on the left and 100% DPI >> - The second screen on the right and 200% DPI >> When we translate the bounds of the config from the device space to the >> user's space, >> the bounds of both screen overlap in the user's space, because we use >> bounds of >> the main screen as-is, and the X/Y of the second screen are divided by >> the scaleX/Y. >> >> Since the screens are overlapped we cannot be sure how to translate the >> user's space >>coordinates to device space in the overlapped zone. >> As a result => we use the wrong screen >>=> got wrong coordinates in the device space >> => show top-level windows/popups/tooltips/menus/etc on >> the wrong screen >> >>The proposed solution for this bug is to change the formulas to these: >> >> userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / >> scaleY >> devSpaceBounds = userX, userY, userW * scaleX, userH * scaleY >> >>In other words, we should not transform the X and Y coordinates of the >> screen(the top/left corner). This will >>complicate the way of how we transform coordinates on the screen: user's >> <--> device spaces: >> >>Before the fix: >> >> userX = deviceX * scaleX; >> deviceX = userX / scaleX; >> >>After the fix(only the part appeared on this screen should be scaled) >> >> userX = screenX + (deviceX - screenX) * scaleX >> deviceX = screenX + (userX - screenX) / scaleX >> >>Note that these new formulas are applicable only for the coordinates on >> the screen such as X and Y. >>If we will need to calculate the "size" such as W and H then the old >> formula should be used. >> >>The main changes for the problem above are: >>- Skip transformation of X and Y of the screen bounds: >> >> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html >>- A number of utility methods in java and native: >> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html >> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html >> >> >> >> Long description: >> Unfortunately, the changes above are not enough to fix the problem when >> different monitors >> have different DPI, even if the bounds are *NOT* overlapped. >> >>- Currently, when we try to set the bounds of the window, we manually >> convert it in "java" to the >> expected device position based on the current GraphicsConfiguration of >> the peer, and then >> additionally, tweak it in native using the device scale stored in >> native code. Unfortunately >> this two scale might not be in sync:(after we use the >> GraphicsConfiguration scale in peer, >> the config might be changed and the tweak in native will use a >> different screen). >> >> As a fix I have moved all transformation from the peer to the native >> code, it will be executed >> on the toolkit thread: >> See the change in WWindowPeer.setBounds() and awt_Window.cpp >> AwtWindow::Reshape >> >> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html >> >> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html >> I think at some point we should delete all transformation in java, and >> apply it in the native code only. >> >> >>- We had a special code that tracked the dragging of the window by the >> user from one screen to another, >> and change the size of the window only when the user stops the drag >> operation. I've proposed to use standard Windows >> machinery for that via WM_DPICHANGED: >>
RFR: 8251854: [macosx] Java forces the use of discrete GPU
This is a review request for the bug particularly fixed some time ago: https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html In that review request it was found that the old fix does not work well in all cases, see: https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html The current fix updates an embedded plist.info, so the java will not require discrete graphics by default, same as for any other applications. The discrete card will be used: 1. If macOS decided to enable it for some reason 2. If the java app sets/uses a full-screen window 3. If the user disable "automatic graphics switching" in the system preferences 4. If an external monitor is connected to the laptop In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds. Note that the new "metal" pipeline also does not require discrete graphics. The documentation for NSSupportsAutomaticGraphicsSwitching: https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching I'll create a release note after approval. Performance numbers: https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html Old review request: https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html - Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/1139/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1139=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251854 Stats: 6 lines in 3 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1139/head:pull/1139 PR: https://git.openjdk.java.net/jdk/pull/1139
