On Tue, 23 Jan 2024 03:13:11 GMT, Alexander Matveev
wrote:
> This is regression from JDK-8262365. JDK-8262365 introduced support for
> hardware pause for audio device. For some reason we will skip ~500 ms of
> audio data after such pause. It is not noticeable for large audio files, but
> for
Note: this proposal does NOT allow Animation.play/stop/etc. to be
"called on any thread" as mentioned in JDK-8324658 [0].
It merely removes the requirement that these methods must be called on
the FX thread, but this doesn't make the class inherently thread-safe.
That is an important distinction t
Here's another option, which I have implemented as a proof of concept [0]:
The play/stop/etc. methods are currently specified to be
"asynchronous". This language should be removed, such that the methods
will be implied to execute synchronously from the point of view of the
caller (like every metho
This is the ballpark of what I meant with "the downside might be some
surprise when these methods behave differently".
The example you give will only show a potential change if 'play' is not
called from the FX thread. In such a case, what's the chance that this is
an undeliberate misuse vs. an inf
This isn't a known issue, so please post more information.
-- Kevin
On 1/24/2024 10:59 AM, Dan Howard wrote:
Hi All,
I'm not sure if this is the right place to discuss but while working
on a game, I noticed that the animations are not running the correct
durations sometimes on Windows 11 Pro
The point you raise is one reason why I wouldn't advocate doing this in
other places, e.g., for scene graph updates, which do need to run
synchronously.
I note that the Animation docs currently state that these operations are
asynchronous (and yes, I know you were proposing the change this). S
On Wed, 24 Jan 2024 14:55:21 GMT, Laurent Bourgès wrote:
> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java
@bourgesl Some of the unit tests looks to be failing. Can you please check?
-
PR Comment: https://git.openjdk.org/jfx/pull/1348#issuecomment-1908749026
I am not in favor of option 2 if the implementation was simply "wrap
the implementation in runLater", as this would be a surprising change.
Consider the following code:
var transition = new FadeTransition();
transition.play();
// Will always print "RUNNING" currently, but might print
Thanks!
I just filed https://bugs.openjdk.org/browse/JDK-8324658
It should mostly revert JDK-8159048 (although the sentence added to the
class docs about animations running on the JavaFX app thread is still
valid), and some of the unit tests might still be valid.
-- Kevin
On 1/24/2024 10:50
Hi All,
I'm not sure if this is the right place to discuss but while working on
a game, I noticed that the animations are not running the correct
durations sometimes on Windows 11 Pro. I tried it out on my Mac
(Ventura) and I don't see this issue.
This is running the latest JavaFX (maven 21.
If there's an agreement, I can do it tomorrow. It will effectively revert
JDK-8159048 and supersede JDK-8324219.
On Wed, Jan 24, 2024 at 8:42 PM Kevin Rushforth
wrote:
> I also now favor option 2 and was in the process of writing something up
> recommending that we do that. Phil and I (and a cou
I also now favor option 2 and was in the process of writing something up
recommending that we do that. Phil and I (and a couple others) had an
offline discussion and think this is the way to go.
Given the short amount of time to get this into 22, I will file the JBS
issue in the next hour or s
These are the options I see as reasonable:
1. Document that these methods *must* be run on the FX thread and throw an
exception otherwise. This leaves it to the responsibility of the user.
However, this will cause the backwards compatibility problems that Jugen
brought up. As a side note, we do th
On Wed, 24 Jan 2024 14:55:21 GMT, Laurent Bourgès wrote:
> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java
@bourgesl You will need to change the title of this PR to match that of the JBS
bug. You can add the additional information by using the `/summary` command if
you like
On Fri, 19 Jan 2024 16:00:49 GMT, John Hendrikx wrote:
>> The SimpleSelector and CompoundSelector classes are public classes in an
>> exported package, javafx.css, but they are not intended to be used by
>> applications. They are implementation details. They cannot be constructed
>> directly a
Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java
-
Commit messages:
- JDK-8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 +
minor syntax fixes (merge with latest MarlinFX)
Changes: https://git.openjdk.org/jfx/pull/1348/files
Webrev: https://we
On Thu, 18 Jan 2024 15:33:49 GMT, Lukasz Kostyra wrote:
>> Originally this issue showed the problem of Node being incorrectly rendered
>> (clipped) when snapshotting, compared to a snapshot of the whole Scene.
>> Later on there was another problem added - lights not being taken into
>> account
I'd like to hear from the others on this. I don't see any fundamental
problem with having the play/pause/stop methods wrap their
implementation in a runLater (if not on the FX Application thread
already), and documenting that it does so, if we can get general agreement.
-- Kevin
On 1/24/2024
Hi Kevin
If I may make one more final appeal then to an alternative solution please.
Could we then instead of throwing an Exception rather invoke runLater if
needed inside play, stop, and resume.
Putting the onus on the developer is fine if it is the developer that is
invoking the call, bu
Thank you to Jurgen for raising the question and to Nir, John, and
Michael for evaluating it.
I conclude that there is insufficient motivation to revert the change in
behavior implemented by JDK-8159048 to allow calling the play/pause/stop
methods of Animation on a background thread. Doing so
Hi Jurgen,
See my answers inline.
On 24/01/2024 10:12, Jurgen Doll wrote:
Hi John
Thank you for the hypothetical receivers array scenario, I think it
explains the problem exactly and is why replacing the array with
CopyOnWriteArrayList removes the NPE.
Your perspective then is that Abstrac
Hi John
Thank you for the hypothetical receivers array scenario, I think it
explains the problem exactly and is why replacing the array with
CopyOnWriteArrayList removes the NPE.
Your perspective then is that AbstractPrimaryTimer is designed for single
threaded use only. If that is indeed
After playing around with the code sample, I think that this is not the
right way to use the animation. The reason is that there is no point in
starting the animation before the control is attached to the scenegraph, or
even made visible. A small refactoring where, e.g., the controller class
expose
23 matches
Mail list logo
