Re: Aw: Chance of Backporting Gtk3 Support to JavaFX 8
Hi, There's a now a defined EOL for SWT-Gtk2 announced [1]. The last SWT Release supporting Gtk2 is 2018-09! Starting with 2018-12 SWT there will be no more Gtk2 support! Tom [1]https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15783.html On 06.06.18 11:12, Tom Schindl wrote: > Hi, > > Yes. FXCanvas from JavaFX8 won't work anymore once SWT-Gtk2 is gone. > > The discussion on this currently happens at [platform-dev] mailing list > - see https://dev.eclipse.org/mhonarc/lists/platform-dev/ - There's no > timeframe mentionned yet by the SWT-Team but sooner or later that will > happen. > > Tom > > On 06.06.18 11:03, Thorsten Fischer wrote: >> Hello Tom, >> >> does that mean that FXCanvas won't work with upcoming Eclipse versions >> and JavaFX8? >> >> Do you know in which timeframe/release that my occur? Is that issue >> discussed in the eclipse bugtracker somewhere? I couldn't find it by >> searching for "gtk4". >> >> Kind regards, >> Thorsten >> >> *Gesendet:* Mittwoch, 06. Juni 2018 um 10:20 Uhr >> *Von:* "Tom Schindl" >> *An:* "openjfx-dev@openjdk.java.net Mailing" >> *Betreff:* Chance of Backporting Gtk3 Support to JavaFX 8 >> Hi, >> >> Eclipse SWT developers are about to remove Gtk2-SWT port once they start >> developing towards support for Gtk4. >> >> This means there's no SWT-FX-Integration layer anymore for JavaFX8 >> because it is linked to Gtk2. >> >> I know JavaFX-8 is not the new and shining thing because everyone wants >> to use modules and Java 11 but there are many applications who can not >> easily to Java 9+. >> >> Is there any chance the Gtk3 changes from JavaFX-9 get backported to >> JavaFX-8? >> >> Tom
[11] JDK-8204336 : Platform.exit() throws ISE when a nested event loop is active
Hi Kevin, Murali, Please review this fix, Webrev: http://cr.openjdk.java.net/~pbansal/8204336/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8204336 Regards, Pankaj
RE: CFV: New OpenJFX Committer: Prem Balakrishnan
Vote: Yes -Original Message- From: Kevin Rushforth Sent: Wednesday, July 11, 2018 5:12 AM To: openjfx-dev@openjdk.java.net; Prem Balakrishnan Subject: CFV: New OpenJFX Committer: Prem Balakrishnan I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer. Prem is a member of JavaFX team at Oracle, who has contributed 10 changesets [2] to OpenJFX. Votes are due by July 24, 2018. Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] http://openjdk.java.net/census#pkbalakr [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28pkbalakr%29 [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer
Re: CFV: New OpenJFX Committer: Prem Balakrishnan
Vote: yes -- Jonathan (Tapped on a touch device) On Wed, 11 Jul 2018, 10:57 PM Arunprasad Rajkumar, < arunprasad.rajku...@oracle.com> wrote: > Vote: Yes > > > On 11-Jul-2018, at 5:11 AM, Kevin Rushforth > wrote: > > > > I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer. > > > > Prem is a member of JavaFX team at Oracle, who has contributed 10 > changesets [2] to OpenJFX. > > > > Votes are due by July 24, 2018. > > > > Only current OpenJFX Committers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [5]. Nomination to a project > Committer is described in [6]. > > > > Thanks. > > > > -- Kevin > > > > [1] http://openjdk.java.net/census#pkbalakr > > > > [2] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28pkbalakr%29 > > > > [3] http://openjdk.java.net/census#openjfx > > > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > > > [5] http://openjdk.java.net/projects#project-committer > > > >
Determining which GraphicsPipeline is being used
Hi, I was wondering if there is a way to find out which graphics pipeline is being used by javafx. Some of our users access our application via virtualized environments or use old GPUs that in some way don't support hardware rendering. The way we do it at the moment: com.sun.prism.GraphicsPipeline.getPipeline() Are there any plans to provide public API for this (maybe in form of an MXBean along with FPS stats and other metrics)? Selim
Re: Aw: Chance of Backporting Gtk3 Support to JavaFX 8
Good to know about the time frame. Yes, we are looking at backporting GTK 3 support to JDK 8. -- Kevin On 7/12/2018 12:47 AM, Tom Schindl wrote: Hi, There's a now a defined EOL for SWT-Gtk2 announced [1]. The last SWT Release supporting Gtk2 is 2018-09! Starting with 2018-12 SWT there will be no more Gtk2 support! Tom [1]https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15783.html On 06.06.18 11:12, Tom Schindl wrote: Hi, Yes. FXCanvas from JavaFX8 won't work anymore once SWT-Gtk2 is gone. The discussion on this currently happens at [platform-dev] mailing list - see https://dev.eclipse.org/mhonarc/lists/platform-dev/ - There's no timeframe mentionned yet by the SWT-Team but sooner or later that will happen. Tom On 06.06.18 11:03, Thorsten Fischer wrote: Hello Tom, does that mean that FXCanvas won't work with upcoming Eclipse versions and JavaFX8? Do you know in which timeframe/release that my occur? Is that issue discussed in the eclipse bugtracker somewhere? I couldn't find it by searching for "gtk4". Kind regards, Thorsten *Gesendet:* Mittwoch, 06. Juni 2018 um 10:20 Uhr *Von:* "Tom Schindl" *An:* "openjfx-dev@openjdk.java.net Mailing" *Betreff:* Chance of Backporting Gtk3 Support to JavaFX 8 Hi, Eclipse SWT developers are about to remove Gtk2-SWT port once they start developing towards support for Gtk4. This means there's no SWT-FX-Integration layer anymore for JavaFX8 because it is linked to Gtk2. I know JavaFX-8 is not the new and shining thing because everyone wants to use modules and Java 11 but there are many applications who can not easily to Java 9+. Is there any chance the Gtk3 changes from JavaFX-9 get backported to JavaFX-8? Tom
Re: Determining which GraphicsPipeline is being used
Checking the conditional feature SCENE_3D should give you what you need. It is true if and only if there is support for 3D features, which is the software pipelines lack. -- Kevin On 7/12/2018 4:02 AM, Selim Dincer wrote: Hi, I was wondering if there is a way to find out which graphics pipeline is being used by javafx. Some of our users access our application via virtualized environments or use old GPUs that in some way don't support hardware rendering. The way we do it at the moment: com.sun.prism.GraphicsPipeline.getPipeline() Are there any plans to provide public API for this (maybe in form of an MXBean along with FPS stats and other metrics)? Selim
Re: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API
Hi Prasanta,
I confirm that the test failures are gone now. I need to do some final
testing (e.g., a clean build using both JDK 11 and JDK 10 on all three
platforms). I also want a second look at a couple of the implementation
files, but overall it's close I think. Here are my review comments so far:
General review comments:
* White space problems
- trailing whitespace and TABS, which must be fixed
- InteropFactoryO constructor missing a space: 'Exception{'
* Several of the files have unused imports -- also can you please sort
the imports?
build.gradle:
* MINOR: naming suggestion:
> 2344 task checkJDKUnsupportedModule(...)
Maybe a more descrptive name for the task would be "copyModuleInfo"?
javafx.swing/src/main/module-info/module-info.java:
* Ordering of requires directives
> 41 requires static jdk.unsupported.desktop;
Can you move this before the 'requires transitive' statements -- it
should group with the previous block (the 'requires' statements)
InteropFactory:
* MINOR: maybe use a lambda for the following?
37 AccessController.doPrivileged(new PrivilegedAction() {
38 public Object run() {
39 verbose = Boolean.valueOf(
40 System.getProperty("javafx.embed.swing.verbose"));
41 return null;
42 }
43 });
JFXPanelInterop
38 public abstract long setMask();
Would ‘getMask’ be a better name? (it’s a getter not a setter)
FOLLOW-ON BUGS:
* We should file a follow-on bug to remove the runtime qualified exports
(e.g., from testrun.args) when running a JDK that
HAS_UNSUPPORTED_DESKTOP; this isn't high priority
-- Kevin
On 7/11/2018 8:48 AM, Prasanta Sadhukhan wrote:
Hi Kevin,
Please find modified webrev fixing the other test failures by
modifying the overrideNativeWindowHandle JNI method
http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.7/
Regards
Prasanta
On 7/10/2018 3:58 PM, Prasanta Sadhukhan wrote:
Hi Kevin,
Please find modified webrev with some more refactoring to move more
common code to SwingNode
and also this solves SwingNodeMemoryLeakTest failure
http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.6/
Regards
Prasanta
On 7/10/2018 7:13 AM, Kevin Rushforth wrote:
Hi Prasanta,
The public API looks fine now. I sent you an offline note about one
of the test failures (SwingNodeMemoryLeakTest).
There are still whitespace problems that will cause a failure in
'gradle checkrepo' (and 'hg jcheck').
I'll do a more thorough review in the next day or so.
-- Kevin
On 7/9/2018 4:12 AM, Prasanta Sadhukhan wrote:
Hi Kevin,
Modified webrev to address the "public" leakage
http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.5/
I am looking into the test failures.
Regards
Prasanta
On 7/7/2018 4:30 AM, Kevin Rushforth wrote:
Most things are working with either mode (JDK 10 with qualified
exports or JDK 11 without), although I do get a few test failures.
There is a serious issue with leakage into the public API that
needs to be addressed before worrying about the failures, but I'll
list the test failures at the end.
SwingNode.java:
This public class is part of the API. You cannot make any of the
following fields public as this would leak implementation into
public API:
+ public int swingPrefWidth;
+ public int swingPrefHeight;
+ public int swingMaxWidth;
+ public int swingMaxHeight;
+ public int swingMinWidth;
+ public int swingMinHeight;
+ public final Object getLightweightFrame() { return lwFrame; }
+ public final ReentrantLock paintLock = new ReentrantLock();
+ public boolean grabbed; // lwframe initiated grab
+ public void setImageBuffer(...)
+ public void setImageBounds(...);
+ public void repaintDirtyRegion(...)
+ public void ungrabFocus(boolean postUngrabEvent)
If you need to access them from other packages, you can either use
the accessor pattern (this might be easiest) or else refactor it
further to move more of this down to the implementation. I note
that even though SwingNodeInterop is abstract, it can still have
non-abstract methods if that helps in your refactoring.
SwingFXUtils.java
Same problem as SwingNode, although to a lesser extent. The
following must not be public:
+ public static void runOnFxThread(Runnable runnable)
+ public static void runOnEDT(final Runnable r)
+ public static void runOnEDTAndWait(Object nestedLoopKey,
Runnable r)
+ public static void leaveFXNestedLoop(Object nestedLoopKey)
JFXPanel is fine.
-
* System tests failures on Linux:
test.robot.javafx.embed.swing.SwingNodeJDialogTest >
testJDialogAbove FAILED
java.lang.AssertionError: JDialog is not above JavaFX stage
expected: but
was:
test.robot.javafx.embed.swing.SwingNodeJDialogTest >
testNodeRemovalAfterShow FAILED
java.lang.AssertionError: JDialog is not above JavaFX stage
expected: but
was:
test.robot.javafx.embed.swing.SwingNo
