Re: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v3]
> This PR updates the screen for each window even for the case where the old > screen has been disposed but there is a new screen instance found for such > window. > > This is the case of Android, where the lifecycle of the application allows > destroying the native screen when the app goes to the background, and > providing a new native screen, in case it comes back to the foreground. > Before this PR, the screen for the window wasn't updated after returning from > the background, and if orientation changes happened, the dimensions were > wrong. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Scale screen dimensions - Changes: - all: https://git.openjdk.java.net/jfx/pull/778/files - new: https://git.openjdk.java.net/jfx/pull/778/files/6fcbd9be..28129038 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=778=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=778=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/778.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/778/head:pull/778 PR: https://git.openjdk.java.net/jfx/pull/778
Re: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v2]
On Wed, 4 May 2022 16:03:20 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old >> screen has been disposed but there is a new screen instance found for such >> window. >> >> This is the case of Android, where the lifecycle of the application allows >> destroying the native screen when the app goes to the background, and >> providing a new native screen, in case it comes back to the foreground. >> Before this PR, the screen for the window wasn't updated after returning >> from the background, and if orientation changes happened, the dimensions >> were wrong. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Rollback change, move to new screen created via native if handler changes You are right, the proposed change was intended only for Android but was touching shared code for all platforms. Based on the comment "Note that if a window has moved to another screen...", and considering that this could apply to the Android case (the initial screen gets destroyed and a new screen is created when app resumes), I have now another solution that does the same but that is mostly on the Android side (`MonocleWindowManager::repaintFromNative` was only called from Android native anyway), with a small change in `MonocleWindow` though, as `Window::notifyMoveToAnotherScreen` has protected access. - PR: https://git.openjdk.java.net/jfx/pull/778
Re: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v2]
> This PR updates the screen for each window even for the case where the old > screen has been disposed but there is a new screen instance found for such > window. > > This is the case of Android, where the lifecycle of the application allows > destroying the native screen when the app goes to the background, and > providing a new native screen, in case it comes back to the foreground. > Before this PR, the screen for the window wasn't updated after returning from > the background, and if orientation changes happened, the dimensions were > wrong. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Rollback change, move to new screen created via native if handler changes - Changes: - all: https://git.openjdk.java.net/jfx/pull/778/files - new: https://git.openjdk.java.net/jfx/pull/778/files/233e29c6..6fcbd9be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=778=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=778=00-01 Stats: 40 lines in 4 files changed: 23 ins; 4 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/778.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/778/head:pull/778 PR: https://git.openjdk.java.net/jfx/pull/778
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v5]
> When the size of a ListCell is changed and a scrollTo method is invoked > without having a layout calculation in between, the old (wrong) size is used > to calculcate the total estimate. This happens e.g. when the size is changed > in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache > containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Don't recalculate estimated size while doing a layout cycle. There are a number of paths possible that first calculate an offset/position, and later do a layoutChildren pass. The offset/position calculations (e.g. in scrollTo calls) assume a specific estimatedSize. If that size is changed between the first call and the layoutChildren logic, the result will not look as intended. Hence, we should avoid updating the estimated size at the start of the layout phase. We can do it safely at the end. Thanks to Zeiss and Florian Kirmaier for providing additional tests. - Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/2b1b4bdc..aa08ba26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=712=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx=712=03-04 Stats: 116 lines in 2 files changed: 115 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712
