[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: [Rev 04] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle.
From:       Florian Kirmaier <fkirmaier () openjdk ! java ! net>
Date:       2020-04-28 14:34:54
Message-ID: TGDmH0-Y8OHmS31oUNi4fIXW6kH2C9NdQtss1SCP40k=.a0dfec60-0681-429e-b014-b38899bc8a09 () github ! com
[Download RAW message or body]

On Mon, 27 Apr 2020 15:09:17 GMT, Ambarish Rapte <arapte@openjdk.org> wrote:

> > Florian Kirmaier has updated the pull request incrementally with one additional \
> > commit since the last revision: 
> > JDK-8241840
> > The tests are now reused for native and monocle tests.
> 
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 1325:
> 
> > 1324:             this.isFocused = focused;
> > 1325:             if (this.isFocused && this.isVisible) {
> > 1326:                 setFocusedWindow(this);
> 
> On my Window10 machine, with this change, `Window.focusedWindow` remains `null` \
> even after the first window (I have not verified with multiple windows though) is \
> shown onto the screen and is focused. And It continues to remain `null` until some \
> mouse or key action is performed on the window. I am not sure if this causes any \
> side effects. It looks like the `Window.focusedWindow` is mostly(only) used for \
> Monocle. Can you please confirm the behavior that `Window.focusedWindow` remain \
> `null` and check for any side effects.

As mentioned - I don't have a good setup to test this code on Windows.

But I've checked where focusedWindow/getFocusedWindow is used, and I can verify your \
assumption. I've searched through the whole project and the variable is only used in \
the MonocleCode.

The fact that focusedWindow get's sometimes set is probably the cause of the \
irregular happening memoryleak on Window.

-------------

PR: https://git.openjdk.java.net/jfx/pull/153


[prev in list] [next in list] [prev in thread] [next in thread]