Re: RFR: 8311895: CSS Transitions [v12]
> Implementation of [CSS > Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > src="https://user-images.githubusercontent.com/43553916/184781143-0520fbfe-54bf-4b8d-93ac-834708e46500.gif"; > width="200"/> > > ### Limitations > This implementation supports both shorthand and longhand notations for the > `transition` property. However, due to limitations of JavaFX CSS, mixing both > notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strauß has updated the pull request incrementally with one additional commit since the last revision: Discard redundant transitions in StyleableProperty impls - Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/22aa4d64..1595a190 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=10-11 Stats: 432 lines in 10 files changed: 320 ins; 93 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870
Re: RFR: 8311895: CSS Transitions [v9]
On Tue, 14 Nov 2023 13:04:35 GMT, John Hendrikx wrote: >> Michael Strauß has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Test whether two Interpolatable instances are compatible > > modules/javafx.graphics/src/main/java/javafx/css/StyleableDoubleProperty.java > line 78: > >> 76: >> 77: if (transition != null) { >> 78: timer = TransitionTimer.run(new TransitionTimerImpl(this, >> v), transition); > > Would it be possible to check here if this timer is going to the same target? > Also see other comment about a simplification. > > if (timer == null || timer.newValue.equals(v))) { > timer = TransitionTimer.run(new TransitionTimerImpl(this, v), > transition); > } I've moved the logic to discard redundant transitions to the `StyleableProperty` implementation classes. - PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1545575965
Re: RFR: 8311895: CSS Transitions [v13]
> Implementation of [CSS > Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > src="https://user-images.githubusercontent.com/43553916/184781143-0520fbfe-54bf-4b8d-93ac-834708e46500.gif"; > width="200"/> > > ### Limitations > This implementation supports both shorthand and longhand notations for the > `transition` property. However, due to limitations of JavaFX CSS, mixing both > notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strauß has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits: - Merge branch 'master' into feature/css-transitions - Discard redundant transitions in StyleableProperty impls - Changes per review - Merge branch 'master' into feature/css-transitions - Merge branch 'master' into feature/css-transitions - Add TransitionMediator - Test whether two Interpolatable instances are compatible - Merge branch 'master' into feature/css-transitions - Added documentation - Review changes - ... and 39 more: https://git.openjdk.org/jfx/compare/eca32354...7edb374f - Changes: https://git.openjdk.org/jfx/pull/870/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=12 Stats: 4661 lines in 43 files changed: 4622 ins; 1 del; 38 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870
Re: RFR: 8311895: CSS Transitions [v14]
> Implementation of [CSS > Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > src="https://user-images.githubusercontent.com/43553916/184781143-0520fbfe-54bf-4b8d-93ac-834708e46500.gif"; > width="200"/> > > ### Limitations > This implementation supports both shorthand and longhand notations for the > `transition` property. However, due to limitations of JavaFX CSS, mixing both > notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strauß has updated the pull request incrementally with one additional commit since the last revision: Change javadoc comment - Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/7edb374f..f7ab6db3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=13 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=12-13 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870
Re: RFR: 8311895: CSS Transitions [v15]
> Implementation of [CSS > Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > src="https://user-images.githubusercontent.com/43553916/184781143-0520fbfe-54bf-4b8d-93ac-834708e46500.gif"; > width="200"/> > > ### Limitations > This implementation supports both shorthand and longhand notations for the > `transition` property. However, due to limitations of JavaFX CSS, mixing both > notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strauß has updated the pull request incrementally with two additional commits since the last revision: - update 'since' tags - Fix javadoc error - Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/f7ab6db3..137a00c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=13-14 Stats: 14 lines in 3 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870
Re: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels
On Thu, 11 Jan 2024 12:17:11 GMT, Marius Hanl wrote: >> As seen in the unit test of the PR, when we click on the area above/below >> the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In >> the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much >> is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is >> much more consistent. >> >> This is also related to the following PR: >> https://github.com/openjdk/jfx/pull/1194 > > Agree, with all the tests added, especially in this area in > https://github.com/openjdk/jfx/pull/1194 and in > https://github.com/openjdk/jfx/pull/1246, it is much easier for us to catch > regression. I will also have a look in the next days. I also noted that I got > weird scrolling behaviour once before, but could never reproduce it. > The suggested patch changes the conceptual idea of `VirtualFlow.scrollTo(int > index)` where a negative index is not specified (this is probably what > @Maran23 asked at [#1326 > (comment)](https://github.com/openjdk/jfx/pull/1326#discussion_r1530233902) . Yes, this is exactly what I mean and where I do not know if this is the right approach. > The way the scrollTo(int index) is modified doesn't sound right to me Agree, it sounds somewhat weird to me that when `scrollTo` is called with index = -1, that means we just scroll up more gradually (not to the top of the cell). > If the latter is the preferred case, this looks to a behavior that is more > similar to the Event that is received when the mousewheel is used (and which > invokes VirtualFlow.scrollPixels(double delta)) I completely agree. This sounds like we may should call `scrollPixels` directly instead. As @johanvos mentioned, we also need to change the "specification" in the comment at least. - PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2028769290
Prefer EGL over GLX on Linux
Hi, I am doing some efforts here: https://github.com/openjdk/jfx/pull/1381 Why? This is initial Wayland support work, since it will require EGL to draw to a Wayland surface. EGL is also supported on Xorg. The idea is to prefer EGL and fallback to GLX as it's done in Gtk, for example. I don't know of an exact scenario where EGL will fail - maybe very old graphics cards. The second step will be to implement a libwayland-client glass backend. Some caveats I've found: - PrismES2Defs.h -> too much #ifdefs - Monocle also uses EGL so it feels somewhat duplicated - The Library loading only supports one lib and then falls back to software - in this case it's a three-phase loading: EGL, GLX, then SW. I will probably have to touch other platform code to isolate this. -- Thiago.