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.
