On Fri, 2 May 2025 14:41:06 GMT, Martin Fox wrote:
> I'm not entirely sure that's a requirement we should be testing for.
I agree. We should test that it settles to the expected values eventually.
-
PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2847383534
On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
On Tue, 29 Apr 2025 16:40:01 GMT, Martin Fox wrote:
> > * Will there be any problem one of the deferred Runnables causes an
> > exitFullScreen (e.g., on a different Stage in a dual screen case)? This
> > might be worth testing.
>
> Could you provide more details on what you want tested? I'm no
On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
On Wed, 30 Apr 2025 21:26:41 GMT, Kevin Rushforth wrote:
> During the headful test run, the following test failed on all four of our
> test systems, so it is likely related to your fix.
I think it's unrelated. During testing @andy-goryachev-oracle noted that the
demaximized position test was n
> On macOS the system animates the transition into and out of fullscreen and
> this animation runs asynchronously. JavaFX tries to make the setFullScreen
> call appear synchronous by running a nested event loop while the transition
> is going on. But this means that runLater runnables can fire d
On Wed, 30 Apr 2025 03:38:34 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
On Wed, 30 Apr 2025 03:38:34 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
On Wed, 30 Apr 2025 03:38:34 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
> On macOS the system animates the transition into and out of fullscreen and
> this animation runs asynchronously. JavaFX tries to make the setFullScreen
> call appear synchronous by running a nested event loop while the transition
> is going on. But this means that runLater runnables can fire d
On Tue, 29 Apr 2025 17:29:26 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
> On macOS the system animates the transition into and out of fullscreen and
> this animation runs asynchronously. JavaFX tries to make the setFullScreen
> call appear synchronous by running a nested event loop while the transition
> is going on. But this means that runLater runnables can fire d
On Tue, 29 Apr 2025 17:29:26 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
On Tue, 29 Apr 2025 17:29:26 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the transition
>> is g
On Tue, 29 Apr 2025 17:20:08 GMT, Andy Goryachev wrote:
> > testDemaximizedPosition()
>
> sorry, I meant with the standalone reproducer, not the actual test.
The standalone reproducer is just a slightly tweaked version of the system
test. Both should work fine. The system test should have been
On Tue, 29 Apr 2025 17:17:28 GMT, Martin Fox wrote:
> testDemaximizedPosition()
sorry, I meant with the standalone reproducer, not the actual test. see here
https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/Stage_RestorePosition_8176813.java
-
PR Comment:
On Mon, 28 Apr 2025 22:49:50 GMT, Andy Goryachev wrote:
> Using the reproducer in the ticket, I could not reproduce the issue with
> `testDemaximizedPosition()` - it passed in the master branch.
You're right, it should work. The test is still disabled on macOS even though
the blocking bug was
On Mon, 28 Apr 2025 20:54:25 GMT, Andy Goryachev wrote:
> question: could this deferral of runnables cause some kind of race condition
> in respect to other synchronous changes? Like, for example, trying to hide
> the window while is being transitioned to or from full screen?
One of the goals
On Mon, 28 Apr 2025 20:22:50 GMT, Kevin Rushforth wrote:
> * Do you think this will increase the possibility of deadlock?
This PR shifts the execution of runLater runnables out to the event loop in
effect when setFullScreen() was called. This matches where Windows and Linux
would process them.
On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox wrote:
> On macOS the system animates the transition into and out of fullscreen and
> this animation runs asynchronously. JavaFX tries to make the setFullScreen
> call appear synchronous by running a nested event loop while the transition
> is going
On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox wrote:
> On macOS the system animates the transition into and out of fullscreen and
> this animation runs asynchronously. JavaFX tries to make the setFullScreen
> call appear synchronous by running a nested event loop while the transition
> is going
On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox wrote:
> On macOS the system animates the transition into and out of fullscreen and
> this animation runs asynchronously. JavaFX tries to make the setFullScreen
> call appear synchronous by running a nested event loop while the transition
> is going
On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox wrote:
> On macOS the system animates the transition into and out of fullscreen and
> this animation runs asynchronously. JavaFX tries to make the setFullScreen
> call appear synchronous by running a nested event loop while the transition
> is going
On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox wrote:
> On macOS the system animates the transition into and out of fullscreen and
> this animation runs asynchronously. JavaFX tries to make the setFullScreen
> call appear synchronous by running a nested event loop while the transition
> is going
On macOS the system animates the transition into and out of fullscreen and this
animation runs asynchronously. JavaFX tries to make the setFullScreen call
appear synchronous by running a nested event loop while the transition is going
on. But this means that runLater runnables can fire during a
28 matches
Mail list logo
