From kevin.rushforth at oracle.com Mon Mar 2 20:58:41 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 02 Mar 2015 12:58:41 -0800 Subject: 8u-dev unlocked following this week's sanity testing Message-ID: <54F4CF01.7010209@oracle.com> From elina.kleyman at oracle.com Tue Mar 3 15:44:36 2015 From: elina.kleyman at oracle.com (Elina Kleyman) Date: Tue, 3 Mar 2015 07:44:36 -0800 (PST) Subject: [8u60] Review request: RT-39874 - NullPointerException while opening new window in Stage.show() Message-ID: <4696aeaa-8fbb-4f5d-89da-697113f781f6@default> Hi Kevin, Chien, Please review fix for https://javafx-jira.kenai.com/browse/RT-39874 Link to webrev: http://cr.openjdk.java.net/~ekleyman/RT-39874/ Thanks, Elina From chien.yang at oracle.com Tue Mar 3 17:49:13 2015 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 03 Mar 2015 09:49:13 -0800 Subject: Code Review Request For RT-40099: GridPane percentage layout bug since JavaFx 8u40 Message-ID: <54F5F419.3030701@oracle.com> Hi Kevin, Please review the proposed fix. Detail information is in the JIRA: https://javafx-jira.kenai.com/browse/RT-40099 Thanks, - Chien From kevin.rushforth at oracle.com Tue Mar 3 22:14:37 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 03 Mar 2015 14:14:37 -0800 Subject: 8u40 is released Message-ID: <54F6324D.1060601@oracle.com> For those who haven't seen yet, the JDK 8u40 release is now live and ready for download. -- Kevin From anton.tarasov at oracle.com Wed Mar 4 08:54:25 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 04 Mar 2015 11:54:25 +0300 Subject: [9] Post commit notification: RT-40077: javafx.scene.web.IrresponsiveScriptTest hangs on Linux with new WebKit Message-ID: <54F6C841.8080409@oracle.com> Hi Kevin, I've commited a simple fix for this issue: https://javafx-jira.kenai.com/browse/RT-40077 (The patch is in the comments.) Thanks, Anton. From ngalarneau at ABINITIO.COM Wed Mar 4 13:58:28 2015 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Wed, 4 Mar 2015 08:58:28 -0500 Subject: 8u40 is released In-Reply-To: <54F6324D.1060601@oracle.com> References: <54F6324D.1060601@oracle.com> Message-ID: Hurray! Thank you all for the good work. Do you know when the corresponding Scene Builder release will be? It would be great to get support for the new widgets. Also, the Scene Builder download page warns against using 2.0 for security reasons. Neil From: Kevin Rushforth To: "openjfx-dev at openjdk.java.net" , Date: 03/03/2015 05:14 PM Subject: 8u40 is released Sent by: "openjfx-dev" For those who haven't seen yet, the JDK 8u40 release is now live and ready for download. -- Kevin NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From kevin.rushforth at oracle.com Wed Mar 4 14:47:02 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Mar 2015 06:47:02 -0800 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> Message-ID: <54F71AE6.907@oracle.com> Scene Builder source code is available in the OpenJFX repo under the BSD license, but separate binaries are no longer being released as of 8u40. See: http://www.oracle.com/technetwork/java/javase/downloads/sb2download-2177776.html -- Kevin ngalarneau at ABINITIO.COM wrote: > Hurray! > > Thank you all for the good work. > > Do you know when the corresponding Scene Builder release will be? > > It would be great to get support for the new widgets. Also, the Scene > Builder download page warns against using 2.0 for security reasons. > > > Neil > > > > > From: Kevin Rushforth > To: "openjfx-dev at openjdk.java.net" , > Date: 03/03/2015 05:14 PM > Subject: 8u40 is released > Sent by: "openjfx-dev" > ------------------------------------------------------------------------ > > > > For those who haven't seen yet, the JDK 8u40 release is now live and > ready for download. > > -- Kevin > > > > > > NOTICE /from Ab Initio: This email (including any attachments) may > contain information that is subject to confidentiality obligations or > is legally privileged, and sender does not waive confidentiality or > privilege. If received in error, please notify the sender, delete this > email, and make no further use, disclosure, or distribution. / From kevin.rushforth at oracle.com Wed Mar 4 14:50:04 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Mar 2015 06:50:04 -0800 Subject: 8u40 is released In-Reply-To: <54F71A5F.2030006@apache.org> References: <54F6324D.1060601@oracle.com> <54F71A5F.2030006@apache.org> Message-ID: <54F71B9C.6050809@oracle.com> Anton Tarasov or Andrew Brygin might be able to provide an answer for you, although our effort recently has been focused on getting the updated C++11-based WebKit to build. -- Kevin Emmanuel Bourg wrote: > Hi Kevin, > > I'm updating the OpenJFX package in Debian to the version 8u40-b25 > and I get a compilation failure on WebKit: > > In file included from /usr/include/x86_64-linux-gnu/unicode/utypes.h:36:0, > from /usr/include/x86_64-linux-gnu/unicode/ucnv_err.h:86, > from /usr/include/x86_64-linux-gnu/unicode/ucnv.h:50, > from /usr/include/libxml2/libxml/encoding.h:31, > from /usr/include/libxml2/libxml/parser.h:810, > from ../../../../src/main/native/Source/WebCore/xml/XSLStyleSheet.h:32, > from ../../../../src/main/native/Source/WebCore/xml/XSLTProcessor.h:29, > from generated/JSXSLTProcessor.h:27, > from generated/JSXSLTProcessor.cpp:25: > /usr/include/x86_64-linux-gnu/unicode/umachine.h:298:17: error: conflicting declaration ?typedef int32_t UChar32? > typedef int32_t UChar32; > ^ > In file included from ../../../../src/main/native/Source/WTF/wtf/unicode/Unicode.h:36:0, > from ../../../../src/main/native/Source/WTF/wtf/text/ASCIIFastPath.h:31, > from ../../../../src/main/native/Source/WTF/wtf/text/WTFString.h:28, > from ../../../../src/main/native/Source/WTF/wtf/DateMath.h:54, > from ../../../../src/main/native/Source/WebCore/webcorejava_pch.h:57: > ../../../../src/main/native/Source/WTF/wtf/unicode/java/UnicodeJava.h:24:18: note: previous declaration as ?typedef uint32_t UChar32? > typedef uint32_t UChar32; > ^ > > It seems UnicodeJava.h and UnicodeWchar.h define UChar32 as an unsigned int32 > whereas icu defines it as a signed int32. > > Emmanuel Bourg > > From ngalarneau at ABINITIO.COM Wed Mar 4 15:03:15 2015 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Wed, 4 Mar 2015 10:03:15 -0500 Subject: 8u40 is released In-Reply-To: <54F71AE6.907@oracle.com> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> Message-ID: Has Oracle stopped adding features to Scene Builder ? Does the code in the repo have support for the widgets introduced in 8u20 & 8u40? Thanks, Neil From: Kevin Rushforth To: ngalarneau at ABINITIO.COM, Cc: "openjfx-dev at openjdk.java.net" Date: 03/04/2015 09:47 AM Subject: Re: 8u40 is released Scene Builder source code is available in the OpenJFX repo under the BSD license, but separate binaries are no longer being released as of 8u40. See: http://www.oracle.com/technetwork/java/javase/downloads/sb2download-2177776.html -- Kevin ngalarneau at ABINITIO.COM wrote: Hurray! Thank you all for the good work. Do you know when the corresponding Scene Builder release will be? It would be great to get support for the new widgets. Also, the Scene Builder download page warns against using 2.0 for security reasons. Neil From: Kevin Rushforth To: "openjfx-dev at openjdk.java.net" , Date: 03/03/2015 05:14 PM Subject: 8u40 is released Sent by: "openjfx-dev" For those who haven't seen yet, the JDK 8u40 release is now live and ready for download. -- Kevin NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From kevin.rushforth at oracle.com Wed Mar 4 15:13:47 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Mar 2015 07:13:47 -0800 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> Message-ID: <54F7212B.3060307@oracle.com> Yes, the SceneBuilder source code in the repo has all the controls introduced between 8 and 8u40, specifically support for Dialogs and Spinner. -- Kevin ngalarneau at ABINITIO.COM wrote: > Has Oracle stopped adding features to Scene Builder ? > > Does the code in the repo have support for the widgets introduced in > 8u20 & 8u40? > > > Thanks, > > Neil > > > > > From: Kevin Rushforth > To: ngalarneau at ABINITIO.COM, > Cc: "openjfx-dev at openjdk.java.net" > Date: 03/04/2015 09:47 AM > Subject: Re: 8u40 is released > ------------------------------------------------------------------------ > > > > Scene Builder source code is available in the OpenJFX repo under the > BSD license, but separate binaries are no longer being released as of > 8u40. See: > _ > __http://www.oracle.com/technetwork/java/javase/downloads/sb2download-2177776.html_ > > -- Kevin > > _ > __ngalarneau at ABINITIO.COM_ wrote: > Hurray! > > Thank you all for the good work. > > Do you know when the corresponding Scene Builder release will be? > > It would be great to get support for the new widgets. Also, the Scene > Builder download page warns against using 2.0 for security reasons. > > > Neil > > > > > From: Kevin Rushforth __ > > To: _"openjfx-dev at openjdk.java.net"_ > __ > , > Date: 03/03/2015 05:14 PM > Subject: 8u40 is released > Sent by: "openjfx-dev" __ > > ------------------------------------------------------------------------ > > > > For those who haven't seen yet, the JDK 8u40 release is now live and > ready for download. > > -- Kevin > > > > > > NOTICE /from Ab Initio: This email (including any attachments) may > contain information that is subject to confidentiality obligations or > is legally privileged, and sender does not waive confidentiality or > privilege. If received in error, please notify the sender, delete this > email, and make no further use, disclosure, or distribution. / > > > > NOTICE /from Ab Initio: This email (including any attachments) may > contain information that is subject to confidentiality obligations or > is legally privileged, and sender does not waive confidentiality or > privilege. If received in error, please notify the sender, delete this > email, and make no further use, disclosure, or distribution. / From mike at plan99.net Wed Mar 4 15:31:12 2015 From: mike at plan99.net (Mike Hearn) Date: Wed, 4 Mar 2015 07:31:12 -0800 Subject: 8u40 is released In-Reply-To: <54F71AE6.907@oracle.com> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> Message-ID: Hi Kevin, Scene Builder source code is available in the OpenJFX repo under the BSD > license, but separate binaries are no longer being released as of 8u40. I'm a bit confused what this means. People who want to use Scene Builder are expected to compile it themselves from now on? Does that really make sense? Presumably the idea here is that SB will be integrated into IDEs and will no longer have any purpose as a standalone app, but I'm not sure we're ready to go there yet - the last time I tried the SB integration into IntelliJ it was extremely basic and far below the experience of the dedicated app. As just one example, UI design benefits a lot from maximal screen space. IDE embeddings often don't provide that. From kevin.rushforth at oracle.com Wed Mar 4 16:50:43 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Mar 2015 08:50:43 -0800 Subject: [8u] post-commit review for: RT-40186: Update copyright header for files modified in 2015 Message-ID: <54F737E3.6040602@oracle.com> JIRA: https://javafx-jira.kenai.com/browse/RT-40186 Webrev: http://cr.openjdk.java.net/~kcr/RT-40186/webrev.00/ Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f9a79df8559d Simple change to update copyright dates for all files modified in 2015. -- Kevin From kevin.rushforth at oracle.com Wed Mar 4 16:51:05 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Mar 2015 08:51:05 -0800 Subject: Please update copyright year to 2015 in any file you create / modify Message-ID: <54F737F9.3040600@oracle.com> A Belated Happy New Year OpenJFX folks! Since it is now 2015 (and has been for 2 months now), when you modify any source code file, please update the last copyright year in the Oracle copyright header to reflect this. Here are the three cases to consider. 1) A new file created this year You would use this: * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. 2) A file created and last touched in 2014 For example, the following: * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. would now be: * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights reserved. 3) A file created and last touched in two different prior years For example, the following: * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All rights reserved. would now be: * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights reserved. I just pushed a fix for files modified in the last two months, so no need for individual engineers to go back to previous fixes. Thank you. -- Kevin From anton.tarasov at oracle.com Wed Mar 4 17:21:43 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 04 Mar 2015 20:21:43 +0300 Subject: 8u40 is released In-Reply-To: <54F71B9C.6050809@oracle.com> References: <54F6324D.1060601@oracle.com> <54F71A5F.2030006@apache.org> <54F71B9C.6050809@oracle.com> Message-ID: <54F73F27.90706@oracle.com> Hi Emmanuel, jfx8u40/WebView (libjfxwebkit.so) doesn't link with icu lib, however it has that option and so it contains all the related headers which it nevertheless uses during the build process. UChar32 was defined as unsigned in older icu versions and it is still that in the jfx8u40/WebView sources. As to the failure you've encountered. It seems like you have libxml2 on your system which was compiled/installed with icu-enabled option. I'm afraid you should recompile it with icu disabled in order to build WebView. There's a similar issue reported against Qt WebKit port: https://bugs.webkit.org/show_bug.cgi?id=82824 Thanks, Anton. On 04.03.2015 17:50, Kevin Rushforth wrote: > Anton Tarasov or Andrew Brygin might be able to provide an answer for you, although our effort > recently has been focused on getting the updated C++11-based WebKit to build. > > -- Kevin > > > Emmanuel Bourg wrote: >> Hi Kevin, >> >> I'm updating the OpenJFX package in Debian to the version 8u40-b25 >> and I get a compilation failure on WebKit: >> >> In file included from /usr/include/x86_64-linux-gnu/unicode/utypes.h:36:0, >> from /usr/include/x86_64-linux-gnu/unicode/ucnv_err.h:86, >> from /usr/include/x86_64-linux-gnu/unicode/ucnv.h:50, >> from /usr/include/libxml2/libxml/encoding.h:31, >> from /usr/include/libxml2/libxml/parser.h:810, >> from ../../../../src/main/native/Source/WebCore/xml/XSLStyleSheet.h:32, >> from ../../../../src/main/native/Source/WebCore/xml/XSLTProcessor.h:29, >> from generated/JSXSLTProcessor.h:27, >> from generated/JSXSLTProcessor.cpp:25: >> /usr/include/x86_64-linux-gnu/unicode/umachine.h:298:17: error: conflicting declaration >> ?typedef int32_t UChar32? >> typedef int32_t UChar32; >> ^ >> In file included from ../../../../src/main/native/Source/WTF/wtf/unicode/Unicode.h:36:0, >> from ../../../../src/main/native/Source/WTF/wtf/text/ASCIIFastPath.h:31, >> from ../../../../src/main/native/Source/WTF/wtf/text/WTFString.h:28, >> from ../../../../src/main/native/Source/WTF/wtf/DateMath.h:54, >> from ../../../../src/main/native/Source/WebCore/webcorejava_pch.h:57: >> ../../../../src/main/native/Source/WTF/wtf/unicode/java/UnicodeJava.h:24:18: note: previous >> declaration as ?typedef uint32_t UChar32? >> typedef uint32_t UChar32; >> ^ >> >> It seems UnicodeJava.h and UnicodeWchar.h define UChar32 as an unsigned int32 >> whereas icu defines it as a signed int32. >> >> Emmanuel Bourg >> From krueger at lesspain.de Wed Mar 4 18:04:41 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Wed, 4 Mar 2015 19:04:41 +0100 Subject: Media player performance on Mac Message-ID: Hi, I just put a MediaView with a MediaPlayer into a FlowPane and displayed it. Playing a Full-HD H.264 file consumes between 40 and 60% of CPU. Playing the same file in Quicktime consumes about 3-4% CPU. What is the reason for the dramatic difference? Is the player subsystem not using hardware acceleration for decoding h.264? Is it something else intrinsic to MediaPlayer oder MediaView? I thought 8u40's media support was build on top of the AVFoundation framework and thus could compete with native players. Can I set a flag to force hardware acceleration? Is something being done about this? I am a bit worried that an application built on top of this would just eat up our users' battery like crazy. Best regards, Robert From kevin.rushforth at oracle.com Wed Mar 4 19:21:15 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Mar 2015 11:21:15 -0800 Subject: [8u] review request: RT-40193: Add new javafx.runtime.build property to javafx.properties file Message-ID: <54F75B2B.8000904@oracle.com> David, Please review this simple addition to javafx.properties. https://javafx-jira.kenai.com/browse/RT-40193 The patch is in the JIRA. -- Kevin From david.dehaven at oracle.com Wed Mar 4 19:28:21 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 4 Mar 2015 11:28:21 -0800 Subject: Media player performance on Mac In-Reply-To: References: Message-ID: <0ADF319B-E3CD-4DAA-8C62-8EBC2C517A2E@oracle.com> > I just put a MediaView with a MediaPlayer into a FlowPane and displayed it. > Playing a Full-HD H.264 file consumes between 40 and 60% of CPU. Playing > the same file in Quicktime consumes about 3-4% CPU. What is the reason for > the dramatic difference? Is the player subsystem not using hardware > acceleration for decoding h.264? Is it something else intrinsic to > MediaPlayer oder MediaView? I thought 8u40's media support was build on top > of the AVFoundation framework and thus could compete with native players. > Can I set a flag to force hardware acceleration? Is something being done > about this? I am a bit worried that an application built on top of this > would just eat up our users' battery like crazy. Can you link a sample of a movie that?s causing that much of a performance difference? There will always be a slight difference, but it should not be that much. Could also be helpful to know more details about the environment you?re running in. Keep in mind the new AVFoundation code is only supported on 10.8 and later due to the lack of certain required APIs in 10.7 and 10.6. -DrD- From johan at lodgon.com Wed Mar 4 19:39:50 2015 From: johan at lodgon.com (Johan Vos) Date: Wed, 4 Mar 2015 20:39:50 +0100 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> Message-ID: Oracle stated that they won't release new binaries for SceneBuilder, but since the code is open-source and BSD licensed, third parties and the Java Community in general can create binaries based on the SceneBuilder sources. This is what we did at Gluon (http://gluonhq.com), and the result can be downloaded at http://gluonhq.com/products/downloads/ This download is based on the latest 8u40 source code in OpenJFX. It includes the 8u40 Controls (e.g. Spinner, Dialogs). Hope this is helpful. - Johan 2015-03-04 16:31 GMT+01:00 Mike Hearn : > Hi Kevin, > > Scene Builder source code is available in the OpenJFX repo under the BSD > > license, but separate binaries are no longer being released as of 8u40. > > > I'm a bit confused what this means. > > People who want to use Scene Builder are expected to compile it themselves > from now on? Does that really make sense? Presumably the idea here is that > SB will be integrated into IDEs and will no longer have any purpose as a > standalone app, but I'm not sure we're ready to go there yet - the last > time I tried the SB integration into IntelliJ it was extremely basic and > far below the experience of the dedicated app. > > As just one example, UI design benefits a lot from maximal screen space. > IDE embeddings often don't provide that. > From kevin.rushforth at oracle.com Wed Mar 4 19:45:12 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Mar 2015 11:45:12 -0800 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> Message-ID: <54F760C8.5060309@oracle.com> Thanks, Johan! -- Kevin Johan Vos wrote: > Oracle stated that they won't release new binaries for SceneBuilder, > but since the code is open-source and BSD licensed, third parties and > the Java Community in general can create binaries based on the > SceneBuilder sources. > This is what we did at Gluon (http://gluonhq.com), and the result can > be downloaded at http://gluonhq.com/products/downloads/ > This download is based on the latest 8u40 source code in OpenJFX. It > includes the 8u40 Controls (e.g. Spinner, Dialogs). > > Hope this is helpful. > > - Johan > > 2015-03-04 16:31 GMT+01:00 Mike Hearn >: > > Hi Kevin, > > Scene Builder source code is available in the OpenJFX repo under > the BSD > > license, but separate binaries are no longer being released as of > 8u40. > > > I'm a bit confused what this means. > > People who want to use Scene Builder are expected to compile it > themselves > from now on? Does that really make sense? Presumably the idea here > is that > SB will be integrated into IDEs and will no longer have any > purpose as a > standalone app, but I'm not sure we're ready to go there yet - the > last > time I tried the SB integration into IntelliJ it was extremely > basic and > far below the experience of the dedicated app. > > As just one example, UI design benefits a lot from maximal screen > space. > IDE embeddings often don't provide that. > > From mike at plan99.net Wed Mar 4 22:14:17 2015 From: mike at plan99.net (Mike Hearn) Date: Wed, 4 Mar 2015 14:14:17 -0800 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> Message-ID: That's great Johan, but ...... what does this mean, exactly? Is SB effectively dead at this point? Short of some horrifically convoluted corporate politics I can't understand why Oracle would develop an application but not provide downloads of it. Does this mean SB won't be upgraded past 8u40? I mean - I don't think it's unreasonable of me to be surprised by this, and I thought I followed JFX development pretty closely. What's the story here? On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos wrote: > Oracle stated that they won't release new binaries for SceneBuilder, but > since the code is open-source and BSD licensed, third parties and the Java > Community in general can create binaries based on the SceneBuilder sources. > This is what we did at Gluon (http://gluonhq.com), and the result can be > downloaded at http://gluonhq.com/products/downloads/ > This download is based on the latest 8u40 source code in OpenJFX. It > includes the 8u40 Controls (e.g. Spinner, Dialogs). > > Hope this is helpful. > > - Johan > > 2015-03-04 16:31 GMT+01:00 Mike Hearn : > >> Hi Kevin, >> >> Scene Builder source code is available in the OpenJFX repo under the BSD >> > license, but separate binaries are no longer being released as of 8u40. >> >> >> I'm a bit confused what this means. >> >> People who want to use Scene Builder are expected to compile it themselves >> from now on? Does that really make sense? Presumably the idea here is that >> SB will be integrated into IDEs and will no longer have any purpose as a >> standalone app, but I'm not sure we're ready to go there yet - the last >> time I tried the SB integration into IntelliJ it was extremely basic and >> far below the experience of the dedicated app. >> >> As just one example, UI design benefits a lot from maximal screen space. >> IDE embeddings often don't provide that. >> > > From tobi at ultramixer.com Wed Mar 4 22:18:23 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 4 Mar 2015 23:18:23 +0100 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> Message-ID: <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> In the past there were 2 bad signs from Oracle concerning JavaFX: end of support for JavaFX on RaspPi and SceneBuilder? So does have JavaFX a future? Tobi > Am 04.03.2015 um 23:14 schrieb Mike Hearn : > > That's great Johan, but ...... what does this mean, exactly? Is SB > effectively dead at this point? Short of some horrifically convoluted > corporate politics I can't understand why Oracle would develop an > application but not provide downloads of it. Does this mean SB won't be > upgraded past 8u40? > > I mean - I don't think it's unreasonable of me to be surprised by this, and > I thought I followed JFX development pretty closely. What's the story here? > > On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos wrote: > >> Oracle stated that they won't release new binaries for SceneBuilder, but >> since the code is open-source and BSD licensed, third parties and the Java >> Community in general can create binaries based on the SceneBuilder sources. >> This is what we did at Gluon (http://gluonhq.com), and the result can be >> downloaded at http://gluonhq.com/products/downloads/ >> This download is based on the latest 8u40 source code in OpenJFX. It >> includes the 8u40 Controls (e.g. Spinner, Dialogs). >> >> Hope this is helpful. >> >> - Johan >> >> 2015-03-04 16:31 GMT+01:00 Mike Hearn : >> >>> Hi Kevin, >>> >>> Scene Builder source code is available in the OpenJFX repo under the BSD >>>> license, but separate binaries are no longer being released as of 8u40. >>> >>> >>> I'm a bit confused what this means. >>> >>> People who want to use Scene Builder are expected to compile it themselves >>> from now on? Does that really make sense? Presumably the idea here is that >>> SB will be integrated into IDEs and will no longer have any purpose as a >>> standalone app, but I'm not sure we're ready to go there yet - the last >>> time I tried the SB integration into IntelliJ it was extremely basic and >>> far below the experience of the dedicated app. >>> >>> As just one example, UI design benefits a lot from maximal screen space. >>> IDE embeddings often don't provide that. >>> >> >> From felix.bembrick at gmail.com Wed Mar 4 22:29:39 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 5 Mar 2015 09:29:39 +1100 Subject: 8u40 is released In-Reply-To: <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> Message-ID: JavaFX has a future but perhaps not the one we were all expecting or hoping for. On 5 March 2015 at 09:18, Tobias Bley wrote: > In the past there were 2 bad signs from Oracle concerning JavaFX: end of > support for JavaFX on RaspPi and SceneBuilder? > > So does have JavaFX a future? > > Tobi > > > > Am 04.03.2015 um 23:14 schrieb Mike Hearn : > > > > That's great Johan, but ...... what does this mean, exactly? Is SB > > effectively dead at this point? Short of some horrifically convoluted > > corporate politics I can't understand why Oracle would develop an > > application but not provide downloads of it. Does this mean SB won't be > > upgraded past 8u40? > > > > I mean - I don't think it's unreasonable of me to be surprised by this, > and > > I thought I followed JFX development pretty closely. What's the story > here? > > > > On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos wrote: > > > >> Oracle stated that they won't release new binaries for SceneBuilder, but > >> since the code is open-source and BSD licensed, third parties and the > Java > >> Community in general can create binaries based on the SceneBuilder > sources. > >> This is what we did at Gluon (http://gluonhq.com), and the result can > be > >> downloaded at http://gluonhq.com/products/downloads/ > >> This download is based on the latest 8u40 source code in OpenJFX. It > >> includes the 8u40 Controls (e.g. Spinner, Dialogs). > >> > >> Hope this is helpful. > >> > >> - Johan > >> > >> 2015-03-04 16:31 GMT+01:00 Mike Hearn : > >> > >>> Hi Kevin, > >>> > >>> Scene Builder source code is available in the OpenJFX repo under the > BSD > >>>> license, but separate binaries are no longer being released as of > 8u40. > >>> > >>> > >>> I'm a bit confused what this means. > >>> > >>> People who want to use Scene Builder are expected to compile it > themselves > >>> from now on? Does that really make sense? Presumably the idea here is > that > >>> SB will be integrated into IDEs and will no longer have any purpose as > a > >>> standalone app, but I'm not sure we're ready to go there yet - the last > >>> time I tried the SB integration into IntelliJ it was extremely basic > and > >>> far below the experience of the dedicated app. > >>> > >>> As just one example, UI design benefits a lot from maximal screen > space. > >>> IDE embeddings often don't provide that. > >>> > >> > >> > > From jonathan.giles at oracle.com Wed Mar 4 22:31:09 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 05 Mar 2015 11:31:09 +1300 Subject: 8u40 is released In-Reply-To: <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> Message-ID: <54F787AD.2090303@oracle.com> I wish I could answer your concerns, but unfortunately asking business questions on a developer list, where the developers are always the last to know of plans, is probably not going to yield satisfactory results. In fact, because we have nothing to say you'll normally be met with silence, which in your mind might lead to your concerns being amplified :-) The best I can say is two things we are actively working on JavaFX 8u60 and 9. I personally don't know why decisions are made the way they are (with regards to Scene Builder builds or JavaFX on ARM) - it is what it is and my job is to just keep churning out the code, not make the business decisions. -- Jonathan On 5/03/2015 11:18 a.m., Tobias Bley wrote: > In the past there were 2 bad signs from Oracle concerning JavaFX: end of support for JavaFX on RaspPi and SceneBuilder? > > So does have JavaFX a future? > > Tobi > > >> Am 04.03.2015 um 23:14 schrieb Mike Hearn : >> >> That's great Johan, but ...... what does this mean, exactly? Is SB >> effectively dead at this point? Short of some horrifically convoluted >> corporate politics I can't understand why Oracle would develop an >> application but not provide downloads of it. Does this mean SB won't be >> upgraded past 8u40? >> >> I mean - I don't think it's unreasonable of me to be surprised by this, and >> I thought I followed JFX development pretty closely. What's the story here? >> >> On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos wrote: >> >>> Oracle stated that they won't release new binaries for SceneBuilder, but >>> since the code is open-source and BSD licensed, third parties and the Java >>> Community in general can create binaries based on the SceneBuilder sources. >>> This is what we did at Gluon (http://gluonhq.com), and the result can be >>> downloaded at http://gluonhq.com/products/downloads/ >>> This download is based on the latest 8u40 source code in OpenJFX. It >>> includes the 8u40 Controls (e.g. Spinner, Dialogs). >>> >>> Hope this is helpful. >>> >>> - Johan >>> >>> 2015-03-04 16:31 GMT+01:00 Mike Hearn : >>> >>>> Hi Kevin, >>>> >>>> Scene Builder source code is available in the OpenJFX repo under the BSD >>>>> license, but separate binaries are no longer being released as of 8u40. >>>> >>>> I'm a bit confused what this means. >>>> >>>> People who want to use Scene Builder are expected to compile it themselves >>>> from now on? Does that really make sense? Presumably the idea here is that >>>> SB will be integrated into IDEs and will no longer have any purpose as a >>>> standalone app, but I'm not sure we're ready to go there yet - the last >>>> time I tried the SB integration into IntelliJ it was extremely basic and >>>> far below the experience of the dedicated app. >>>> >>>> As just one example, UI design benefits a lot from maximal screen space. >>>> IDE embeddings often don't provide that. >>>> >>> From tobi at ultramixer.com Wed Mar 4 22:32:32 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 4 Mar 2015 23:32:32 +0100 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> Message-ID: <3ED9D236-1A3B-4656-B99E-69159A1085C3@ultramixer.com> which future should it be? IoT? > Am 04.03.2015 um 23:29 schrieb Felix Bembrick : > > JavaFX has a future but perhaps not the one we were all expecting or hoping for. > > On 5 March 2015 at 09:18, Tobias Bley > wrote: > In the past there were 2 bad signs from Oracle concerning JavaFX: end of support for JavaFX on RaspPi and SceneBuilder? > > So does have JavaFX a future? > > Tobi > > > > Am 04.03.2015 um 23:14 schrieb Mike Hearn >: > > > > That's great Johan, but ...... what does this mean, exactly? Is SB > > effectively dead at this point? Short of some horrifically convoluted > > corporate politics I can't understand why Oracle would develop an > > application but not provide downloads of it. Does this mean SB won't be > > upgraded past 8u40? > > > > I mean - I don't think it's unreasonable of me to be surprised by this, and > > I thought I followed JFX development pretty closely. What's the story here? > > > > On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos > wrote: > > > >> Oracle stated that they won't release new binaries for SceneBuilder, but > >> since the code is open-source and BSD licensed, third parties and the Java > >> Community in general can create binaries based on the SceneBuilder sources. > >> This is what we did at Gluon (http://gluonhq.com ), and the result can be > >> downloaded at http://gluonhq.com/products/downloads/ > >> This download is based on the latest 8u40 source code in OpenJFX. It > >> includes the 8u40 Controls (e.g. Spinner, Dialogs). > >> > >> Hope this is helpful. > >> > >> - Johan > >> > >> 2015-03-04 16:31 GMT+01:00 Mike Hearn >: > >> > >>> Hi Kevin, > >>> > >>> Scene Builder source code is available in the OpenJFX repo under the BSD > >>>> license, but separate binaries are no longer being released as of 8u40. > >>> > >>> > >>> I'm a bit confused what this means. > >>> > >>> People who want to use Scene Builder are expected to compile it themselves > >>> from now on? Does that really make sense? Presumably the idea here is that > >>> SB will be integrated into IDEs and will no longer have any purpose as a > >>> standalone app, but I'm not sure we're ready to go there yet - the last > >>> time I tried the SB integration into IntelliJ it was extremely basic and > >>> far below the experience of the dedicated app. > >>> > >>> As just one example, UI design benefits a lot from maximal screen space. > >>> IDE embeddings often don't provide that. > >>> > >> > >> > > From tomas.mikula at gmail.com Wed Mar 4 23:01:49 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Wed, 4 Mar 2015 18:01:49 -0500 Subject: 8u40 is released In-Reply-To: <3ED9D236-1A3B-4656-B99E-69159A1085C3@ultramixer.com> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <3ED9D236-1A3B-4656-B99E-69159A1085C3@ultramixer.com> Message-ID: To add fuel to the fire, I have seen issues in the JIRA going from "assigned" to "unassigned", for multiple assignees. Also, Steve is now (back) at IBM: https://ca.linkedin.com/in/stevenorthover. On Wed, Mar 4, 2015 at 5:32 PM, Tobias Bley wrote: > which future should it be? IoT? > > >> Am 04.03.2015 um 23:29 schrieb Felix Bembrick : >> >> JavaFX has a future but perhaps not the one we were all expecting or hoping for. >> >> On 5 March 2015 at 09:18, Tobias Bley > wrote: >> In the past there were 2 bad signs from Oracle concerning JavaFX: end of support for JavaFX on RaspPi and SceneBuilder? >> >> So does have JavaFX a future? >> >> Tobi >> >> >> > Am 04.03.2015 um 23:14 schrieb Mike Hearn >: >> > >> > That's great Johan, but ...... what does this mean, exactly? Is SB >> > effectively dead at this point? Short of some horrifically convoluted >> > corporate politics I can't understand why Oracle would develop an >> > application but not provide downloads of it. Does this mean SB won't be >> > upgraded past 8u40? >> > >> > I mean - I don't think it's unreasonable of me to be surprised by this, and >> > I thought I followed JFX development pretty closely. What's the story here? >> > >> > On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos > wrote: >> > >> >> Oracle stated that they won't release new binaries for SceneBuilder, but >> >> since the code is open-source and BSD licensed, third parties and the Java >> >> Community in general can create binaries based on the SceneBuilder sources. >> >> This is what we did at Gluon (http://gluonhq.com ), and the result can be >> >> downloaded at http://gluonhq.com/products/downloads/ >> >> This download is based on the latest 8u40 source code in OpenJFX. It >> >> includes the 8u40 Controls (e.g. Spinner, Dialogs). >> >> >> >> Hope this is helpful. >> >> >> >> - Johan >> >> >> >> 2015-03-04 16:31 GMT+01:00 Mike Hearn >: >> >> >> >>> Hi Kevin, >> >>> >> >>> Scene Builder source code is available in the OpenJFX repo under the BSD >> >>>> license, but separate binaries are no longer being released as of 8u40. >> >>> >> >>> >> >>> I'm a bit confused what this means. >> >>> >> >>> People who want to use Scene Builder are expected to compile it themselves >> >>> from now on? Does that really make sense? Presumably the idea here is that >> >>> SB will be integrated into IDEs and will no longer have any purpose as a >> >>> standalone app, but I'm not sure we're ready to go there yet - the last >> >>> time I tried the SB integration into IntelliJ it was extremely basic and >> >>> far below the experience of the dedicated app. >> >>> >> >>> As just one example, UI design benefits a lot from maximal screen space. >> >>> IDE embeddings often don't provide that. >> >>> >> >> >> >> >> >> > From mike at plan99.net Thu Mar 5 00:50:23 2015 From: mike at plan99.net (Mike Hearn) Date: Wed, 4 Mar 2015 16:50:23 -0800 Subject: 8u40 is released In-Reply-To: <54F787AD.2090303@oracle.com> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> Message-ID: Hey Jonathan, If you let us know who does make these decisions, we will happily repeat our questions to them :) Mark Reinhold perhaps? I mean, I appreciate that GUI libraries are probably not a prime driver of sales for Oracle, but as an enterprise focused company I assume management understands the value of being able to do long term planning around any tool or API. WRT 8u60+9, I read that 8u60 is going to be a bug fix only release with no new features at all. I don't know how to read that, as JavaFX does not seem especially buggy to me, and previously it seemed that rich text might feature. It feels that manpower put on JFX is indeed being reduced. Perhaps a business opportunity for someone who wants to be the next Trolltech :-) From mike at plan99.net Thu Mar 5 00:58:17 2015 From: mike at plan99.net (Mike Hearn) Date: Wed, 4 Mar 2015 16:58:17 -0800 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> Message-ID: > > This is what we did at Gluon (http://gluonhq.com), and the result can be > downloaded at http://gluonhq.com/products/downloads/ > Thanks Johan! Looks like Gluon is the Trolltech equivalent I just wished for - that was fast :-) >From your blog post, it sounds like you're planning to fork SB or at least maintain a patch set on top of it. So I guess you have reason to believe SB upstream is a dead project at this point? If you let me know when you have a public repository, I'll take a look at contributing an integration of UpdateFX and CrashFX. Users would still need to re-download the app to upgrade the JVM across major releases but other changes could be pushed easily to all users in the background. I'm also interested in making it more keyboardable, in particular shortcuts for wrapping/unwrapping would be useful and ability to insert controls based on an auto complete of the name. From tomas.mikula at gmail.com Thu Mar 5 01:25:47 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Wed, 4 Mar 2015 20:25:47 -0500 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> Message-ID: On Wed, Mar 4, 2015 at 7:50 PM, Mike Hearn wrote: > WRT 8u60+9, I read that 8u60 is going to be a bug fix only release with no > new features at all. I don't know how to read that, as JavaFX does not seem > especially buggy to me, 2349 Unresolved Bugs seems buggy to me: https://javafx-jira.kenai.com/issues/?jql=issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved I personally don't mind if higher-level projects like SceneBuilder are handed to the community, as long as Oracle keeps maintaining a healthy and _portable_ core. From mike at plan99.net Thu Mar 5 01:34:17 2015 From: mike at plan99.net (Mike Hearn) Date: Wed, 4 Mar 2015 17:34:17 -0800 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> Message-ID: > > 2349 Unresolved Bugs seems buggy to me: > > https://javafx-jira.kenai.com/issues/?jql=issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved Any software project always has lots of unresolved issues in the issue tracker, though, especially something as large as a UI toolkit. Qt has about 15,000 open issues: https://bugreports.qt.io/browse/QTWEBSITE-628?jql=status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Accepted%2C%20Reported) Actually 2349 bugs feels suspiciously low to me ..... I suspect it reflects more that the JFX user community is quite small rather than the true number of bugs in the product :-) I certainly encountered a few bugs when writing my own app, but they were all easy to work around and so far they were all fixed in 8u40. Perhaps my experience is atypical. I agree that SB is probably something that can be well maintained by the community at this point, especially with commercial backing from Gluon. From tbee at tbee.org Thu Mar 5 08:19:36 2015 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 05 Mar 2015 09:19:36 +0100 Subject: 8u40 is released / SB In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> Message-ID: <54F81198.9090704@tbee.org> My two cents would be that maintaining a UI builder is an awful lot of work, while I expect that a lot of programmers won't be using SB because it always has limitations. Either with complex layouts or custom controls. "Real" programmers probably use FXML directly or even just code it in Java. So the "return on investment" probably is fairly low and thus the resources can be much better spent on the core. IMHO. On 5-3-2015 02:34, Mike Hearn wrote: > I agree that SB is probably something that can be well maintained by the > community at this point, especially with commercial backing from Gluon From hastebrot at gmail.com Thu Mar 5 08:30:47 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Thu, 5 Mar 2015 09:30:47 +0100 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> Message-ID: > > Looks like Gluon is the Trolltech equivalent I just wished > for - that was fast :-) > I had a similar thought. Honestly this reminds me a bit more to JGoodies and the tools around it, but with a lot more. Looks good. Hope that Gluon takes the mobile ports for JavaFX and SceneBuilder to the next level and allow open-source contributions. Also noticed the support for Material design on Android. > If you let me know when you have a public repository, I'll take a look at > contributing an integration of UpdateFX and CrashFX. Why don't I know about these projects? They look very useful! :D Maybe I'm on the wrong communication channels. > I'm also interested in making it more keyboardable, in particular shortcuts > for wrapping/unwrapping would be useful and ability to insert controls > based on an auto complete of the name. > A keyboard shortcuts editor would be nice. I wish I could toggle the left and right panes with ALT-1 and ALT-2. A IntelliJ-esque action palette to insert controls would be very nice. --Benjamin From tobi at ultramixer.com Thu Mar 5 08:36:50 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Thu, 5 Mar 2015 09:36:50 +0100 Subject: 8u40 is released / SB In-Reply-To: <54F81198.9090704@tbee.org> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> Message-ID: <15CCA320-0C81-4640-A0AB-53B52A105655@ultramixer.com> But what about Xcode GUI design? Android Studio GUI designer? QT Designer? ? > Am 05.03.2015 um 09:19 schrieb Tom Eugelink : > > My two cents would be that maintaining a UI builder is an awful lot of work, while I expect that a lot of programmers won't be using SB because it always has limitations. Either with complex layouts or custom controls. "Real" programmers probably use FXML directly or even just code it in Java. So the "return on investment" probably is fairly low and thus the resources can be much better spent on the core. IMHO. > > > On 5-3-2015 02:34, Mike Hearn wrote: >> I agree that SB is probably something that can be well maintained by the >> community at this point, especially with commercial backing from Gluon > From johan at lodgon.com Thu Mar 5 08:46:09 2015 From: johan at lodgon.com (Johan Vos) Date: Thu, 5 Mar 2015 09:46:09 +0100 Subject: 8u40 is released In-Reply-To: <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> Message-ID: I think it is really important to make a clear distinction between Oracle as a (database/middleware) company and Oracle as the Java Steward. As a Java Steward, Oracle is dedicated to the future of Java, which includes JavaFX. The Oracle engineers contribute most of the code and provide excellent support and communication to the community. As a company, Oracle can decide that e.g. a commercially supported SceneBuilder, or JavaFX on embedded, or whatever... is not in line with their business goals. However, this does not mean that the technology is not good or has no chance in another business constellation. I am not in the business of selling cars, but that does not mean I don't believe in the car industry. Personally, I think that both SceneBuilder and JavaFX on Pi could lead to more revenue on the backend, but if Oracle doesn't see it this way, hey it's their business decision :) Good enough, they take their job as a Java Steward serious, and that shows by the many great features that have been added in JavaFX 8u40. - Johan 2015-03-04 23:18 GMT+01:00 Tobias Bley : > In the past there were 2 bad signs from Oracle concerning JavaFX: end of > support for JavaFX on RaspPi and SceneBuilder... > > So does have JavaFX a future? > > Tobi > > > > Am 04.03.2015 um 23:14 schrieb Mike Hearn : > > > > That's great Johan, but ...... what does this mean, exactly? Is SB > > effectively dead at this point? Short of some horrifically convoluted > > corporate politics I can't understand why Oracle would develop an > > application but not provide downloads of it. Does this mean SB won't be > > upgraded past 8u40? > > > > I mean - I don't think it's unreasonable of me to be surprised by this, > and > > I thought I followed JFX development pretty closely. What's the story > here? > > > > On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos wrote: > > > >> Oracle stated that they won't release new binaries for SceneBuilder, but > >> since the code is open-source and BSD licensed, third parties and the > Java > >> Community in general can create binaries based on the SceneBuilder > sources. > >> This is what we did at Gluon (http://gluonhq.com), and the result can > be > >> downloaded at http://gluonhq.com/products/downloads/ > >> This download is based on the latest 8u40 source code in OpenJFX. It > >> includes the 8u40 Controls (e.g. Spinner, Dialogs). > >> > >> Hope this is helpful. > >> > >> - Johan > >> > >> 2015-03-04 16:31 GMT+01:00 Mike Hearn : > >> > >>> Hi Kevin, > >>> > >>> Scene Builder source code is available in the OpenJFX repo under the > BSD > >>>> license, but separate binaries are no longer being released as of > 8u40. > >>> > >>> > >>> I'm a bit confused what this means. > >>> > >>> People who want to use Scene Builder are expected to compile it > themselves > >>> from now on? Does that really make sense? Presumably the idea here is > that > >>> SB will be integrated into IDEs and will no longer have any purpose as > a > >>> standalone app, but I'm not sure we're ready to go there yet - the last > >>> time I tried the SB integration into IntelliJ it was extremely basic > and > >>> far below the experience of the dedicated app. > >>> > >>> As just one example, UI design benefits a lot from maximal screen > space. > >>> IDE embeddings often don't provide that. > >>> > >> > >> > > From tbee at tbee.org Thu Mar 5 08:46:25 2015 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 05 Mar 2015 09:46:25 +0100 Subject: 8u40 is released / SB In-Reply-To: <15CCA320-0C81-4640-A0AB-53B52A105655@ultramixer.com> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <15CCA320-0C81-4640-A0AB-53B52A105655@ultramixer.com> Message-ID: <54F817E1.7070106@tbee.org> That fact that companies are willing to invest in those editors is great; I've coded for iOS and Android, but quickly stopped using the designers. Interesting is that there is no commonly used UI designer for Swing. There were some attempts, I believe NetBeans still has one, but I know of no project that uses them (that may be my shortcoming). For me they quickly get in the way. The only exception being Flash, because there was no way around the UI editor. And I hated flash for it ;-) On 5-3-2015 09:36, Tobias Bley wrote: > But what about Xcode GUI design? Android Studio GUI designer? QT Designer? ? > > >> Am 05.03.2015 um 09:19 schrieb Tom Eugelink : >> >> My two cents would be that maintaining a UI builder is an awful lot of work, while I expect that a lot of programmers won't be using SB because it always has limitations. Either with complex layouts or custom controls. "Real" programmers probably use FXML directly or even just code it in Java. So the "return on investment" probably is fairly low and thus the resources can be much better spent on the core. IMHO. >> >> >> On 5-3-2015 02:34, Mike Hearn wrote: >>> I agree that SB is probably something that can be well maintained by the >>> community at this point, especially with commercial backing from Gluon From hastebrot at gmail.com Thu Mar 5 08:47:05 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Thu, 5 Mar 2015 09:47:05 +0100 Subject: 8u40 is released / SB In-Reply-To: <54F81198.9090704@tbee.org> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> Message-ID: Hi Tom! As a programmer I use SB for prototyping. I think the problem is, that designers really need a visual UI and CSS editor. Upcoming web-standards like Web Components and frameworks like Google Polymer really shine, when it comes to connection between programmers and designers. --Benjamin On Thu, Mar 5, 2015 at 9:19 AM, Tom Eugelink wrote: > My two cents would be that maintaining a UI builder is an awful lot of > work, while I expect that a lot of programmers won't be using SB because it > always has limitations. Either with complex layouts or custom controls. > "Real" programmers probably use FXML directly or even just code it in Java. > So the "return on investment" probably is fairly low and thus the resources > can be much better spent on the core. IMHO. > > > On 5-3-2015 02:34, Mike Hearn wrote: > >> I agree that SB is probably something that can be well maintained by the >> community at this point, especially with commercial backing from Gluon >> > > From krueger at lesspain.de Thu Mar 5 10:06:02 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Thu, 5 Mar 2015 11:06:02 +0100 Subject: Media player performance on Mac In-Reply-To: <0ADF319B-E3CD-4DAA-8C62-8EBC2C517A2E@oracle.com> References: <0ADF319B-E3CD-4DAA-8C62-8EBC2C517A2E@oracle.com> Message-ID: I am running 10.10.1 and the video is a standard h.264 export from FCPX, so nothing special. I have tried other plain h.264 videos (an iTunes trailer) with the same result. Have you tried it on Mac? Another thing that is strange is that files with mov-Extensions do not seem to be allowed. I had to rename a file to mp4 for it to be accepted. That feels a bit weird, if the underlying framework is really AVFoundation. This is the code I used for testing: import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.layout.FlowPane; import javafx.scene.media.Media; import javafx.scene.media.MediaPlayer; import javafx.scene.media.MediaView; import javafx.stage.Stage; import java.util.List; /** * Simple Media Player Example */ public class MediaPlayerExample extends Application { @Override public void start(Stage stage) throws Exception { FlowPane pane = new FlowPane(); final List args = getParameters().getRaw(); if(args.isEmpty()){ throw new IllegalStateException("no file specified"); } final String file = args.get(0); final Media media = new Media(file); final MediaPlayer player = new MediaPlayer(media); MediaView mediaView = new MediaView(player); mediaView.setOnMouseClicked((e)->{ if(player.getStatus() == MediaPlayer.Status.PAUSED){ player.play(); } else if(player.getStatus() == MediaPlayer.Status.PLAYING){ player.pause(); } }); mediaView.setFitWidth(800); mediaView.setFitHeight(600); pane.getChildren().add(mediaView); final Scene scene = new Scene(pane); stage.setScene(scene); stage.setTitle(getClass().getSimpleName()); stage.sizeToScene(); stage.show(); player.play(); } public static void main(String[] args) { launch(args); } } On Wed, Mar 4, 2015 at 8:28 PM, David DeHaven wrote: > > > I just put a MediaView with a MediaPlayer into a FlowPane and displayed > it. > > Playing a Full-HD H.264 file consumes between 40 and 60% of CPU. Playing > > the same file in Quicktime consumes about 3-4% CPU. What is the reason > for > > the dramatic difference? Is the player subsystem not using hardware > > acceleration for decoding h.264? Is it something else intrinsic to > > MediaPlayer oder MediaView? I thought 8u40's media support was build on > top > > of the AVFoundation framework and thus could compete with native players. > > Can I set a flag to force hardware acceleration? Is something being done > > about this? I am a bit worried that an application built on top of this > > would just eat up our users' battery like crazy. > > Can you link a sample of a movie that?s causing that much of a performance > difference? There will always be a slight difference, but it should not be > that much. > > Could also be helpful to know more details about the environment you?re > running in. Keep in mind the new AVFoundation code is only supported on > 10.8 and later due to the lack of certain required APIs in 10.7 and 10.6. > > -DrD- > > -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From swpalmer at gmail.com Thu Mar 5 12:20:05 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 5 Mar 2015 07:20:05 -0500 Subject: 8u40 is released / SB In-Reply-To: <54F81198.9090704@tbee.org> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> Message-ID: <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> I would never consider for a second coding FXML "directly". I have only tweaked it by hand occasionally after creating it with SceneBuilder. SB is an important selling point for JavaFX and should be included in the JDK, it shouldn't even be a separate download. Scott > On Mar 5, 2015, at 3:19 AM, Tom Eugelink wrote: > > My two cents would be that maintaining a UI builder is an awful lot of work, while I expect that a lot of programmers won't be using SB because it always has limitations. Either with complex layouts or custom controls. "Real" programmers probably use FXML directly or even just code it in Java. So the "return on investment" probably is fairly low and thus the resources can be much better spent on the core. IMHO. > > >> On 5-3-2015 02:34, Mike Hearn wrote: >> I agree that SB is probably something that can be well maintained by the >> community at this point, especially with commercial backing from Gluon > From dschaefer at qnx.com Thu Mar 5 14:58:05 2015 From: dschaefer at qnx.com (Doug Schaefer) Date: Thu, 5 Mar 2015 14:58:05 +0000 Subject: 8u40 is released / SB In-Reply-To: <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> Message-ID: GUI builders are great for prototyping or helping you learn. But when the application gets complex I keep hearing developers throw them out. They start getting in the way. I think if you have a good API and a good declarative UI language, think QML not FXML, then you may find you don?t really need a GUI builder. How may people are using GUI builders to create Web app UI?s? Now web UIs are simpler, but maybe that?s the point. And why not leave GUI builders to the tools vendors. They?re hard to make and get right, especially of you don?t have a revenue model to support the army of developers you need. Doug. Hmm, I wonder what React Native would look like with JavaFX and Nashorn? On 2015-03-05, 7:20 AM, "Scott Palmer" wrote: >I would never consider for a second coding FXML "directly". I have only >tweaked it by hand occasionally after creating it with SceneBuilder. SB >is an important selling point for JavaFX and should be included in the >JDK, it shouldn't even be a separate download. > >Scott > >> On Mar 5, 2015, at 3:19 AM, Tom Eugelink wrote: >> >> My two cents would be that maintaining a UI builder is an awful lot of >>work, while I expect that a lot of programmers won't be using SB because >>it always has limitations. Either with complex layouts or custom >>controls. "Real" programmers probably use FXML directly or even just >>code it in Java. So the "return on investment" probably is fairly low >>and thus the resources can be much better spent on the core. IMHO. >> >> >>> On 5-3-2015 02:34, Mike Hearn wrote: >>> I agree that SB is probably something that can be well maintained by >>>the >>> community at this point, especially with commercial backing from Gluon >> From ngalarneau at ABINITIO.COM Thu Mar 5 15:08:45 2015 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Thu, 5 Mar 2015 10:08:45 -0500 Subject: QML vs. FXML In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> Message-ID: Doug, You said: "good declarative UI language, think QML not FXML". What do you see as the advantages of QML over FXML? Neil From: Doug Schaefer To: "openjfx-dev at openjdk.java.net" , Date: 03/05/2015 10:00 AM Subject: Re: 8u40 is released / SB Sent by: "openjfx-dev" GUI builders are great for prototyping or helping you learn. But when the application gets complex I keep hearing developers throw them out. They start getting in the way. I think if you have a good API and a good declarative UI language, think QML not FXML, then you may find you don?t really need a GUI builder. How may people are using GUI builders to create Web app UI?s? Now web UIs are simpler, but maybe that?s the point. And why not leave GUI builders to the tools vendors. They?re hard to make and get right, especially of you don?t have a revenue model to support the army of developers you need. Doug. Hmm, I wonder what React Native would look like with JavaFX and Nashorn? On 2015-03-05, 7:20 AM, "Scott Palmer" wrote: >I would never consider for a second coding FXML "directly". I have only >tweaked it by hand occasionally after creating it with SceneBuilder. SB >is an important selling point for JavaFX and should be included in the >JDK, it shouldn't even be a separate download. > >Scott > >> On Mar 5, 2015, at 3:19 AM, Tom Eugelink wrote: >> >> My two cents would be that maintaining a UI builder is an awful lot of >>work, while I expect that a lot of programmers won't be using SB because >>it always has limitations. Either with complex layouts or custom >>controls. "Real" programmers probably use FXML directly or even just >>code it in Java. So the "return on investment" probably is fairly low >>and thus the resources can be much better spent on the core. IMHO. >> >> >>> On 5-3-2015 02:34, Mike Hearn wrote: >>> I agree that SB is probably something that can be well maintained by >>>the >>> community at this point, especially with commercial backing from Gluon >> NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From dschaefer at qnx.com Thu Mar 5 15:23:08 2015 From: dschaefer at qnx.com (Doug Schaefer) Date: Thu, 5 Mar 2015 15:23:08 +0000 Subject: QML vs. FXML In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> Message-ID: In general, it?s an argument against writing code in XML. XML was really meant to be a machine to machine language, to make things like SceneBuilder easier to write :). People came second. You really want to use a domain specific language that?s easy to read and write. QML is that. I find XML tags overwhelm the rest of the text making it hard to understand what?s going on, and hard to write unless you have a good XML editor. QML has less cruft and it?s easier to see what?s happening with a quick glance. Now, having said that, HTML seems to be pretty popular? Doug. From: "ngalarneau at ABINITIO.COM" > Date: Thursday, March 5, 2015 at 10:08 AM To: Doug Schaefer > Cc: "openjfx-dev at openjdk.java.net" > Subject: QML vs. FXML Doug, You said: "good declarative UI language, think QML not FXML". What do you see as the advantages of QML over FXML? Neil From: Doug Schaefer > To: "openjfx-dev at openjdk.java.net" >, Date: 03/05/2015 10:00 AM Subject: Re: 8u40 is released / SB Sent by: "openjfx-dev" > ________________________________ GUI builders are great for prototyping or helping you learn. But when the application gets complex I keep hearing developers throw them out. They start getting in the way. I think if you have a good API and a good declarative UI language, think QML not FXML, then you may find you don?t really need a GUI builder. How may people are using GUI builders to create Web app UI?s? Now web UIs are simpler, but maybe that?s the point. And why not leave GUI builders to the tools vendors. They?re hard to make and get right, especially of you don?t have a revenue model to support the army of developers you need. Doug. Hmm, I wonder what React Native would look like with JavaFX and Nashorn? On 2015-03-05, 7:20 AM, "Scott Palmer" > wrote: >I would never consider for a second coding FXML "directly". I have only >tweaked it by hand occasionally after creating it with SceneBuilder. SB >is an important selling point for JavaFX and should be included in the >JDK, it shouldn't even be a separate download. > >Scott > >> On Mar 5, 2015, at 3:19 AM, Tom Eugelink > wrote: >> >> My two cents would be that maintaining a UI builder is an awful lot of >>work, while I expect that a lot of programmers won't be using SB because >>it always has limitations. Either with complex layouts or custom >>controls. "Real" programmers probably use FXML directly or even just >>code it in Java. So the "return on investment" probably is fairly low >>and thus the resources can be much better spent on the core. IMHO. >> >> >>> On 5-3-2015 02:34, Mike Hearn wrote: >>> I agree that SB is probably something that can be well maintained by >>>the >>> community at this point, especially with commercial backing from Gluon >> NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From lehmann at media-interactive.de Thu Mar 5 15:55:33 2015 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 5 Mar 2015 16:55:33 +0100 Subject: QML vs. FXML In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> Message-ID: <54F87C75.4060308@media-interactive.de> Like this? http://wiki.eclipse.org/Efxclipse/Tooling/FXGraph On 05.03.2015 16:23, Doug Schaefer wrote: > You really want to use a domain specific language that?s easy to read > and write. QML is that. I find XML tags overwhelm the rest of the > text making it hard to understand what?s going on, and hard to write > unless you have a good XML editor. QML has less cruft and it?s > easier to see what?s happening with a quick glance. From ngalarneau at ABINITIO.COM Thu Mar 5 15:59:10 2015 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Thu, 5 Mar 2015 10:59:10 -0500 Subject: QML vs. FXML In-Reply-To: <54F87C75.4060308@media-interactive.de> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> Message-ID: Or GroovyFX From: Werner Lehmann To: openjfx-dev at openjdk.java.net, Date: 03/05/2015 10:56 AM Subject: Re: QML vs. FXML Sent by: "openjfx-dev" Like this? http://wiki.eclipse.org/Efxclipse/Tooling/FXGraph On 05.03.2015 16:23, Doug Schaefer wrote: > You really want to use a domain specific language that?s easy to read > and write. QML is that. I find XML tags overwhelm the rest of the > text making it hard to understand what?s going on, and hard to write > unless you have a good XML editor. QML has less cruft and it?s > easier to see what?s happening with a quick glance. NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From dschaefer at qnx.com Thu Mar 5 16:03:19 2015 From: dschaefer at qnx.com (Doug Schaefer) Date: Thu, 5 Mar 2015 16:03:19 +0000 Subject: QML vs. FXML In-Reply-To: <54F87C75.4060308@media-interactive.de> References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> <54F87C75.4060308@media-interactive.de> Message-ID: Yes :). Tom has dome some great work supporting JavaFX in the community. Now, I think you still need to compile FXGraph to something. The important requirement for declarative UI is the quick edit/reload cycle. Having the ?compiler? in the run-time would be needed for that, which is what QML, and FXML for that matter, offer. On 2015-03-05, 10:55 AM, "Werner Lehmann" wrote: >Like this? > >http://wiki.eclipse.org/Efxclipse/Tooling/FXGraph > >On 05.03.2015 16:23, Doug Schaefer wrote: >> You really want to use a domain specific language that?s easy to read >> and write. QML is that. I find XML tags overwhelm the rest of the >> text making it hard to understand what?s going on, and hard to write >> unless you have a good XML editor. QML has less cruft and it?s >> easier to see what?s happening with a quick glance. > From tomas.mikula at gmail.com Thu Mar 5 16:11:52 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Thu, 5 Mar 2015 11:11:52 -0500 Subject: 8u40 is released / SB In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> Message-ID: And then there are GroovyFX and ScalaFX, which embed the declarative UI language in the host language. To me, FXML seems to be just compensation for the lack of expressiveness in Java. Tomas On Thu, Mar 5, 2015 at 9:58 AM, Doug Schaefer wrote: > GUI builders are great for prototyping or helping you learn. But when the > application gets complex I keep hearing developers throw them out. They > start getting in the way. > > I think if you have a good API and a good declarative UI language, think > QML not FXML, then you may find you don?t really need a GUI builder. How > may people are using GUI builders to create Web app UI?s? Now web UIs are > simpler, but maybe that?s the point. > > And why not leave GUI builders to the tools vendors. They?re hard to make > and get right, especially of you don?t have a revenue model to support the > army of developers you need. > > Doug. > > Hmm, I wonder what React Native would look like with JavaFX and Nashorn? > > On 2015-03-05, 7:20 AM, "Scott Palmer" wrote: > >>I would never consider for a second coding FXML "directly". I have only >>tweaked it by hand occasionally after creating it with SceneBuilder. SB >>is an important selling point for JavaFX and should be included in the >>JDK, it shouldn't even be a separate download. >> >>Scott >> >>> On Mar 5, 2015, at 3:19 AM, Tom Eugelink wrote: >>> >>> My two cents would be that maintaining a UI builder is an awful lot of >>>work, while I expect that a lot of programmers won't be using SB because >>>it always has limitations. Either with complex layouts or custom >>>controls. "Real" programmers probably use FXML directly or even just >>>code it in Java. So the "return on investment" probably is fairly low >>>and thus the resources can be much better spent on the core. IMHO. >>> >>> >>>> On 5-3-2015 02:34, Mike Hearn wrote: >>>> I agree that SB is probably something that can be well maintained by >>>>the >>>> community at this point, especially with commercial backing from Gluon >>> > From hastebrot at gmail.com Thu Mar 5 16:15:36 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Thu, 5 Mar 2015 17:15:36 +0100 Subject: QML vs. FXML In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> Message-ID: >Now, having said that, HTML seems to be pretty popular? Some folks found even HTML too cumbersome to write and edit, and built transpilers [1], [2], [3], [4]. They look a bit like QML. [1] http://jade-lang.com/ [2] http://emblemjs.com/ [3] http://haml.info/ [4] http://slim-lang.com/ --Benjamin From herve.girod at gmail.com Thu Mar 5 18:00:24 2015 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Thu, 5 Mar 2015 19:00:24 +0100 Subject: QML vs. FXML In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> Message-ID: I don't find QML files easier to read than FXML. People are just used to them. They are also used to the fact that there are no good QML graphical editors, so they modify QML by hand. Sent from my iPhone > On Mar 5, 2015, at 16:23, Doug Schaefer wrote: > > In general, it?s an argument against writing code in XML. XML was really meant to be a machine to machine language, to make things like SceneBuilder easier to write :). People came second. > > You really want to use a domain specific language that?s easy to read and write. QML is that. I find XML tags overwhelm the rest of the text making it hard to understand what?s going on, and hard to write unless you have a good XML editor. QML has less cruft and it?s easier to see what?s happening with a quick glance. > > Now, having said that, HTML seems to be pretty popular? > > Doug. > > From: "ngalarneau at ABINITIO.COM" > > Date: Thursday, March 5, 2015 at 10:08 AM > To: Doug Schaefer > > Cc: "openjfx-dev at openjdk.java.net" > > Subject: QML vs. FXML > > Doug, > > You said: "good declarative UI language, think QML not FXML". > > What do you see as the advantages of QML over FXML? > > > Neil > > > > > From: Doug Schaefer > > To: "openjfx-dev at openjdk.java.net" >, > Date: 03/05/2015 10:00 AM > Subject: Re: 8u40 is released / SB > Sent by: "openjfx-dev" > > ________________________________ > > > > GUI builders are great for prototyping or helping you learn. But when the > application gets complex I keep hearing developers throw them out. They > start getting in the way. > > I think if you have a good API and a good declarative UI language, think > QML not FXML, then you may find you don?t really need a GUI builder. How > may people are using GUI builders to create Web app UI?s? Now web UIs are > simpler, but maybe that?s the point. > > And why not leave GUI builders to the tools vendors. They?re hard to make > and get right, especially of you don?t have a revenue model to support the > army of developers you need. > > Doug. > > Hmm, I wonder what React Native would look like with JavaFX and Nashorn? > >> On 2015-03-05, 7:20 AM, "Scott Palmer" > wrote: >> >> I would never consider for a second coding FXML "directly". I have only >> tweaked it by hand occasionally after creating it with SceneBuilder. SB >> is an important selling point for JavaFX and should be included in the >> JDK, it shouldn't even be a separate download. >> >> Scott >> >>> On Mar 5, 2015, at 3:19 AM, Tom Eugelink > wrote: >>> >>> My two cents would be that maintaining a UI builder is an awful lot of >>> work, while I expect that a lot of programmers won't be using SB because >>> it always has limitations. Either with complex layouts or custom >>> controls. "Real" programmers probably use FXML directly or even just >>> code it in Java. So the "return on investment" probably is fairly low >>> and thus the resources can be much better spent on the core. IMHO. >>> >>> >>>> On 5-3-2015 02:34, Mike Hearn wrote: >>>> I agree that SB is probably something that can be well maintained by >>>> the >>>> community at this point, especially with commercial backing from Gluon > > > > > > NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From tom.schindl at bestsolution.at Thu Mar 5 18:33:16 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 05 Mar 2015 19:33:16 +0100 Subject: QML vs. FXML In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> <54F87C75.4060308@media-interactive.de> Message-ID: <54F8A16C.8070604@bestsolution.at> Hi, First of all by default FXGraph "compiles" to FXML, that's also the reason why we currently don't allow you to write event-handlers inside the FXGraph file (from a technical point of view there's no reason why we should not be able to do that) but that would render us incompatible with FXML. What do we have: * FXGraph => FXML transition * FXML => FXGraph transition * FXML => Java transition (you can run that as part of the build) * LivePreview inside IDE while defining FXGraph / FXML - maybe this is the fast turn around stuff Doug talks about?) * A specialized FXMLLoader who first checks if the FXML file has not been compiled to Java code already as part of the build process otherwise it will load the FXML file using the default loader (or this is the fast turn around Doug talked about?) FXML => Java translator: Main reason for that is speed on constrainted devices - allowing you to run on profile1 instead of profile2 because of the need for an XML parser - no reflection overhead I guess RoboVM or ART would also welcome bytecode they can translate to native code instead of providing the full reflection stuff. As of today the tooling works only on Eclipse but because Xtext is coming to IntelliJ IDEA we'll soon maybe also support that IDE. The FXML => Java compiler is plain java code, we currently ship an ant-task but it should be trivial to provide maven support, not sure about gradle but someone who knows that platform should be able to call out to our APIs. Tom On 05.03.15 17:03, Doug Schaefer wrote: > Yes :). Tom has dome some great work supporting JavaFX in the community. > > Now, I think you still need to compile FXGraph to something. The important > requirement for declarative UI is the quick edit/reload cycle. Having the > ?compiler? in the run-time would be needed for that, which is what QML, > and FXML for that matter, offer. > > On 2015-03-05, 10:55 AM, "Werner Lehmann" > wrote: > >> Like this? >> >> http://wiki.eclipse.org/Efxclipse/Tooling/FXGraph >> >> On 05.03.2015 16:23, Doug Schaefer wrote: >>> You really want to use a domain specific language that?s easy to read >>> and write. QML is that. I find XML tags overwhelm the rest of the >>> text making it hard to understand what?s going on, and hard to write >>> unless you have a good XML editor. QML has less cruft and it?s >>> easier to see what?s happening with a quick glance. >> > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From mike at plan99.net Thu Mar 5 19:49:18 2015 From: mike at plan99.net (Mike Hearn) Date: Thu, 5 Mar 2015 11:49:18 -0800 Subject: 8u40 is released / SB In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> Message-ID: > > And then there are GroovyFX and ScalaFX, which embed the declarative > UI language in the host language. To me, FXML seems to be just > compensation for the lack of expressiveness in Java. I think the main benefit of FXML is that Scene Builder and programmers can both work with it directly, regardless of which programming language the host app is written in. If there was no FXML and just things like ScalaFX, a visual UI builder would be a hopeless proposition. And I do believe SB is a valuable tool for several reasons: 1. It's still much easier to get a layout looking exactly how you want with a visual designer. Even though JFX layout is more intuitive than most layout mechanisms I've used, it's still faster to do things visually. 2. For newbies to the framework i.e. almost everyone, a visual designer helps you explore the capabilities of the framework and is much easier to learn with than raw FXML + autocomplete. Of course once you master the framework this doesn't apply any more, but is still very important to start with. 3. For apps that have a split between the programmers and the visual designers, a tool is critical. 4. If/when SB eventually gets support for animations, that's another thing that's just a lot easier to do visually. That said, I'd love it if SB could have "Export to Java", "Export to ScalaFX" etc options too, if only because loading FXML seems to be kind of slow. From dschaefer at qnx.com Thu Mar 5 19:55:57 2015 From: dschaefer at qnx.com (Doug Schaefer) Date: Thu, 5 Mar 2015 19:55:57 +0000 Subject: 8u40 is released / SB In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> <54F787AD.2090303@oracle.com> <54F81198.9090704@tbee.org> <5196BC06-49B3-4B6D-A057-F188D7A89E15@gmail.com> Message-ID: From: Mike Hearn > Date: Thursday, March 5, 2015 at 2:49 PM To: Tomas Mikula > Cc: Doug Schaefer >, "openjfx-dev at openjdk.java.net" > Subject: Re: 8u40 is released / SB And then there are GroovyFX and ScalaFX, which embed the declarative UI language in the host language. To me, FXML seems to be just compensation for the lack of expressiveness in Java. I think the main benefit of FXML is that Scene Builder and programmers can both work with it directly, regardless of which programming language the host app is written in. If there was no FXML and just things like ScalaFX, a visual UI builder would be a hopeless proposition. I don?t disagree with that. FXML does fill that need well. But a program?s usability requirements is different from a person. As Benjamin mentioned, even HTML has more user friendly languages, like Jade which I?ve used in the past, that translate down to it so that humans have a better time. And I do believe SB is a valuable tool for several reasons: 1. It's still much easier to get a layout looking exactly how you want with a visual designer. Even though JFX layout is more intuitive than most layout mechanisms I've used, it's still faster to do things visually. 2. For newbies to the framework i.e. almost everyone, a visual designer helps you explore the capabilities of the framework and is much easier to learn with than raw FXML + autocomplete. Of course once you master the framework this doesn't apply any more, but is still very important to start with. 3. For apps that have a split between the programmers and the visual designers, a tool is critical. 4. If/when SB eventually gets support for animations, that's another thing that's just a lot easier to do visually. And that?s really crux of the matter. The complaint I hear about GUI building tools is that they don?t help with dynamic interfaces. A lot of GUI builders are stuck in the If/when phase for that. But is that which makes GUI frameworks like JavaFX so exciting. That said, I'd love it if SB could have "Export to Java", "Export to ScalaFX" etc options too, if only because loading FXML seems to be kind of slow. From vadim.pakhnushev at oracle.com Fri Mar 6 14:30:18 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 06 Mar 2015 17:30:18 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <54F9B9FA.9060504@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From leif.samuelsson at oracle.com Fri Mar 6 17:11:23 2015 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Fri, 06 Mar 2015 09:11:23 -0800 Subject: [8u] Review request: RT-39642: Selection on double click selects too much on Windows Message-ID: <54F9DFBB.1070605@oracle.com> Hi Jonathan, Please review this fix for TextInputControl on Windows. A simple patch is attached in JIRA. https://javafx-jira.kenai.com/browse/RT-39642 Thanks, Leif From morris.meyer at oracle.com Fri Mar 6 20:51:26 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Fri, 06 Mar 2015 15:51:26 -0500 Subject: [8u-dev] Review request: RT-2298: Mac: implement -Xdock:name support in Glass Message-ID: <54FA134E.5000306@oracle.com> Kevin, David, Danno and Chien, Please review these changes to add Mac system menu bar naming support to JavaFX based on the JavaRuntimeSupport foundation that the JDK uses for -Xdock:name via JRSAppkitAWT methods. On the Mac the application name needs to be available prior to the runLoop being viable. I have made modifications to PlatformImpl to differentiate between application class and startup application name to provide a route to pass this information into the toolkit startup() sequence a priori. The rest of the changes provide named startup. The nice part about this change is that we get an immediate system menu activation with the application name prior to any Stages getting loaded, laid-out and shown, which gives the user an immediate notification of the application launch. Thanks, --morris JIRA - https://javafx-jira.kenai.com/browse/RT-22988 WEBREV - http://cr.openjdk.java.net/~morris/RT-22988.01 WEBREV - http://cr.openjdk.java.net/~morris/DEPLOY-22988.01 From cnewland at chrisnewland.com Mon Mar 9 08:11:50 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Mon, 9 Mar 2015 08:11:50 -0000 Subject: DemoFX - JavaFX examples / benchmarking framework Message-ID: Hi all, I've put together a little framework called DemoFX and a few "demoscene" graphical effects for measuring JavaFX performance: https://github.com/chriswhocodes/DemoFX Here's a YouTube video of some of the effects I've developed: https://www.youtube.com/watch?v=N1rihYA8c2M (watch in HD if you can) There's an abstract base class that takes care of the setup and measures frame rate and time spent in the render() method so developing new effects is quite easy. I plan to add some text-based effects and also some 3D stuff. It's all Canvas based and the effects are rendered with calls to GraphicsContext. It seems to run at 60fps on modern hardware with the ES2Pipeline (once it's run enough loops for the JIT compilers to do their thing). I think I've already found one JavaFX performance problem: GraphicsContext's strokePolygon(pointsX, pointsY, count) has about half the performance of the equivalent set of strokeLine(x1, y1, x2, y2) commands. Example (after building DemoFX with ant) ./run.sh -m line vs ./run.sh -m poly Will do a full write-up later. Cheers, Chris @chriswhocodes From hastebrot at gmail.com Mon Mar 9 08:36:39 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Mon, 9 Mar 2015 09:36:39 +0100 Subject: DemoFX - JavaFX examples / benchmarking framework In-Reply-To: References: Message-ID: Hi Chris, that's amazing. Would it be possible in the future to allow both Canvas and Shapes (in a Scene graph)? --Benjamin On Mon, Mar 9, 2015 at 9:11 AM, Chris Newland wrote: > Hi all, > > I've put together a little framework called DemoFX and a few "demoscene" > graphical effects for measuring JavaFX performance: > > https://github.com/chriswhocodes/DemoFX > > Here's a YouTube video of some of the effects I've developed: > > https://www.youtube.com/watch?v=N1rihYA8c2M (watch in HD if you can) > > There's an abstract base class that takes care of the setup and measures > frame rate and time spent in the render() method so developing new effects > is quite easy. I plan to add some text-based effects and also some 3D > stuff. > > It's all Canvas based and the effects are rendered with calls to > GraphicsContext. It seems to run at 60fps on modern hardware with the > ES2Pipeline (once it's run enough loops for the JIT compilers to do their > thing). > > I think I've already found one JavaFX performance problem: > > GraphicsContext's strokePolygon(pointsX, pointsY, count) has about half > the performance of the equivalent set of strokeLine(x1, y1, x2, y2) > commands. > > Example (after building DemoFX with ant) > > ./run.sh -m line > vs > ./run.sh -m poly > > Will do a full write-up later. > > Cheers, > > Chris > @chriswhocodes > > From cnewland at chrisnewland.com Mon Mar 9 09:00:51 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Mon, 9 Mar 2015 09:00:51 -0000 Subject: Build farm for OpenJFX (on ARM) In-Reply-To: References: <6BA3EA13-80EF-475E-BD23-5BA095A2A995@oracle.com> Message-ID: <325f075db2878656a57d2f6964249aec.squirrel@excalibur.xssl.net> Hi all, A quick update on this: There are a small number of wrinkles before we get OpenJFX building on the Adoption group's CloudBees system so I've put together a Debian-based VPS server that is producing nightly OpenJFX builds for Linux amd64 and armv6hf. It updates from http://hg.openjdk.java.net/openjfx/8u-dev/rt and pulls the latest crosslibs dependencies before building so it's the bleeding edge of the OpenJFX codebase. The build log shows failing tests for LinuxDebBundlerTest which I need to fix but working binaries are still produced. http://108.61.191.178/ No domain name yet as this is just a temporary home. Oracle - please shout if there are any license issues with me doing this? Cheers, Chris From cnewland at chrisnewland.com Mon Mar 9 09:12:02 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Mon, 9 Mar 2015 09:12:02 -0000 Subject: DemoFX - JavaFX examples / benchmarking framework In-Reply-To: References: Message-ID: Hi Benjamin, Thanks :) I'll definitely be looking at scene graph when I do some 3D effects. Cheers, Chris @chriswhocodes On Mon, March 9, 2015 08:36, Benjamin Gudehus wrote: > Hi Chris, > > > that's amazing. Would it be possible in the future to allow both Canvas > and Shapes (in a Scene graph)? > > > --Benjamin > > > > On Mon, Mar 9, 2015 at 9:11 AM, Chris Newland > wrote: > > >> Hi all, >> >> >> I've put together a little framework called DemoFX and a few >> "demoscene" >> graphical effects for measuring JavaFX performance: >> >> https://github.com/chriswhocodes/DemoFX >> >> >> Here's a YouTube video of some of the effects I've developed: >> >> >> https://www.youtube.com/watch?v=N1rihYA8c2M (watch in HD if you can) >> >> >> There's an abstract base class that takes care of the setup and >> measures frame rate and time spent in the render() method so developing >> new effects is quite easy. I plan to add some text-based effects and >> also some 3D stuff. >> >> It's all Canvas based and the effects are rendered with calls to >> GraphicsContext. It seems to run at 60fps on modern hardware with the >> ES2Pipeline (once it's run enough loops for the JIT compilers to do >> their thing). >> >> I think I've already found one JavaFX performance problem: >> >> >> GraphicsContext's strokePolygon(pointsX, pointsY, count) has about half >> the performance of the equivalent set of strokeLine(x1, y1, x2, y2) >> commands. >> >> Example (after building DemoFX with ant) >> >> >> ./run.sh -m line >> vs ./run.sh -m poly >> >> >> Will do a full write-up later. >> >> >> Cheers, >> >> >> Chris >> @chriswhocodes >> >> >> > From martijnverburg at gmail.com Mon Mar 9 09:41:35 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 9 Mar 2015 09:41:35 +0000 Subject: Build farm for OpenJFX (on ARM) In-Reply-To: <325f075db2878656a57d2f6964249aec.squirrel@excalibur.xssl.net> References: <6BA3EA13-80EF-475E-BD23-5BA095A2A995@oracle.com> <325f075db2878656a57d2f6964249aec.squirrel@excalibur.xssl.net> Message-ID: Hi Chris, Just to add to this, have you got an account to edit the wiki at adoptopenjdk.java.net? We should add a link to this build from there. Cheers, Martijn On 9 March 2015 at 09:00, Chris Newland wrote: > Hi all, > > A quick update on this: > > There are a small number of wrinkles before we get OpenJFX building on the > Adoption group's CloudBees system so I've put together a Debian-based VPS > server that is producing nightly OpenJFX builds for Linux amd64 and > armv6hf. > > It updates from http://hg.openjdk.java.net/openjfx/8u-dev/rt and pulls the > latest crosslibs dependencies before building so it's the bleeding edge of > the OpenJFX codebase. > > The build log shows failing tests for LinuxDebBundlerTest which I need to > fix but working binaries are still produced. > > http://108.61.191.178/ > > No domain name yet as this is just a temporary home. > > Oracle - please shout if there are any license issues with me doing this? > > Cheers, > > Chris > > From neugens.limasoftware at gmail.com Mon Mar 9 11:47:27 2015 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 9 Mar 2015 12:47:27 +0100 Subject: DemoFX - JavaFX examples / benchmarking framework In-Reply-To: References: Message-ID: It gave me a big headache, but it's so cool looking at it that I could not stop! :) Thanks for bringing back memories ;) Cheers, Mario 2015-03-09 9:36 GMT+01:00 Benjamin Gudehus : > Hi Chris, > > that's amazing. Would it be possible in the future to allow both Canvas and > Shapes (in a Scene graph)? > > --Benjamin > > > On Mon, Mar 9, 2015 at 9:11 AM, Chris Newland > wrote: > >> Hi all, >> >> I've put together a little framework called DemoFX and a few "demoscene" >> graphical effects for measuring JavaFX performance: >> >> https://github.com/chriswhocodes/DemoFX >> >> Here's a YouTube video of some of the effects I've developed: >> >> https://www.youtube.com/watch?v=N1rihYA8c2M (watch in HD if you can) >> >> There's an abstract base class that takes care of the setup and measures >> frame rate and time spent in the render() method so developing new effects >> is quite easy. I plan to add some text-based effects and also some 3D >> stuff. >> >> It's all Canvas based and the effects are rendered with calls to >> GraphicsContext. It seems to run at 60fps on modern hardware with the >> ES2Pipeline (once it's run enough loops for the JIT compilers to do their >> thing). >> >> I think I've already found one JavaFX performance problem: >> >> GraphicsContext's strokePolygon(pointsX, pointsY, count) has about half >> the performance of the equivalent set of strokeLine(x1, y1, x2, y2) >> commands. >> >> Example (after building DemoFX with ant) >> >> ./run.sh -m line >> vs >> ./run.sh -m poly >> >> Will do a full write-up later. >> >> Cheers, >> >> Chris >> @chriswhocodes >> >> -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From cnewland at chrisnewland.com Mon Mar 9 12:05:50 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Mon, 9 Mar 2015 12:05:50 -0000 Subject: Build farm for OpenJFX (on ARM) In-Reply-To: References: <6BA3EA13-80EF-475E-BD23-5BA095A2A995@oracle.com> <325f075db2878656a57d2f6964249aec.squirrel@excalibur.xssl.net> Message-ID: <1bab1d83297156ed60b45021c5dfd6fc.squirrel@excalibur.xssl.net> Hi Martijn, I have "Role: Observer" for Adopt OpenJDK and I don't see any edit buttons so guess I'm not permitted ;) There's already a very good wiki for OpenJFX here https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX so maybe Adopt should link to that? Mani's been chipping away at the hurdles to get OpenJFX working on the Adopt CloudBees but we're stuck on a darned Fedora/freetype dependency at the moment so I've put this personal VPS together as a stop gap. I've pushed a little JavaFX benchmark framework to do some performance measurements https://github.com/chriswhocodes/DemoFX and have found one possible perf bug for which I'll submit a patch if confirmed. Hopefully this little framework will lower the bar for people to play with JavaFX as you just need to implement a single render() method. Maybe I could do a JavaFX demoscene hacking tutorial at the next Hack-the-Tower meetup? Cheers, Chris On Mon, March 9, 2015 09:41, Martijn Verburg wrote: > Hi Chris, > > > Just to add to this, have you got an account to edit the wiki at > adoptopenjdk.java.net? We should add a link to this build from there. > > Cheers, > Martijn > > > On 9 March 2015 at 09:00, Chris Newland > wrote: > > >> Hi all, >> >> >> A quick update on this: >> >> >> There are a small number of wrinkles before we get OpenJFX building on >> the Adoption group's CloudBees system so I've put together a >> Debian-based VPS >> server that is producing nightly OpenJFX builds for Linux amd64 and >> armv6hf. >> >> It updates from http://hg.openjdk.java.net/openjfx/8u-dev/rt and pulls >> the latest crosslibs dependencies before building so it's the bleeding >> edge of the OpenJFX codebase. >> >> The build log shows failing tests for LinuxDebBundlerTest which I need >> to fix but working binaries are still produced. >> >> http://108.61.191.178/ >> >> >> No domain name yet as this is just a temporary home. >> >> >> Oracle - please shout if there are any license issues with me doing >> this? >> >> Cheers, >> >> >> Chris >> >> >> > From krueger at lesspain.de Mon Mar 9 16:31:04 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Mon, 9 Mar 2015 17:31:04 +0100 Subject: Media player maturity (on Mac) Message-ID: Hi, anyone doing serious work with the media player on the Mac? I am experimenting and so far I am not getting the impression, this is really something very solid. The first Audio-Sample I tried playing plays fine the first time but when I play it for a second time by either issuing stop() followed by play() or seek(new Duration(0) and then play, the playback cuts off a few samples at the start (does not happen when I instantiate a new Player for each time I want to play it, which does not feel right). You need a suitable audio file like a drum beat that starts immediately in the file to notice the difference. If one was to implement simple sample-player-like functionality (not a full fledged music sequencer but something that allows timed playback to arrange sounds on a timeline a bit) in JavaFX, should Mediaplayer be the tool to use or do I have to use native APIs? Last time I checked JavaSound, it was still an abandoned toy usable only for educational purposes but not for anything else. Don't know if that has changed or if this is even the Audio strategy for JFX. Would be great if someone could share experience/opinions in this area. Thanks in advance, Robert From joe.mcglynn at oracle.com Mon Mar 9 17:01:14 2015 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Mon, 9 Mar 2015 10:01:14 -0700 Subject: Media player maturity (on Mac) In-Reply-To: References: Message-ID: The FX/Media stack is supported, and the media stack on Mac was *just* updated in 8u40 to use the newer AVFoundation stack (10.8+ only) instead of QtKit. It?s certainly possible there are bugs, please file a bug report with a reproducer case so we can fix them. > On Mar 9, 2015, at 9:31 AM, Robert Kr?ger wrote: > > Hi, > > anyone doing serious work with the media player on the Mac? I am > experimenting and so far I am not getting the impression, this is really > something very solid. > > The first Audio-Sample I tried playing plays fine the first time but when I > play it for a second time by either issuing stop() followed by play() or > seek(new Duration(0) and then play, the playback cuts off a few samples at > the start (does not happen when I instantiate a new Player for each time I > want to play it, which does not feel right). You need a suitable audio file > like a drum beat that starts immediately in the file to notice the > difference. > > If one was to implement simple sample-player-like functionality (not a full > fledged music sequencer but something that allows timed playback to arrange > sounds on a timeline a bit) in JavaFX, should Mediaplayer be the tool to > use or do I have to use native APIs? Last time I checked JavaSound, it was > still an abandoned toy usable only for educational purposes but not for > anything else. Don't know if that has changed or if this is even the Audio > strategy for JFX. > > Would be great if someone could share experience/opinions in this area. > > Thanks in advance, > > Robert From kevin.rushforth at oracle.com Mon Mar 9 20:07:38 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 09 Mar 2015 13:07:38 -0700 Subject: 8u-dev unlocked following this week's sanity testing Message-ID: <54FDFD8A.9040800@oracle.com> From peter.penzov at gmail.com Mon Mar 9 21:18:22 2015 From: peter.penzov at gmail.com (Peter Penzov) Date: Mon, 9 Mar 2015 23:18:22 +0200 Subject: Multiple parallel tasks in a single service Message-ID: Hi All, I'm interested how I can create 10 Tasks in one Scheduled Service? private final DataService service = new DataService(); class DataService extends ScheduledService { @Override protected Task createTask() { return new Task() { @Override protected Void call() throws Exception { // Several tasks return null; } }; } } In my case I have 10 charts which I want to update with one Scheduled Service. So maybe the best solution will be to run the Scheduled Service with 10 Tasks and update the Charts. Is there any way to do this? BR, Peter From David.Hill at Oracle.com Mon Mar 9 22:00:36 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 09 Mar 2015 18:00:36 -0400 Subject: Review on minor change to openZip Message-ID: <54FE1804.90708@Oracle.com> Kevin, jira: https://javafx-jira.kenai.com/browse/RT-40227 The change is in the description. openZip is a gradle task that produces a "clean" JFX bundle suitable for framing or overlaying on top of a JDK. Dave -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From krueger at lesspain.de Mon Mar 9 22:49:59 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Mon, 9 Mar 2015 23:49:59 +0100 Subject: Media player maturity (on Mac) In-Reply-To: References: Message-ID: Doesn't seem to make a difference if I use u25 or u40. I can't get any sound file to loop using setCycleCount(INDEFINITE) on u25 or u40 either. I will probably submit bug reports for this later. On Mon, Mar 9, 2015 at 6:01 PM, Joe McGlynn wrote: > The FX/Media stack is supported, and the media stack on Mac was *just* > updated in 8u40 to use the newer AVFoundation stack (10.8+ only) instead of > QtKit. It?s certainly possible there are bugs, please file a bug report > with a reproducer case so we can fix them. > > > > > > On Mar 9, 2015, at 9:31 AM, Robert Kr?ger wrote: > > Hi, > > anyone doing serious work with the media player on the Mac? I am > experimenting and so far I am not getting the impression, this is really > something very solid. > > The first Audio-Sample I tried playing plays fine the first time but when I > play it for a second time by either issuing stop() followed by play() or > seek(new Duration(0) and then play, the playback cuts off a few samples at > the start (does not happen when I instantiate a new Player for each time I > want to play it, which does not feel right). You need a suitable audio file > like a drum beat that starts immediately in the file to notice the > difference. > > If one was to implement simple sample-player-like functionality (not a full > fledged music sequencer but something that allows timed playback to arrange > sounds on a timeline a bit) in JavaFX, should Mediaplayer be the tool to > use or do I have to use native APIs? Last time I checked JavaSound, it was > still an abandoned toy usable only for educational purposes but not for > anything else. Don't know if that has changed or if this is even the Audio > strategy for JFX. > > Would be great if someone could share experience/opinions in this area. > > Thanks in advance, > > Robert > > > -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From swpalmer at gmail.com Tue Mar 10 00:44:15 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 9 Mar 2015 20:44:15 -0400 Subject: Media player maturity (on Mac) In-Reply-To: References: Message-ID: <5E0E3A8C-A9ED-4F0E-8BB7-76895B94DA68@gmail.com> As you have discovered, the JavaFX media support isn't quite where it needs to be. That said, the JavaFX team is putting in the effort to make JavaFX better with every release. Please do file that bug report! (This kind of issue is sure to get addressed faster than my request to make the media system extensible RT-2684) Scott > On Mar 9, 2015, at 6:49 PM, Robert Kr?ger wrote: > > Doesn't seem to make a difference if I use u25 or u40. > > I can't get any sound file to loop using setCycleCount(INDEFINITE) on u25 > or u40 either. > > I will probably submit bug reports for this later. > > >> On Mon, Mar 9, 2015 at 6:01 PM, Joe McGlynn wrote: >> >> The FX/Media stack is supported, and the media stack on Mac was *just* >> updated in 8u40 to use the newer AVFoundation stack (10.8+ only) instead of >> QtKit. It?s certainly possible there are bugs, please file a bug report >> with a reproducer case so we can fix them. >> >> >> >> >> >> On Mar 9, 2015, at 9:31 AM, Robert Kr?ger wrote: >> >> Hi, >> >> anyone doing serious work with the media player on the Mac? I am >> experimenting and so far I am not getting the impression, this is really >> something very solid. >> >> The first Audio-Sample I tried playing plays fine the first time but when I >> play it for a second time by either issuing stop() followed by play() or >> seek(new Duration(0) and then play, the playback cuts off a few samples at >> the start (does not happen when I instantiate a new Player for each time I >> want to play it, which does not feel right). You need a suitable audio file >> like a drum beat that starts immediately in the file to notice the >> difference. >> >> If one was to implement simple sample-player-like functionality (not a full >> fledged music sequencer but something that allows timed playback to arrange >> sounds on a timeline a bit) in JavaFX, should Mediaplayer be the tool to >> use or do I have to use native APIs? Last time I checked JavaSound, it was >> still an abandoned toy usable only for educational purposes but not for >> anything else. Don't know if that has changed or if this is even the Audio >> strategy for JFX. >> >> Would be great if someone could share experience/opinions in this area. >> >> Thanks in advance, >> >> Robert > > > -- > Robert Kr?ger > Managing Partner > Lesspain GmbH & Co. KG > > www.lesspain-software.com From david.dehaven at oracle.com Wed Mar 11 01:51:28 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 10 Mar 2015 18:51:28 -0700 Subject: Media player maturity (on Mac) In-Reply-To: References: Message-ID: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> > anyone doing serious work with the media player on the Mac? I am > experimenting and so far I am not getting the impression, this is really > something very solid. > > The first Audio-Sample I tried playing plays fine the first time but when I > play it for a second time by either issuing stop() followed by play() or > seek(new Duration(0) and then play, the playback cuts off a few samples at > the start (does not happen when I instantiate a new Player for each time I > want to play it, which does not feel right). You need a suitable audio file > like a drum beat that starts immediately in the file to notice the > difference. > > If one was to implement simple sample-player-like functionality (not a full > fledged music sequencer but something that allows timed playback to arrange > sounds on a timeline a bit) in JavaFX, should Mediaplayer be the tool to > use or do I have to use native APIs? Last time I checked JavaSound, it was > still an abandoned toy usable only for educational purposes but not for > anything else. Don't know if that has changed or if this is even the Audio > strategy for JFX. > > Would be great if someone could share experience/opinions in this area. Have you tried AudioClip instead of MediaPlayer? -DrD- From krueger at lesspain.de Wed Mar 11 10:42:27 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Wed, 11 Mar 2015 11:42:27 +0100 Subject: Media player maturity (on Mac) In-Reply-To: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> References: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> Message-ID: No, thanks for the hint. I just did and the behavior is a bit better in the sense that the sample start is not cut off on subsequent play invocations (behaves more or less line instantiating a new mediaplayer for each invocation, which is good) but when I loop using setCycleCount the sample start is also not clean (seams to be varying, though). For my uses case I will probably need both MediaPlayer and Audioclip, because I have typical cases for AudioClip (e.g. short notification sounds) and long looping background samples. Wow, I just discovered, that the behavior with the sample start sounding different on the first invocation also happens when I play the sample using the player integrated in Finder, so I owe you a big apology. I am sorry! I can also no longer reproduce the looping failure after my last reboot :-S. Btw. the latency of AudioClip on the Mac (2012 MBP) is not quite low enough to implement something like a drum kit using the keyboard. I don't know if that is the benchmark you are after or if that is also a limitation of the hosting system. I need to test that with other applications. The latency I get with AudioClip is good enough for my current use case, though. @Joe: I am using 10.10.1, just realized I never answered that Best regards, Robert On Wed, Mar 11, 2015 at 2:51 AM, David DeHaven wrote: > > > anyone doing serious work with the media player on the Mac? I am > > experimenting and so far I am not getting the impression, this is really > > something very solid. > > > > The first Audio-Sample I tried playing plays fine the first time but > when I > > play it for a second time by either issuing stop() followed by play() or > > seek(new Duration(0) and then play, the playback cuts off a few samples > at > > the start (does not happen when I instantiate a new Player for each time > I > > want to play it, which does not feel right). You need a suitable audio > file > > like a drum beat that starts immediately in the file to notice the > > difference. > > > > If one was to implement simple sample-player-like functionality (not a > full > > fledged music sequencer but something that allows timed playback to > arrange > > sounds on a timeline a bit) in JavaFX, should Mediaplayer be the tool to > > use or do I have to use native APIs? Last time I checked JavaSound, it > was > > still an abandoned toy usable only for educational purposes but not for > > anything else. Don't know if that has changed or if this is even the > Audio > > strategy for JFX. > > > > Would be great if someone could share experience/opinions in this area. > > Have you tried AudioClip instead of MediaPlayer? > > -DrD- > > -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From swpalmer at gmail.com Wed Mar 11 11:08:43 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 11 Mar 2015 07:08:43 -0400 Subject: Media player maturity (on Mac) In-Reply-To: References: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> Message-ID: <70A1CFAC-5CCD-4E7D-A714-98F0DD1E8A49@gmail.com> Now that you mention this, I remember having a problem with JavaFX audio on my Mac - where I believe playback wasn't working at all, and that was also resolved with a reboot. That was some time ago, with an older version of FX and the OS for that matter. Scott > On Mar 11, 2015, at 6:42 AM, Robert Kr?ger wrote: > > I can also no longer reproduce the looping failure after my last reboot :-S. > From david.dehaven at oracle.com Wed Mar 11 16:28:02 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 11 Mar 2015 09:28:02 -0700 Subject: Media player maturity (on Mac) In-Reply-To: References: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> Message-ID: <97A90385-B65A-4DCF-AD2F-6463D2059CE7@oracle.com> > No, thanks for the hint. I just did and the behavior is a bit better in the sense that the sample start is not cut off on subsequent play invocations (behaves more or less line instantiating a new mediaplayer for each invocation, which is good) but when I loop using setCycleCount the sample start is also not clean (seams to be varying, though). > > For my uses case I will probably need both MediaPlayer and Audioclip, because I have typical cases for AudioClip (e.g. short notification sounds) and long looping background samples. > > Wow, I just discovered, that the behavior with the sample start sounding different on the first invocation also happens when I play the sample using the player integrated in Finder, so I owe you a big apology. I am sorry! I can also no longer reproduce the looping failure after my last reboot :-S. No worries, these things just aren?t supposed to behave that way ;) > Btw. the latency of AudioClip on the Mac (2012 MBP) is not quite low enough to implement something like a drum kit using the keyboard. I don't know if that is the benchmark you are after or if that is also a limitation of the hosting system. I need to test that with other applications. The latency I get with AudioClip is good enough for my current use case, though. Yeah, the current AudioClip implementation actually uses the same engine as MediaPlayer, just in a slightly different way. The biggest difference (aside from the one-shot interface) is it caches all the audio data in memory. If you use uncompressed audio (aiff) it will be a bit faster. -DrD- From David.Hill at Oracle.com Wed Mar 11 16:36:21 2015 From: David.Hill at Oracle.com (David Hill) Date: Wed, 11 Mar 2015 12:36:21 -0400 Subject: Build farm for OpenJFX (on ARM) In-Reply-To: <325f075db2878656a57d2f6964249aec.squirrel@excalibur.xssl.net> References: <6BA3EA13-80EF-475E-BD23-5BA095A2A995@oracle.com> <325f075db2878656a57d2f6964249aec.squirrel@excalibur.xssl.net> Message-ID: <55006F05.2010203@Oracle.com> On 3/9/15, 5:00 AM, Chris Newland wrote: > Hi all, > > A quick update on this: > > There are a small number of wrinkles before we get OpenJFX building on the > Adoption group's CloudBees system so I've put together a Debian-based VPS > server that is producing nightly OpenJFX builds for Linux amd64 and > armv6hf. > > It updates fromhttp://hg.openjdk.java.net/openjfx/8u-dev/rt and pulls the > latest crosslibs dependencies before building so it's the bleeding edge of > the OpenJFX codebase. Chris, I forgot to blast this out to the group: gradle openZip which is part of gradle zip -or- gradle all at least in the open builds. This target was added a month or so ago, and I just fixed something in in, that meant it was not showing up in openZip properly. This target builds a bundle in ./builds/[platform-]bundles/javafx-sdk-overlay.zip The contents include jfxrt.jar which has been filtered in a similar fashion to the JFX product, removing some stuff that is not appropriate to a given platform. (Yes that means Monocle on non-arm platforms). The logic is pretty straight forward - ie Windows classes don't show up on a non-windows platform. The resulting bundle *should* be able to be deployed by just unpacking it over a JDK, which is intended to simplify matters. Dave -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From krueger at lesspain.de Wed Mar 11 16:56:01 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Wed, 11 Mar 2015 17:56:01 +0100 Subject: Media player maturity (on Mac) In-Reply-To: <97A90385-B65A-4DCF-AD2F-6463D2059CE7@oracle.com> References: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> <97A90385-B65A-4DCF-AD2F-6463D2059CE7@oracle.com> Message-ID: On Wed, Mar 11, 2015 at 5:28 PM, David DeHaven wrote: > > > No, thanks for the hint. I just did and the behavior is a bit better in > the sense that the sample start is not cut off on subsequent play > invocations (behaves more or less line instantiating a new mediaplayer for > each invocation, which is good) but when I loop using setCycleCount the > sample start is also not clean (seams to be varying, though). > > > > For my uses case I will probably need both MediaPlayer and Audioclip, > because I have typical cases for AudioClip (e.g. short notification sounds) > and long looping background samples. > > > > Wow, I just discovered, that the behavior with the sample start sounding > different on the first invocation also happens when I play the sample using > the player integrated in Finder, so I owe you a big apology. I am sorry! I > can also no longer reproduce the looping failure after my last reboot :-S. > > No worries, these things just aren?t supposed to behave that way ;) > > > > Btw. the latency of AudioClip on the Mac (2012 MBP) is not quite low > enough to implement something like a drum kit using the keyboard. I don't > know if that is the benchmark you are after or if that is also a limitation > of the hosting system. I need to test that with other applications. The > latency I get with AudioClip is good enough for my current use case, though. > > Yeah, the current AudioClip implementation actually uses the same engine > as MediaPlayer, just in a slightly different way. The biggest difference > (aside from the one-shot interface) is it caches all the audio data in > memory. If you use uncompressed audio (aiff) it will be a bit faster. > > I already tested uncompressed (wav). From krueger at lesspain.de Thu Mar 12 16:46:33 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Thu, 12 Mar 2015 17:46:33 +0100 Subject: Media player maturity (on Mac) In-Reply-To: <97A90385-B65A-4DCF-AD2F-6463D2059CE7@oracle.com> References: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> <97A90385-B65A-4DCF-AD2F-6463D2059CE7@oracle.com> Message-ID: On Wed, Mar 11, 2015 at 5:28 PM, David DeHaven wrote: > > > No, thanks for the hint. I just did and the behavior is a bit better in > the sense that the sample start is not cut off on subsequent play > invocations (behaves more or less line instantiating a new mediaplayer for > each invocation, which is good) but when I loop using setCycleCount the > sample start is also not clean (seams to be varying, though). > > > > For my uses case I will probably need both MediaPlayer and Audioclip, > because I have typical cases for AudioClip (e.g. short notification sounds) > and long looping background samples. > > > > Wow, I just discovered, that the behavior with the sample start sounding > different on the first invocation also happens when I play the sample using > the player integrated in Finder, so I owe you a big apology. I am sorry! I > can also no longer reproduce the looping failure after my last reboot :-S. > > No worries, these things just aren?t supposed to behave that way ;) > > > > Btw. the latency of AudioClip on the Mac (2012 MBP) is not quite low > enough to implement something like a drum kit using the keyboard. I don't > know if that is the benchmark you are after or if that is also a limitation > of the hosting system. I need to test that with other applications. The > latency I get with AudioClip is good enough for my current use case, though. > > Yeah, the current AudioClip implementation actually uses the same engine > as MediaPlayer, just in a slightly different way. The biggest difference > (aside from the one-shot interface) is it caches all the audio data in > memory. If you use uncompressed audio (aiff) it will be a bit faster. > > -DrD- > > One more question regarding this. Is it OK to have many instances of AudioClip or MediaPlayer if only a few of them actually play stuff or do they block audio resources even when they are stopped? From david.dehaven at oracle.com Thu Mar 12 17:02:12 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 12 Mar 2015 10:02:12 -0700 Subject: Media player maturity (on Mac) In-Reply-To: References: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> <97A90385-B65A-4DCF-AD2F-6463D2059CE7@oracle.com> Message-ID: <27B8FEC2-831A-4DE4-A6BE-BDD802DC70E3@oracle.com> > One more question regarding this. Is it OK to have many instances of AudioClip or MediaPlayer if only a few of them actually play stuff or do they block audio resources even when they are stopped? You can have as many as memory will allow :) They don?t tie up hardware resources until actually playing. I actually recommend pre-loading AudioClips to avoid startup latency, especially if they?re fetched remotely. -DrD- From krueger at lesspain.de Thu Mar 12 18:57:44 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Thu, 12 Mar 2015 19:57:44 +0100 Subject: Media player maturity (on Mac) In-Reply-To: <27B8FEC2-831A-4DE4-A6BE-BDD802DC70E3@oracle.com> References: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> <97A90385-B65A-4DCF-AD2F-6463D2059CE7@oracle.com> <27B8FEC2-831A-4DE4-A6BE-BDD802DC70E3@oracle.com> Message-ID: On Thu, Mar 12, 2015 at 6:02 PM, David DeHaven wrote: > > > One more question regarding this. Is it OK to have many instances of > AudioClip or MediaPlayer if only a few of them actually play stuff or do > they block audio resources even when they are stopped? > > You can have as many as memory will allow :) They don?t tie up hardware > resources until actually playing. I actually recommend pre-loading > AudioClips to avoid startup latency, especially if they?re fetched remotely. > Thanks for the info! From krueger at lesspain.de Thu Mar 12 19:12:30 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Thu, 12 Mar 2015 20:12:30 +0100 Subject: MediaPlayer status changes Message-ID: Hi, I don't see anything in the docs stating how status should change in MediaPlayer, e.g. will reaching end of media trigger a transition from PLAYING to STOPPED? Will a subsequent call to play() start at the beginning of the media file or do I need to seek? I was expecting some kind of status change on end of media but am not seeing any when playing back an audio sample until the end and when I checked the api doc, I didn't find anything (e.g. like a state diagram) to check if it's a bug or documented behavior. Regards, Robert From kevin.rushforth at oracle.com Thu Mar 12 19:33:41 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Mar 2015 12:33:41 -0700 Subject: [8u60] review request: RT-40254: Allow building with gradle 2.X Message-ID: <5501EA15.3080205@oracle.com> Dave, Please review the following: https://javafx-jira.kenai.com/browse/RT-40254 This change will allow building with gradle 2.X, although 1.8 is still the default (this will not change in FX 8u). Tested with gradle 1.8 and 2.3. -- Kevin From david.dehaven at oracle.com Thu Mar 12 19:46:30 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 12 Mar 2015 12:46:30 -0700 Subject: MediaPlayer status changes In-Reply-To: References: Message-ID: <2AA3B0FB-DEF6-4025-ADD9-B9F315902A55@oracle.com> > I don't see anything in the docs stating how status should change in > MediaPlayer, e.g. will reaching end of media trigger a transition from > PLAYING to STOPPED? Will a subsequent call to play() start at the beginning > of the media file or do I need to seek? I was expecting some kind of status > change on end of media but am not seeing any when playing back an audio > sample until the end and when I checked the api doc, I didn't find anything > (e.g. like a state diagram) to check if it's a bug or documented behavior. The formal documentation is here (read the package Description, link at the top): http://docs.oracle.com/javase/8/javafx/api/javafx/scene/media/package-summary.html There?s actually a flow chart in the docs for MediaPlayer.Status: http://docs.oracle.com/javase/8/javafx/api/javafx/scene/media/MediaPlayer.Status.html Hope that helps. -DrD- From david.dehaven at oracle.com Thu Mar 12 19:48:38 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 12 Mar 2015 12:48:38 -0700 Subject: Media player maturity (on Mac) In-Reply-To: References: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> <97A90385-B65A-4DCF-AD2F-6463D2059CE7@oracle.com> <27B8FEC2-831A-4DE4-A6BE-BDD802DC70E3@oracle.com> Message-ID: <4D517184-D336-42B8-BA8F-FABEE1EA3684@oracle.com> > > One more question regarding this. Is it OK to have many instances of AudioClip or MediaPlayer if only a few of them actually play stuff or do they block audio resources even when they are stopped? > > You can have as many as memory will allow :) They don?t tie up hardware resources until actually playing. I actually recommend pre-loading AudioClips to avoid startup latency, especially if they?re fetched remotely. > > Thanks for the info! Oh, and if you have a lot of AudioClips, it?s best to spawn a new thread to load them up asynchronously, otherwise you could block the main application thread which will render the UI unresponsive while it?s loading. We?ve seen this happen on a couple occasions... I wanted to provide a library API to handle pre-loading, but didn?t have the time or resources :( -DrD- From krueger at lesspain.de Fri Mar 13 08:18:36 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Fri, 13 Mar 2015 09:18:36 +0100 Subject: Media player maturity (on Mac) In-Reply-To: <4D517184-D336-42B8-BA8F-FABEE1EA3684@oracle.com> References: <3B7094BD-B86E-431D-8F9D-3E05C12F505F@oracle.com> <97A90385-B65A-4DCF-AD2F-6463D2059CE7@oracle.com> <27B8FEC2-831A-4DE4-A6BE-BDD802DC70E3@oracle.com> <4D517184-D336-42B8-BA8F-FABEE1EA3684@oracle.com> Message-ID: On Thu, Mar 12, 2015 at 8:48 PM, David DeHaven wrote: > > > > One more question regarding this. Is it OK to have many instances of > AudioClip or MediaPlayer if only a few of them actually play stuff or do > they block audio resources even when they are stopped? > > > > You can have as many as memory will allow :) They don?t tie up hardware > resources until actually playing. I actually recommend pre-loading > AudioClips to avoid startup latency, especially if they?re fetched remotely. > > > > Thanks for the info! > > Oh, and if you have a lot of AudioClips, it?s best to spawn a new thread > to load them up asynchronously, otherwise you could block the main > application thread which will render the UI unresponsive while it?s > loading. We?ve seen this happen on a couple occasions... > > Good to know, thanks. > I wanted to provide a library API to handle pre-loading, but didn?t have > the time or resources :( > I can imagine resources quite stretched for a huge project like this. Maybe JFX10 then ;-). From vadim.pakhnushev at oracle.com Fri Mar 13 14:48:27 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 13 Mar 2015 17:48:27 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <5502F8BB.6010008@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From kevin.rushforth at oracle.com Fri Mar 13 23:44:00 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 Mar 2015 16:44:00 -0700 Subject: HEADS-UP: 8u-dev will stop syncing into 9-dev in about 2 weeks Message-ID: <55037640.3000106@oracle.com> As a heads-up, we will stop automatically forward-sync changes from 8u to 9 in about two weeks (to coincide with the feature freeze of 8u60). I will give more details later, but the high-level summary is: * It will be business as usual next week and until 1am on Monday, Mar 23 -- most changes will be pushed into 8u-dev for 8u60 * I will sync changes as usual from 8u-dev to 9-dev * Some time during the week of Mar 23 (I hope it will be on the 23rd, but might be a couple days later), we plan to backport the webkit changes to 8u60 and push them into 8u-dev; since this will include the compiler upgrade for 8u60 I will send a separate notification about this. * It will still be business as usual through 1am on Monday, Mar 30. I will export any changesets that go into 8u-dev after the webkit backport and import them into 9-dev so that we will effectively continue auto-syncing through Mar 30. * On Monday, Mar 30, all developers should plan to switch to the same model that the JDK uses: namely fixes should go into 9-dev first and those fixes that are relevant to 8u60 can be backported to 8u60 and pushed to 8u-dev; it will become the developer's responsibility to do this push. Let me know if you have any questions on any of this. -- Kevin From tomas.mikula at gmail.com Sat Mar 14 03:33:29 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Fri, 13 Mar 2015 23:33:29 -0400 Subject: The trouble with Skins Message-ID: A quick poll: Has anyone ever implemented a custom skin for some of the more complex controls like ListView, TableView, TreeView, TextArea? The problem I have with the Control/Skin architecture is that a Control, being a Node in the scene graph, cannot be a pure model (in the MVC sense) - it is inherently a view (in the MVC sense). What is the model of a check box? For me, a model of a check box is a boolean property; certainly not something that has boundsInParent or onZoomFinished properties. CheckBox is hardly a model. It is a view. Everything in the scene graph is inherently a view. There is this idea that the view aspect of a control is implemented by the skin. The control itself does not know what the skin looks like or even what skin class is used. So a ListView knows about its items, but it does not know about its scroll position. But users sometimes want to know the scroll position. Why should there be onScrollProperty, but not way to get the current scroll position? Why should there be TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There is no good way to implement the latter methods using custom skins. The ListView or TextArea don't know anything about the skin, thus they don't know anything about the current scroll position or caret bounds. They cannot ask the skin, because there might be no skin yet, and even if there is, all they know about it is that it is an instance of Skin - not much one can do with it (certainly not get caret bounds). I'm leaning more and more towards not supporting custom skins at all. The whole idea of overriding skins via CSS looks to me like dependency injection via CSS, except without any possibility to constrain the type of what can be injected. I would like to know the community opinion on this. Even hear your success story how skins are awesome, if there is such. Regards, Tomas From tbee at tbee.org Sat Mar 14 07:31:23 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 14 Mar 2015 08:31:23 +0100 Subject: The trouble with Skins In-Reply-To: References: Message-ID: <5503E3CB.4070506@tbee.org> Hi Tomas, I have looked into it, but not yet attempted, but I did do a lot of custom controls. And I agree that it is dubious that a control is a node, and has the properties that come with it. I try to maintain a strict separation in my controls in JFXtras; controls only have functional methods, the skin and CSS do all the layout. For example the gauge I've ported from Enzo; my version does not have a setFillColor() like the one in Enzo, that is something that the user needs to do through CSS. That said, if a control were only a model, than it would not be a control, right? We would create model-skins, so there is something that differentiates a control from a model. To me that is an abstraction of the skin. For example: not knowning HOW it is rendered, a textbox does know that it can receive the focus, it is implicit to what it is. So there is a certain logic for allowing controls to have rudimentary rendering info, as long as it does not expose the actual layout details. Looking at ListView, there is a logic in that a list can scroll, so onScroll on the control makes sense. Whether that scrolling is done via a scrollbar or buttons is a skin detail that should not leak out. So the fact that ListView does not have a scroll position makes sense to me. Tom On 14-3-2015 04:33, Tomas Mikula wrote: > A quick poll: > > Has anyone ever implemented a custom skin for some of the more complex > controls like ListView, TableView, TreeView, TextArea? > > The problem I have with the Control/Skin architecture is that a > Control, being a Node in the scene graph, cannot be a pure model (in > the MVC sense) - it is inherently a view (in the MVC sense). What is > the model of a check box? For me, a model of a check box is a boolean > property; certainly not something that has boundsInParent or > onZoomFinished properties. CheckBox is hardly a model. It is a view. > Everything in the scene graph is inherently a view. > > There is this idea that the view aspect of a control is implemented by > the skin. The control itself does not know what the skin looks like or > even what skin class is used. So a ListView knows about its items, but > it does not know about its scroll position. But users sometimes want > to know the scroll position. Why should there be onScrollProperty, but > not way to get the current scroll position? Why should there be > TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There > is no good way to implement the latter methods using custom skins. The > ListView or TextArea don't know anything about the skin, thus they > don't know anything about the current scroll position or caret bounds. > They cannot ask the skin, because there might be no skin yet, and even > if there is, all they know about it is that it is an instance of > Skin - not much one can do with it (certainly not get caret > bounds). > > I'm leaning more and more towards not supporting custom skins at all. > The whole idea of overriding skins via CSS looks to me like dependency > injection via CSS, except without any possibility to constrain the > type of what can be injected. > > I would like to know the community opinion on this. Even hear your > success story how skins are awesome, if there is such. > > Regards, > Tomas From tomas.mikula at gmail.com Sat Mar 14 16:07:01 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sat, 14 Mar 2015 12:07:01 -0400 Subject: The trouble with Skins In-Reply-To: <5503E3CB.4070506@tbee.org> References: <5503E3CB.4070506@tbee.org> Message-ID: I could say how I _feel_ differently about some things, but it's not important how I feel. What is important is that it comes down to practical problems. The layout details often leak and are not details anymore. Sometimes you would like to know if an item of a ListView is currently displayed. Or you want to know item's location on screen, so that you can position a popup next to it. This is something only the skin knows. As said before, Control is not your domain model. We need to go no further than OpenJFX for evidence: TextArea has a field of type TextAreaContent, which says "Text area content model". So not even OpenJFX uses Controls as (domain) models. So what kind of model is it? Is it a "model of interaction" with the domain model? Layout details necessarily leak in. Maybe just being able to specify required type of skin would help: if TextArea could say that its skin has to implement interface TextAreaSkin (which has the method getCaretBounds()). Also, I think skins should be opt-in - not all Controls should be Skinnable by default. Tomas On Sat, Mar 14, 2015 at 3:31 AM, Tom Eugelink wrote: > Hi Tomas, > > I have looked into it, but not yet attempted, but I did do a lot of custom > controls. And I agree that it is dubious that a control is a node, and has > the properties that come with it. I try to maintain a strict separation in > my controls in JFXtras; controls only have functional methods, the skin and > CSS do all the layout. For example the gauge I've ported from Enzo; my > version does not have a setFillColor() like the one in Enzo, that is > something that the user needs to do through CSS. > > That said, if a control were only a model, than it would not be a control, > right? We would create model-skins, so there is something that > differentiates a control from a model. To me that is an abstraction of the > skin. For example: not knowning HOW it is rendered, a textbox does know that > it can receive the focus, it is implicit to what it is. So there is a > certain logic for allowing controls to have rudimentary rendering info, as > long as it does not expose the actual layout details. > > Looking at ListView, there is a logic in that a list can scroll, so onScroll > on the control makes sense. Whether that scrolling is done via a scrollbar > or buttons is a skin detail that should not leak out. So the fact that > ListView does not have a scroll position makes sense to me. > > Tom > > > > On 14-3-2015 04:33, Tomas Mikula wrote: >> >> A quick poll: >> >> Has anyone ever implemented a custom skin for some of the more complex >> controls like ListView, TableView, TreeView, TextArea? >> >> The problem I have with the Control/Skin architecture is that a >> Control, being a Node in the scene graph, cannot be a pure model (in >> the MVC sense) - it is inherently a view (in the MVC sense). What is >> the model of a check box? For me, a model of a check box is a boolean >> property; certainly not something that has boundsInParent or >> onZoomFinished properties. CheckBox is hardly a model. It is a view. >> Everything in the scene graph is inherently a view. >> >> There is this idea that the view aspect of a control is implemented by >> the skin. The control itself does not know what the skin looks like or >> even what skin class is used. So a ListView knows about its items, but >> it does not know about its scroll position. But users sometimes want >> to know the scroll position. Why should there be onScrollProperty, but >> not way to get the current scroll position? Why should there be >> TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There >> is no good way to implement the latter methods using custom skins. The >> ListView or TextArea don't know anything about the skin, thus they >> don't know anything about the current scroll position or caret bounds. >> They cannot ask the skin, because there might be no skin yet, and even >> if there is, all they know about it is that it is an instance of >> Skin - not much one can do with it (certainly not get caret >> bounds). >> >> I'm leaning more and more towards not supporting custom skins at all. >> The whole idea of overriding skins via CSS looks to me like dependency >> injection via CSS, except without any possibility to constrain the >> type of what can be injected. >> >> I would like to know the community opinion on this. Even hear your >> success story how skins are awesome, if there is such. >> >> Regards, >> Tomas > > From martijnverburg at gmail.com Sun Mar 15 16:51:39 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 15 Mar 2015 16:51:39 +0000 Subject: Build farm for OpenJFX (on ARM) In-Reply-To: <1bab1d83297156ed60b45021c5dfd6fc.squirrel@excalibur.xssl.net> References: <6BA3EA13-80EF-475E-BD23-5BA095A2A995@oracle.com> <325f075db2878656a57d2f6964249aec.squirrel@excalibur.xssl.net> <1bab1d83297156ed60b45021c5dfd6fc.squirrel@excalibur.xssl.net> Message-ID: Hi Chris, Sorry for the late reply. I've made you an editor for the future and I'm linking in as you suggested. Cheers, Martijn On 9 March 2015 at 12:05, Chris Newland wrote: > Hi Martijn, > > I have "Role: Observer" for Adopt OpenJDK and I don't see any edit buttons > so guess I'm not permitted ;) > > There's already a very good wiki for OpenJFX here > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX so maybe > Adopt should link to that? > > Mani's been chipping away at the hurdles to get OpenJFX working on the > Adopt CloudBees but we're stuck on a darned Fedora/freetype dependency at > the moment so I've put this personal VPS together as a stop gap. > > I've pushed a little JavaFX benchmark framework to do some performance > measurements https://github.com/chriswhocodes/DemoFX and have found one > possible perf bug for which I'll submit a patch if confirmed. > > Hopefully this little framework will lower the bar for people to play with > JavaFX as you just need to implement a single render() method. > > Maybe I could do a JavaFX demoscene hacking tutorial at the next > Hack-the-Tower meetup? > > Cheers, > > Chris > > On Mon, March 9, 2015 09:41, Martijn Verburg wrote: > > Hi Chris, > > > > > > Just to add to this, have you got an account to edit the wiki at > > adoptopenjdk.java.net? We should add a link to this build from there. > > > > Cheers, > > Martijn > > > > > > On 9 March 2015 at 09:00, Chris Newland > > wrote: > > > > > >> Hi all, > >> > >> > >> A quick update on this: > >> > >> > >> There are a small number of wrinkles before we get OpenJFX building on > >> the Adoption group's CloudBees system so I've put together a > >> Debian-based VPS > >> server that is producing nightly OpenJFX builds for Linux amd64 and > >> armv6hf. > >> > >> It updates from http://hg.openjdk.java.net/openjfx/8u-dev/rt and pulls > >> the latest crosslibs dependencies before building so it's the bleeding > >> edge of the OpenJFX codebase. > >> > >> The build log shows failing tests for LinuxDebBundlerTest which I need > >> to fix but working binaries are still produced. > >> > >> http://108.61.191.178/ > >> > >> > >> No domain name yet as this is just a temporary home. > >> > >> > >> Oracle - please shout if there are any license issues with me doing > >> this? > >> > >> Cheers, > >> > >> > >> Chris > >> > >> > >> > > > > > From cnewland at chrisnewland.com Sun Mar 15 17:07:34 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Sun, 15 Mar 2015 17:07:34 -0000 Subject: Build farm for OpenJFX (on ARM) In-Reply-To: <55006F05.2010203@Oracle.com> References: <6BA3EA13-80EF-475E-BD23-5BA095A2A995@oracle.com> <325f075db2878656a57d2f6964249aec.squirrel@excalibur.xssl.net> <55006F05.2010203@Oracle.com> Message-ID: <55ffbd9e233c6f14ae8f6f9f12fcbbc2.squirrel@excalibur.xssl.net> Hi David, Thanks for the tip, the build server now uses the openZip task and the bundles appear to be fine when unzipped into a Java installation. Updated the instructions and it also now creates a build from 9-dev/rt. http://108.61.191.178/ The intention is still to move this over to Adoption Group's CloudBees but for now this helps IoT ARM JDKs to get OpenJFX support. Cheers, Chris On Wed, March 11, 2015 16:36, David Hill wrote: > On 3/9/15, 5:00 AM, Chris Newland wrote: > >> Hi all, >> >> >> A quick update on this: >> >> >> There are a small number of wrinkles before we get OpenJFX building on >> the Adoption group's CloudBees system so I've put together a >> Debian-based VPS >> server that is producing nightly OpenJFX builds for Linux amd64 and >> armv6hf. >> >> It updates fromhttp://hg.openjdk.java.net/openjfx/8u-dev/rt and pulls >> the latest crosslibs dependencies before building so it's the bleeding >> edge of the OpenJFX codebase. > Chris, > I forgot to blast this out to the group: > > > gradle openZip > > which is part of gradle zip -or- > gradle all at least in the open builds. > > This target was added a month or so ago, and I just fixed something in > in, that meant it was not showing up in openZip properly. > > This target builds a bundle in > ./builds/[platform-]bundles/javafx-sdk-overlay.zip > > > The contents include jfxrt.jar which has been filtered in a similar > fashion to the JFX product, removing some stuff that is not appropriate > to a given platform. (Yes that means Monocle on non-arm platforms). The > logic is pretty straight forward - ie Windows classes don't show up on a > non-windows platform. > > The resulting bundle *should* be able to be deployed by just unpacking it > over a JDK, which is intended to simplify matters. > > Dave > > > > -- > David Hill > Java Embedded Development > > > "A man's feet should be planted in his country, but his eyes should > survey the world." -- George Santayana (1863 - 1952) > > > From kevin.rushforth at oracle.com Mon Mar 16 20:16:17 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 16 Mar 2015 13:16:17 -0700 Subject: 8u-dev / 9-dev unlocked following this week's sanity testing Message-ID: <55073A11.2050906@oracle.com> From cnewland at chrisnewland.com Mon Mar 16 22:45:21 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Mon, 16 Mar 2015 22:45:21 -0000 Subject: libjfxmedia.so on armv6hf? Message-ID: In reference to http://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367&p=720267#p720267 When cross-compiling to armv6hf on an x86-64 Linux system using: gradle clean openZip -PCOMPILE_TARGETS=armv6hf Some of the binaries are compiled as x86-64: file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped Is this a simple gradle error or is it not currently possible to build some of the JavaFX libraries for ARM? Thanks, Chris From kevin.rushforth at oracle.com Mon Mar 16 23:14:36 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 16 Mar 2015 16:14:36 -0700 Subject: libjfxmedia.so on armv6hf? In-Reply-To: References: Message-ID: <550763DC.1010703@oracle.com> Media and web have not ever been supported or delivered on linux-arm. Seems that libjfxmedia.so should be excluded by the openZips target. David can response further. -- Kevin Chris Newland wrote: > In reference to > http://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367&p=720267#p720267 > > When cross-compiling to armv6hf on an x86-64 Linux system using: > > gradle clean openZip -PCOMPILE_TARGETS=armv6hf > > Some of the binaries are compiled as x86-64: > > file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so > > build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object, > x86-64, version 1 (SYSV), dynamically linked, > BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped > > Is this a simple gradle error or is it not currently possible to build > some of the JavaFX libraries for ARM? > > Thanks, > > Chris > > > From felix.bembrick at gmail.com Mon Mar 16 23:21:25 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 17 Mar 2015 10:21:25 +1100 Subject: libjfxmedia.so on armv6hf? In-Reply-To: <550763DC.1010703@oracle.com> References: <550763DC.1010703@oracle.com> Message-ID: Will they ever be supported? On 17 March 2015 at 10:14, Kevin Rushforth wrote: > Media and web have not ever been supported or delivered on linux-arm. > > Seems that libjfxmedia.so should be excluded by the openZips target. David > can response further. > > -- Kevin > > > > Chris Newland wrote: > >> In reference to >> http://www.raspberrypi.org/forums/viewtopic.php?f=81&t= >> 97367&p=720267#p720267 >> >> When cross-compiling to armv6hf on an x86-64 Linux system using: >> >> gradle clean openZip -PCOMPILE_TARGETS=armv6hf >> >> Some of the binaries are compiled as x86-64: >> >> file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so >> >> build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared >> object, >> x86-64, version 1 (SYSV), dynamically linked, >> BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped >> >> Is this a simple gradle error or is it not currently possible to build >> some of the JavaFX libraries for ARM? >> >> Thanks, >> >> Chris >> >> >> >> > From kevin.rushforth at oracle.com Mon Mar 16 23:27:53 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 16 Mar 2015 16:27:53 -0700 Subject: libjfxmedia.so on armv6hf? In-Reply-To: References: <550763DC.1010703@oracle.com> Message-ID: <550766F9.2020606@oracle.com> Unlikely without help from the community, given that FX itself is no longer supported on linux-arm. We currently have no plan to add such support. -- Kevin Felix Bembrick wrote: > Will they ever be supported? > > On 17 March 2015 at 10:14, Kevin Rushforth > wrote: > > Media and web have not ever been supported or delivered on linux-arm. > > Seems that libjfxmedia.so should be excluded by the openZips > target. David can response further. > > -- Kevin > > > > Chris Newland wrote: > > In reference to > http://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367&p=720267#p720267 > > > When cross-compiling to armv6hf on an x86-64 Linux system using: > > gradle clean openZip -PCOMPILE_TARGETS=armv6hf > > Some of the binaries are compiled as x86-64: > > file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so > > build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB > shared object, > x86-64, version 1 (SYSV), dynamically linked, > BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not > stripped > > Is this a simple gradle error or is it not currently possible > to build > some of the JavaFX libraries for ARM? > > Thanks, > > Chris > > > > > From Fabrizio.Giudici at tidalwave.it Mon Mar 16 23:53:21 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Tue, 17 Mar 2015 00:53:21 +0100 Subject: libjfxmedia.so on armv6hf? In-Reply-To: <550766F9.2020606@oracle.com> References: <550763DC.1010703@oracle.com> <550766F9.2020606@oracle.com> Message-ID: On Tue, 17 Mar 2015 00:27:53 +0100, Kevin Rushforth wrote: > Unlikely without help from the community, given that FX itself is no > longer supported on linux-arm. We currently have no plan to add such > support. Quite annoying stuff. BTW, I've just read http://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367 It's quite curious. I've just ordered a Raspberry Pi 2 and was planning about writing a media center prototype with some ideas in mind. In the past years I did lots of stuff with imaging and media, and was with Swing. I struggled with tons of incomplete features in the imaging and movie APIs, lots of additional libraries in order to have a decent modern UI (with animations and such), because Java didn't offer them out of the box. In the end I quit because it was frustrating to always be forced to fix something at the basics level. I mean, I just wanted to focus on the application. Now, fast forward some years and we have that Java FX, with bells and whistles. I supposed I could at last enjoy writing an app on the RPI without worrying about missing, incomplete, partially unsupported stuff, but I was wrong. It seems that no matter Sun or Oracle, there's a sort of curse preventing the Java ecosystem to fully work on the reference rich UI hardware. Sorry for the rant, nothing against people of course, but that's just my feelings at the moment. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From felix.bembrick at gmail.com Tue Mar 17 00:21:29 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 17 Mar 2015 11:21:29 +1100 Subject: libjfxmedia.so on armv6hf? In-Reply-To: References: <550763DC.1010703@oracle.com> <550766F9.2020606@oracle.com> Message-ID: Yes Fabrizio, I agree with you. First it was iOS, then Android and now ARM. Oracle the company seem to view JavafX or their support for it as just a fancy Swing replacement to run exclusively on desktop operating systems like Windows, MacOS and Linux. But can we even trust that they will continue to invest in those platforms? The problem seems to be as simple that Oracle makes little or no money directly from JavaFX and being a very profit focused company, why would they care about it? Their attitude now is that is you want JavaFX to actually work on anything other than the desktop (i.e. on all the modern devices that most people are actually using these days) then the "community" must step-up and make it happen. Thats a very disappointing and concerning attitude to say the least! Fortunately some in the community, notably Johan Vos and his company Gluon and Niklas Therning with RoboVM have "stepped-up" to try to fill this void but we are talking about a handful of people with shoestring budgets trying to get sophisticated technology working on an enormous range of complex and highly fragmented modern devices. How can they compete with a company like Qt which exists *only* to develop and sell Qt and have at least one hundred developers working on each of the iOS and Android ports and already have viable mobile apps using Qt selling out there in the marketplace. I really admire guys like this and wish that my own personal circumstances enabled me to get involved in a similar way but my main concern is that the "community" required to make JavaFX truly viable on iOS, Android and ARM needs to be about 50-100 times bigger than it currently is. Without an overall corporation paying the wages of these people, how is that ever going to happen? And by "truly viable" I mean making JavaFX a technology that can be used for *serious commercial application development *on all those platforms. Pretty gauges and simple square-based games are not enough to sustain or interest software houses to adopt JavaFX to develop their products and until that happens, JavaFX is going to struggle... Felix On 17 March 2015 at 10:53, Fabrizio Giudici wrote: > On Tue, 17 Mar 2015 00:27:53 +0100, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > > Unlikely without help from the community, given that FX itself is no >> longer supported on linux-arm. We currently have no plan to add such >> support. >> > > Quite annoying stuff. BTW, I've just read http://www.raspberrypi.org/ > forums/viewtopic.php?f=81&t=97367 > > It's quite curious. I've just ordered a Raspberry Pi 2 and was planning > about writing a media center prototype with some ideas in mind. In the past > years I did lots of stuff with imaging and media, and was with Swing. I > struggled with tons of incomplete features in the imaging and movie APIs, > lots of additional libraries in order to have a decent modern UI (with > animations and such), because Java didn't offer them out of the box. In the > end I quit because it was frustrating to always be forced to fix something > at the basics level. I mean, I just wanted to focus on the application. > Now, fast forward some years and we have that Java FX, with bells and > whistles. I supposed I could at last enjoy writing an app on the RPI > without worrying about missing, incomplete, partially unsupported stuff, > but I was wrong. It seems that no matter Sun or Oracle, there's a sort of > curse preventing the Java ecosystem to fully work on the reference rich UI > hardware. > > Sorry for the rant, nothing against people of course, but that's just my > feelings at the moment. > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it > From cnewland at chrisnewland.com Tue Mar 17 01:47:33 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 17 Mar 2015 01:47:33 -0000 Subject: libjfxmedia.so on armv6hf? In-Reply-To: <550763DC.1010703@oracle.com> References: <550763DC.1010703@oracle.com> Message-ID: Hi Kevin, Is there any chance Oracle can release all the missing ARM32 stuff and let the community have a go at getting it to work or are there IP / licensing issues here? I understand that a decision was made to reassign resources but I think there's enough brainpower out here in userland to finish the job if all the sources were made available. Thanks, Chris @chriswhocodes On Mon, March 16, 2015 23:14, Kevin Rushforth wrote: > Media and web have not ever been supported or delivered on linux-arm. > > > Seems that libjfxmedia.so should be excluded by the openZips target. > David can response further. > > > -- Kevin > > > > Chris Newland wrote: > >> In reference to >> http://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367&p=720267#p7 >> 20267 >> >> >> When cross-compiling to armv6hf on an x86-64 Linux system using: >> >> >> gradle clean openZip -PCOMPILE_TARGETS=armv6hf >> >> Some of the binaries are compiled as x86-64: >> >> >> file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so >> >> build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared >> object, x86-64, version 1 (SYSV), dynamically linked, >> BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped >> >> >> Is this a simple gradle error or is it not currently possible to build >> some of the JavaFX libraries for ARM? >> >> Thanks, >> >> >> Chris >> >> >> >> > From Fabrizio.Giudici at tidalwave.it Tue Mar 17 11:50:57 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Tue, 17 Mar 2015 12:50:57 +0100 Subject: libjfxmedia.so on armv6hf? In-Reply-To: References: <550763DC.1010703@oracle.com> <550766F9.2020606@oracle.com> Message-ID: On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick wrote: > I really admire guys like this and wish that my own personal > circumstances > enabled me to get involved in a similar way but my main concern is that > the > "community" required to make JavaFX truly viable on iOS, Android and ARM > needs to be about 50-100 times bigger than it currently is. Without an It's my concern too. At this point we're at 20 years of Java, and I lived them from the very beginning. The idea "the community will fix it" is a d?j? vu that, unfortunately, says that in the past the thing didn't work many times. This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2 arrives, I'll try the option you and others suggested. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From derijcke.erik at gmail.com Tue Mar 17 12:04:55 2015 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Tue, 17 Mar 2015 13:04:55 +0100 Subject: libjfxmedia.so on armv6hf? In-Reply-To: References: <550763DC.1010703@oracle.com> <550766F9.2020606@oracle.com> Message-ID: Why are there limitations on the "embedded" port of javafx to begin with? Are there technical reasons for it? If you think about it, "It's arm, so it's embedded. It's x86 so it's desktop" doesn't make much sense... (atom is embedded, and there are arm windows netbooks that are not). Anyway, as a workaround, can't openjfx simply be compiled on an arm host (so no cross compilation is required) and as such generate the missing libraries? Qemu with an arm vm can be used to do that on an x86 host for example. On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici < Fabrizio.Giudici at tidalwave.it> wrote: > On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick < > felix.bembrick at gmail.com> wrote: > > I really admire guys like this and wish that my own personal circumstances >> enabled me to get involved in a similar way but my main concern is that >> the >> "community" required to make JavaFX truly viable on iOS, Android and ARM >> needs to be about 50-100 times bigger than it currently is. Without an >> > > It's my concern too. At this point we're at 20 years of Java, and I lived > them from the very beginning. The idea "the community will fix it" is a > d?j? vu that, unfortunately, says that in the past the thing didn't work > many times. > > This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2 > arrives, I'll try the option you and others suggested. > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it > From kevin.rushforth at oracle.com Tue Mar 17 14:46:52 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Mar 2015 07:46:52 -0700 Subject: libjfxmedia.so on armv6hf? In-Reply-To: References: <550763DC.1010703@oracle.com> Message-ID: <55083E5C.8090805@oracle.com> Not sure what missing stuff you are referring to. All of the JavaFX sources for embedded are in the rt repo on openjfx. -- Kevin Chris Newland wrote: > Hi Kevin, > > Is there any chance Oracle can release all the missing ARM32 stuff and let > the community have a go at getting it to work or are there IP / licensing > issues here? > > I understand that a decision was made to reassign resources but I think > there's enough brainpower out here in userland to finish the job if all > the sources were made available. > > Thanks, > > Chris > @chriswhocodes > > On Mon, March 16, 2015 23:14, Kevin Rushforth wrote: > >> Media and web have not ever been supported or delivered on linux-arm. >> >> >> Seems that libjfxmedia.so should be excluded by the openZips target. >> David can response further. >> >> >> -- Kevin >> >> >> >> Chris Newland wrote: >> >> >>> In reference to >>> http://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367&p=720267#p7 >>> 20267 >>> >>> >>> When cross-compiling to armv6hf on an x86-64 Linux system using: >>> >>> >>> gradle clean openZip -PCOMPILE_TARGETS=armv6hf >>> >>> Some of the binaries are compiled as x86-64: >>> >>> >>> file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so >>> >>> build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared >>> object, x86-64, version 1 (SYSV), dynamically linked, >>> BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped >>> >>> >>> Is this a simple gradle error or is it not currently possible to build >>> some of the JavaFX libraries for ARM? >>> >>> Thanks, >>> >>> >>> Chris >>> >>> >>> >>> >>> > > > From cnewland at chrisnewland.com Tue Mar 17 17:50:31 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 17 Mar 2015 17:50:31 -0000 Subject: libjfxmedia.so on armv6hf? In-Reply-To: <55083E5C.8090805@oracle.com> References: <550763DC.1010703@oracle.com> <55083E5C.8090805@oracle.com> Message-ID: Sorry, I'm a bit confused: >> On Mon, March 16, 2015 23:14, Kevin Rushforth wrote: >> >> Media and web have not ever been supported or delivered on linux-arm. So it is possible to build libjfxmedia.so for Linux armv6hf using just what's in the rt repo? Thanks, Chris On Tue, March 17, 2015 14:46, Kevin Rushforth wrote: > Not sure what missing stuff you are referring to. All of the JavaFX > sources for embedded are in the rt repo on openjfx. > > -- Kevin > > > > Chris Newland wrote: > >> Hi Kevin, >> >> >> Is there any chance Oracle can release all the missing ARM32 stuff and >> let the community have a go at getting it to work or are there IP / >> licensing issues here? >> >> I understand that a decision was made to reassign resources but I think >> there's enough brainpower out here in userland to finish the job if >> all the sources were made available. >> >> Thanks, >> >> >> Chris >> @chriswhocodes >> >> >> On Mon, March 16, 2015 23:14, Kevin Rushforth wrote: >> >> >>> Media and web have not ever been supported or delivered on linux-arm. >>> >>> >>> >>> Seems that libjfxmedia.so should be excluded by the openZips target. >>> David can response further. >>> >>> >>> >>> -- Kevin >>> >>> >>> >>> >>> Chris Newland wrote: >>> >>> >>> >>>> In reference to >>>> http://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367&p=72026 >>>> 7#p7 >>>> 20267 >>>> >>>> >>>> >>>> When cross-compiling to armv6hf on an x86-64 Linux system using: >>>> >>>> >>>> >>>> gradle clean openZip -PCOMPILE_TARGETS=armv6hf >>>> >>>> Some of the binaries are compiled as x86-64: >>>> >>>> >>>> >>>> file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so >>>> >>>> build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared >>>> object, x86-64, version 1 (SYSV), dynamically linked, >>>> BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not >>>> stripped >>>> >>>> >>>> Is this a simple gradle error or is it not currently possible to >>>> build some of the JavaFX libraries for ARM? >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Chris >>>> >>>> >>>> >>>> >>>> >>>> >> >> >> > From David.Hill at Oracle.com Tue Mar 17 18:39:40 2015 From: David.Hill at Oracle.com (David Hill) Date: Tue, 17 Mar 2015 14:39:40 -0400 Subject: libjfxmedia.so on armv6hf? In-Reply-To: References: <550763DC.1010703@oracle.com> <550766F9.2020606@oracle.com> Message-ID: <550874EC.4070603@Oracle.com> On 3/17/15, 8:04 AM, Erik De Rijcke wrote: > Why are there limitations on the "embedded" port of javafx to begin with? > Are there technical reasons for it? Quite a few actually.... The "embedded" platforms have quite a few "features" that make them difficult. (and I have the bruises to prove it :-) To start with, an "embedded" application is usually a single purpose instead of a general purpose computing device. Think a kiosk for example. When I say general purpose devices - I mean classic desktops and now the mobile platforms, where the expectation is that the machine will be used for a number of application. Several of you will say that I am wrong, that a Raspberry Pi for example behaves just like a pokey "desktop" machine. This is a case where the lines have blurred and will continue to get more blurry. The Pi was one of a new generation of ARM platforms that have a community around them - a place where you can both buy a cheap board and get an OS and drivers without an NDA. So just as you can make a kiosk using a desktop machine, you can also use the PI with XMBC as a media center. As part of the "embedded" FX team, our design center was less the Pi running with X11, but rather a direct to framebuffer (without the overhead and limitations of X11). And the Pi was an after thought for us, a way to help out the community. We were targeting a more modern platforms liek the i.MX6. The problem with the direct to framebuffer, and to some extent with the rest of the ARM platforms - the platforms are really fractured and it is hard to build a working distro. I personally spend many a frustrating day trying to get some ARM platform to do something we take for granted on the desktop. Starting with.... OpenGLES drivers, especially ones that would talk to the framebuffer (and not X11). The Pi is one of the few examples out there of a port that has an easy download that contains most of the needed drivers already integrated (and documented). I spent almost a week fighting the Beagle Bone Black before getting up. Oh yes - and add on top of this all that GL initialization direct to framebuffer is non-standard API, so we ended up with 3 code paths for the platforms we were able to build. So in summary it is easy to download a Linux distro. The hardpart is right after you do that, and you want the proprietary hardware accelerated drivers. There are very few platforms that make this easy. And the Pi (version 1) is really too slow. The i.MX6 has enough power for a real application. The ODROID U3 and XU are also pretty spiffy, but I could not get direct to framebuffer working for either of those. If you want to use X11 - OpenJFX will probably work for you, and it might even have graphical acceleration if the drivers are present and integrated. Our Embedded team had ARM media as the next big thing to do, but ... So now we have all of the gstreamer code in the OpenJFX repo. I really expect that media on the Pi (1) will probably not work well due to the speed of the CPU and the memory bus. Maybe the Pi 2..... Again, you really need the right drivers in place to take advantage of hardware accelerated decoding of the media stream. With the right gstreamer libraries and drivers, I expect the media port would not take that long for someone that understands gstreamer. There might need to be some changes in Monocle to take the video stream hand off. I really would not expect that media would work without some debugging, and that after getting the build issues worked out. > > If you think about it, "It's arm, so it's embedded. It's x86 so it's > desktop" doesn't make much sense... (atom is embedded, and there are arm > windows netbooks that are not). > > Anyway, as a workaround, can't openjfx simply be compiled on an arm host > (so no cross compilation is required) and as such generate the missing > libraries? Qemu with an arm vm can be used to do that on an x86 host for > example. > > On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici< > Fabrizio.Giudici at tidalwave.it> wrote: > >> On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick< >> felix.bembrick at gmail.com> wrote: >> >> I really admire guys like this and wish that my own personal circumstances >>> enabled me to get involved in a similar way but my main concern is that >>> the >>> "community" required to make JavaFX truly viable on iOS, Android and ARM >>> needs to be about 50-100 times bigger than it currently is. Without an >>> >> It's my concern too. At this point we're at 20 years of Java, and I lived >> them from the very beginning. The idea "the community will fix it" is a >> d?j? vu that, unfortunately, says that in the past the thing didn't work >> many times. >> >> This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2 >> arrives, I'll try the option you and others suggested. >> >> >> -- >> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >> "We make Java work. Everywhere." >> http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it >> -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From ngalarneau at ABINITIO.COM Tue Mar 17 18:46:27 2015 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Tue, 17 Mar 2015 14:46:27 -0400 Subject: libjfxmedia.so on armv6hf? In-Reply-To: <550874EC.4070603@Oracle.com> References: <550763DC.1010703@oracle.com> <550766F9.2020606@oracle.com> <550874EC.4070603@Oracle.com> Message-ID: Thank you, David, for explaining all that is involved to us desktop-types. :-) Neil From: David Hill To: openjfx-dev at openjdk.java.net, Date: 03/17/2015 02:40 PM Subject: Re: libjfxmedia.so on armv6hf? Sent by: "openjfx-dev" On 3/17/15, 8:04 AM, Erik De Rijcke wrote: > Why are there limitations on the "embedded" port of javafx to begin with? > Are there technical reasons for it? Quite a few actually.... The "embedded" platforms have quite a few "features" that make them difficult. (and I have the bruises to prove it :-) To start with, an "embedded" application is usually a single purpose instead of a general purpose computing device. Think a kiosk for example. When I say general purpose devices - I mean classic desktops and now the mobile platforms, where the expectation is that the machine will be used for a number of application. Several of you will say that I am wrong, that a Raspberry Pi for example behaves just like a pokey "desktop" machine. This is a case where the lines have blurred and will continue to get more blurry. The Pi was one of a new generation of ARM platforms that have a community around them - a place where you can both buy a cheap board and get an OS and drivers without an NDA. So just as you can make a kiosk using a desktop machine, you can also use the PI with XMBC as a media center. As part of the "embedded" FX team, our design center was less the Pi running with X11, but rather a direct to framebuffer (without the overhead and limitations of X11). And the Pi was an after thought for us, a way to help out the community. We were targeting a more modern platforms liek the i.MX6. The problem with the direct to framebuffer, and to some extent with the rest of the ARM platforms - the platforms are really fractured and it is hard to build a working distro. I personally spend many a frustrating day trying to get some ARM platform to do something we take for granted on the desktop. Starting with.... OpenGLES drivers, especially ones that would talk to the framebuffer (and not X11). The Pi is one of the few examples out there of a port that has an easy download that contains most of the needed drivers already integrated (and documented). I spent almost a week fighting the Beagle Bone Black before getting up. Oh yes - and add on top of this all that GL initialization direct to framebuffer is non-standard API, so we ended up with 3 code paths for the platforms we were able to build. So in summary it is easy to download a Linux distro. The hardpart is right after you do that, and you want the proprietary hardware accelerated drivers. There are very few platforms that make this easy. And the Pi (version 1) is really too slow. The i.MX6 has enough power for a real application. The ODROID U3 and XU are also pretty spiffy, but I could not get direct to framebuffer working for either of those. If you want to use X11 - OpenJFX will probably work for you, and it might even have graphical acceleration if the drivers are present and integrated. Our Embedded team had ARM media as the next big thing to do, but ... So now we have all of the gstreamer code in the OpenJFX repo. I really expect that media on the Pi (1) will probably not work well due to the speed of the CPU and the memory bus. Maybe the Pi 2..... Again, you really need the right drivers in place to take advantage of hardware accelerated decoding of the media stream. With the right gstreamer libraries and drivers, I expect the media port would not take that long for someone that understands gstreamer. There might need to be some changes in Monocle to take the video stream hand off. I really would not expect that media would work without some debugging, and that after getting the build issues worked out. > > If you think about it, "It's arm, so it's embedded. It's x86 so it's > desktop" doesn't make much sense... (atom is embedded, and there are arm > windows netbooks that are not). > > Anyway, as a workaround, can't openjfx simply be compiled on an arm host > (so no cross compilation is required) and as such generate the missing > libraries? Qemu with an arm vm can be used to do that on an x86 host for > example. > > On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici< > Fabrizio.Giudici at tidalwave.it> wrote: > >> On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick< >> felix.bembrick at gmail.com> wrote: >> >> I really admire guys like this and wish that my own personal circumstances >>> enabled me to get involved in a similar way but my main concern is that >>> the >>> "community" required to make JavaFX truly viable on iOS, Android and ARM >>> needs to be about 50-100 times bigger than it currently is. Without an >>> >> It's my concern too. At this point we're at 20 years of Java, and I lived >> them from the very beginning. The idea "the community will fix it" is a >> d?j? vu that, unfortunately, says that in the past the thing didn't work >> many times. >> >> This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2 >> arrives, I'll try the option you and others suggested. >> >> >> -- >> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >> "We make Java work. Everywhere." >> http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it >> -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From derijcke.erik at gmail.com Tue Mar 17 19:55:18 2015 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Tue, 17 Mar 2015 20:55:18 +0100 Subject: libjfxmedia.so on armv6hf? In-Reply-To: <550874EC.4070603@Oracle.com> References: <550763DC.1010703@oracle.com> <550766F9.2020606@oracle.com> <550874EC.4070603@Oracle.com> Message-ID: Why didn't you target drm/kms gl approach? I realise not all platforms support this, but it would greatly extend the number of supported (embedded) platforms in a generic way. A quick google search seems to indicate that the sgx530 (BBB) has a kms driver as does the vivante (imx6). An RPi drm/kms driver also seems to be in the works and a lot of upcoming arm gpu's seem to be supported as well. By targeting kms/drm you'd be supporting a lot of platforms with a single codepath now and in the future. Unrelated, embedded jfx should use http://wayland.freedesktop.org/libinput/doc/latest/ instead of it's own bug-risky evdev/raw kernel input implementation. ;) Now if just somebody would sponser me so I can work fulltime to implement these things ;) On Tue, Mar 17, 2015 at 7:39 PM, David Hill wrote: > On 3/17/15, 8:04 AM, Erik De Rijcke wrote: > >> Why are there limitations on the "embedded" port of javafx to begin with? >> Are there technical reasons for it? >> > Quite a few actually.... > > The "embedded" platforms have quite a few "features" that make them > difficult. (and I have the bruises to prove it :-) > > To start with, an "embedded" application is usually a single purpose > instead of a general purpose computing device. Think a kiosk for example. > When I say general purpose devices - I mean classic desktops and now the > mobile platforms, where the expectation is that the machine will be used > for a number of application. > > Several of you will say that I am wrong, that a Raspberry Pi for example > behaves just like a pokey "desktop" machine. This is a case where the lines > have blurred and will continue to get more blurry. The Pi was one of a new > generation of ARM platforms that have a community around them - a place > where you can both buy a cheap board and get an OS and drivers without an > NDA. So just as you can make a kiosk using a desktop machine, you can also > use the PI with XMBC as a media center. > > As part of the "embedded" FX team, our design center was less the Pi > running with X11, but rather a direct to framebuffer (without the overhead > and limitations of X11). And the Pi was an after thought for us, a way to > help out the community. We were targeting a more modern platforms liek the > i.MX6. > > The problem with the direct to framebuffer, and to some extent with the > rest of the ARM platforms - the platforms are really fractured and it is > hard to build a working distro. I personally spend many a frustrating day > trying to get some ARM platform to do something we take for granted on the > desktop. Starting with.... OpenGLES drivers, especially ones that would > talk to the framebuffer (and not X11). The Pi is one of the few examples > out there of a port that has an easy download that contains most of the > needed drivers already integrated (and documented). I spent almost a week > fighting the Beagle Bone Black before getting up. Oh yes - and add on top > of this all that GL initialization direct to framebuffer is non-standard > API, so we ended up with 3 code paths for the platforms we were able to > build. > > So in summary it is easy to download a Linux distro. The hardpart is right > after you do that, and you want the proprietary hardware accelerated > drivers. There are very few platforms that make this easy. > > And the Pi (version 1) is really too slow. The i.MX6 has enough power for > a real application. The ODROID U3 and XU are also pretty spiffy, but I > could not get direct to framebuffer working for either of those. If you > want to use X11 - OpenJFX will probably work for you, and it might even > have graphical acceleration if the drivers are present and integrated. > > Our Embedded team had ARM media as the next big thing to do, but ... > > So now we have all of the gstreamer code in the OpenJFX repo. I really > expect that media on the Pi (1) will probably not work well due to the > speed of the CPU and the memory bus. Maybe the Pi 2..... > > Again, you really need the right drivers in place to take advantage of > hardware accelerated decoding of the media stream. > > With the right gstreamer libraries and drivers, I expect the media port > would not take that long for someone that understands gstreamer. > > There might need to be some changes in Monocle to take the video stream > hand off. > > I really would not expect that media would work without some debugging, > and that after getting the build issues worked out. > > > > >> If you think about it, "It's arm, so it's embedded. It's x86 so it's >> desktop" doesn't make much sense... (atom is embedded, and there are arm >> windows netbooks that are not). >> >> Anyway, as a workaround, can't openjfx simply be compiled on an arm host >> (so no cross compilation is required) and as such generate the missing >> libraries? Qemu with an arm vm can be used to do that on an x86 host for >> example. >> >> On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici< >> Fabrizio.Giudici at tidalwave.it> wrote: >> >> On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick< >>> felix.bembrick at gmail.com> wrote: >>> >>> I really admire guys like this and wish that my own personal >>> circumstances >>> >>>> enabled me to get involved in a similar way but my main concern is that >>>> the >>>> "community" required to make JavaFX truly viable on iOS, Android and ARM >>>> needs to be about 50-100 times bigger than it currently is. Without an >>>> >>>> It's my concern too. At this point we're at 20 years of Java, and I >>> lived >>> them from the very beginning. The idea "the community will fix it" is a >>> d?j? vu that, unfortunately, says that in the past the thing didn't work >>> many times. >>> >>> This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2 >>> arrives, I'll try the option you and others suggested. >>> >>> >>> -- >>> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >>> "We make Java work. Everywhere." >>> http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it >>> >>> > > -- > David Hill > Java Embedded Development > > "A man's feet should be planted in his country, but his eyes should survey > the world." > -- George Santayana (1863 - 1952) > > From morris.meyer at oracle.com Tue Mar 17 20:50:40 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 17 Mar 2015 16:50:40 -0400 Subject: [8u60] Review request: RT-39813: [Mac] JavaFX core dumps on Stage#close Message-ID: <550893A0.1070008@oracle.com> Kevin, Chien and David, Please review my fix for this Mac Stage focus close issue. The Mac OSX internals were forcing a callback event onto a non-focused window, and this preemptively asserts focus before allowing the event through. --morris WEBREV - http://cr.openjdk.java.net/~morris/RT-39813.01/ JIRA - https://javafx-jira.kenai.com/browse/RT-39813 From fbrunnerlist at gmx.ch Tue Mar 17 21:50:12 2015 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Tue, 17 Mar 2015 22:50:12 +0100 Subject: OpenJFX mirror at BitBucket? Message-ID: <4448565.lx0cmW0kx3@andor> Hi, AFAIK there is/ was a mirror of OpenJFX at BitBucket. I think the URL was https://bitbucket.org/openjfxmirrors, but it's not valid anymore. Is there still a mirror of OpenJFX at BitBucket? A fork/pull-request workflow is state-of-the-art nowadays in software development and way better than a patch-file based workflow IMHO. It would be great to have such a fork/pull-request workflow also for OpenJFX! -Florian From jonathan.giles at oracle.com Tue Mar 17 21:55:51 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 18 Mar 2015 10:55:51 +1300 Subject: OpenJFX mirror at BitBucket? In-Reply-To: <4448565.lx0cmW0kx3@andor> References: <4448565.lx0cmW0kx3@andor> Message-ID: <5508A2E7.3000809@oracle.com> There was a mirror, but it was unofficial and one-way (OpenJDK -> BitBucket). I believe (although my memory may be failing me) that it was operated by Danno, so he might have more to say. In regards to fork / pull-request vs patch-file, I have no arguments there. Of course, OpenJFX is part of the OpenJDK, and therefore makes use of the OpenJDK infrastructure. My main point is that any movement regarding infrastructure is guided by an over-arching infrastructure team, in conjunction with the OpenJDK masters. OpenJFX can't work independent of this. -- Jonathan On 18/03/2015 10:50 a.m., Florian Brunner wrote: > Hi, > > AFAIK there is/ was a mirror of OpenJFX at BitBucket. > > I think the URL was https://bitbucket.org/openjfxmirrors, but it's not valid > anymore. > > Is there still a mirror of OpenJFX at BitBucket? > > A fork/pull-request workflow is state-of-the-art nowadays in software > development and way better than a patch-file based workflow IMHO. > > It would be great to have such a fork/pull-request workflow also for OpenJFX! > > -Florian From kevin.rushforth at oracle.com Tue Mar 17 22:02:01 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Mar 2015 15:02:01 -0700 Subject: OpenJFX mirror at BitBucket? In-Reply-To: <5508A2E7.3000809@oracle.com> References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> Message-ID: <5508A459.7060906@oracle.com> Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror for your own experiments, that is certainly something you could do (subject to the GPLv2 + CLASSPATH license terms). For those patches to then be incorporated into the openjfx repos on hg.openjdk.java.net they need to go through the existing openjdk mechanism (which requires a signed OCA) as patches / webrevs, just like any other openjdk project. We cannot take patches directly from a BitBucket repo. -- Kevin Jonathan Giles wrote: > There was a mirror, but it was unofficial and one-way (OpenJDK -> > BitBucket). I believe (although my memory may be failing me) that it > was operated by Danno, so he might have more to say. > > In regards to fork / pull-request vs patch-file, I have no arguments > there. Of course, OpenJFX is part of the OpenJDK, and therefore makes > use of the OpenJDK infrastructure. My main point is that any movement > regarding infrastructure is guided by an over-arching infrastructure > team, in conjunction with the OpenJDK masters. OpenJFX can't work > independent of this. > > -- Jonathan > > On 18/03/2015 10:50 a.m., Florian Brunner wrote: >> Hi, >> >> AFAIK there is/ was a mirror of OpenJFX at BitBucket. >> >> I think the URL was https://bitbucket.org/openjfxmirrors, but it's >> not valid >> anymore. >> >> Is there still a mirror of OpenJFX at BitBucket? >> >> A fork/pull-request workflow is state-of-the-art nowadays in software >> development and way better than a patch-file based workflow IMHO. >> >> It would be great to have such a fork/pull-request workflow also for >> OpenJFX! >> >> -Florian > From fbrunnerlist at gmx.ch Tue Mar 17 22:12:41 2015 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Tue, 17 Mar 2015 23:12:41 +0100 Subject: OpenJFX mirror at BitBucket? In-Reply-To: <5508A459.7060906@oracle.com> References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> Message-ID: <44586436.hfhyBupV1v@andor> Wouldn't it be possible for the OpenJFX team to officially maintain a mirror at BitBucket themselves and use the same criteria for accepting a pull-request as for accepting a patch-file? Then you're sure that you can synchronize it with the main repositories without any legal or quality issues. The contributors could link their forks and pull-requests in JIRA for documentation purposes. It would really be great if we could move on with this. -Florian Am Dienstag, 17. M?rz 2015, 15.02:01 schrieb Kevin Rushforth: > Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror > for your own experiments, that is certainly something you could do > (subject to the GPLv2 + CLASSPATH license terms). > > For those patches to then be incorporated into the openjfx repos on > hg.openjdk.java.net they need to go through the existing openjdk > mechanism (which requires a signed OCA) as patches / webrevs, just like > any other openjdk project. We cannot take patches directly from a > BitBucket repo. > > -- Kevin > > Jonathan Giles wrote: > > There was a mirror, but it was unofficial and one-way (OpenJDK -> > > BitBucket). I believe (although my memory may be failing me) that it > > was operated by Danno, so he might have more to say. > > > > In regards to fork / pull-request vs patch-file, I have no arguments > > there. Of course, OpenJFX is part of the OpenJDK, and therefore makes > > use of the OpenJDK infrastructure. My main point is that any movement > > regarding infrastructure is guided by an over-arching infrastructure > > team, in conjunction with the OpenJDK masters. OpenJFX can't work > > independent of this. > > > > -- Jonathan > > > > On 18/03/2015 10:50 a.m., Florian Brunner wrote: > >> Hi, > >> > >> AFAIK there is/ was a mirror of OpenJFX at BitBucket. > >> > >> I think the URL was https://bitbucket.org/openjfxmirrors, but it's > >> not valid > >> anymore. > >> > >> Is there still a mirror of OpenJFX at BitBucket? > >> > >> A fork/pull-request workflow is state-of-the-art nowadays in software > >> development and way better than a patch-file based workflow IMHO. > >> > >> It would be great to have such a fork/pull-request workflow also for > >> OpenJFX! > >> > >> -Florian From jonathan.giles at oracle.com Tue Mar 17 22:22:25 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 18 Mar 2015 11:22:25 +1300 Subject: OpenJFX mirror at BitBucket? In-Reply-To: <44586436.hfhyBupV1v@andor> References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> Message-ID: <5508A921.2000503@oracle.com> There is no issue with members of the community using BitBucket to develop their patches. I just don't think it is a wise use of our limited time to maintain a mirror. This seems something that interested community members can do if they want. The main issue is as Kevin mentioned - someone has to submit the patch officially, and that someone has to have signed an OCA stating that they are owners of the code and IP being submitted. It would pay to very carefully track who has contributed code to a certain patch file, as all contributors will need to have signed an OCA. -- Jonathan On 18/03/2015 11:12 a.m., Florian Brunner wrote: > Wouldn't it be possible for the OpenJFX team to officially maintain a mirror at > BitBucket themselves and use the same criteria for accepting a pull-request as > for accepting a patch-file? Then you're sure that you can synchronize it with > the main repositories without any legal or quality issues. > > The contributors could link their forks and pull-requests in JIRA for > documentation purposes. > > It would really be great if we could move on with this. > > -Florian > > Am Dienstag, 17. M?rz 2015, 15.02:01 schrieb Kevin Rushforth: >> Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror >> for your own experiments, that is certainly something you could do >> (subject to the GPLv2 + CLASSPATH license terms). >> >> For those patches to then be incorporated into the openjfx repos on >> hg.openjdk.java.net they need to go through the existing openjdk >> mechanism (which requires a signed OCA) as patches / webrevs, just like >> any other openjdk project. We cannot take patches directly from a >> BitBucket repo. >> >> -- Kevin >> >> Jonathan Giles wrote: >>> There was a mirror, but it was unofficial and one-way (OpenJDK -> >>> BitBucket). I believe (although my memory may be failing me) that it >>> was operated by Danno, so he might have more to say. >>> >>> In regards to fork / pull-request vs patch-file, I have no arguments >>> there. Of course, OpenJFX is part of the OpenJDK, and therefore makes >>> use of the OpenJDK infrastructure. My main point is that any movement >>> regarding infrastructure is guided by an over-arching infrastructure >>> team, in conjunction with the OpenJDK masters. OpenJFX can't work >>> independent of this. >>> >>> -- Jonathan >>> >>> On 18/03/2015 10:50 a.m., Florian Brunner wrote: >>>> Hi, >>>> >>>> AFAIK there is/ was a mirror of OpenJFX at BitBucket. >>>> >>>> I think the URL was https://bitbucket.org/openjfxmirrors, but it's >>>> not valid >>>> anymore. >>>> >>>> Is there still a mirror of OpenJFX at BitBucket? >>>> >>>> A fork/pull-request workflow is state-of-the-art nowadays in software >>>> development and way better than a patch-file based workflow IMHO. >>>> >>>> It would be great to have such a fork/pull-request workflow also for >>>> OpenJFX! >>>> >>>> -Florian From tomas.mikula at gmail.com Wed Mar 18 00:03:28 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Tue, 17 Mar 2015 20:03:28 -0400 Subject: OpenJFX mirror at BitBucket? In-Reply-To: <5508A921.2000503@oracle.com> References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> Message-ID: Legal issues could be resolved by requiring a signed OCA before each pull request is merged. But anyway, if OpenJDK project does not accept pull requests, who is going to create the patches? If patches are painful for individual developers, they are going to be super painful for the person who is supposed to get the accepted PRs back to OpenJDK. OTOH, one-way mirrors should be easy enough to maintain by anyone who has access to a server where they can set up a cron task to periodically pull from OpenJDK repos and push to bitbucket repos. Whoever forks the mirror and makes changes would still have to submit patches directly to OpenJDK. Tomas On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles wrote: > There is no issue with members of the community using BitBucket to develop > their patches. I just don't think it is a wise use of our limited time to > maintain a mirror. This seems something that interested community members > can do if they want. The main issue is as Kevin mentioned - someone has to > submit the patch officially, and that someone has to have signed an OCA > stating that they are owners of the code and IP being submitted. It would > pay to very carefully track who has contributed code to a certain patch > file, as all contributors will need to have signed an OCA. > > -- Jonathan > > > On 18/03/2015 11:12 a.m., Florian Brunner wrote: >> >> Wouldn't it be possible for the OpenJFX team to officially maintain a >> mirror at >> BitBucket themselves and use the same criteria for accepting a >> pull-request as >> for accepting a patch-file? Then you're sure that you can synchronize it >> with >> the main repositories without any legal or quality issues. >> >> The contributors could link their forks and pull-requests in JIRA for >> documentation purposes. >> >> It would really be great if we could move on with this. >> >> -Florian >> >> Am Dienstag, 17. M?rz 2015, 15.02:01 schrieb Kevin Rushforth: >>> >>> Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror >>> for your own experiments, that is certainly something you could do >>> (subject to the GPLv2 + CLASSPATH license terms). >>> >>> For those patches to then be incorporated into the openjfx repos on >>> hg.openjdk.java.net they need to go through the existing openjdk >>> mechanism (which requires a signed OCA) as patches / webrevs, just like >>> any other openjdk project. We cannot take patches directly from a >>> BitBucket repo. >>> >>> -- Kevin >>> >>> Jonathan Giles wrote: >>>> >>>> There was a mirror, but it was unofficial and one-way (OpenJDK -> >>>> BitBucket). I believe (although my memory may be failing me) that it >>>> was operated by Danno, so he might have more to say. >>>> >>>> In regards to fork / pull-request vs patch-file, I have no arguments >>>> there. Of course, OpenJFX is part of the OpenJDK, and therefore makes >>>> use of the OpenJDK infrastructure. My main point is that any movement >>>> regarding infrastructure is guided by an over-arching infrastructure >>>> team, in conjunction with the OpenJDK masters. OpenJFX can't work >>>> independent of this. >>>> >>>> -- Jonathan >>>> >>>> On 18/03/2015 10:50 a.m., Florian Brunner wrote: >>>>> >>>>> Hi, >>>>> >>>>> AFAIK there is/ was a mirror of OpenJFX at BitBucket. >>>>> >>>>> I think the URL was https://bitbucket.org/openjfxmirrors, but it's >>>>> not valid >>>>> anymore. >>>>> >>>>> Is there still a mirror of OpenJFX at BitBucket? >>>>> >>>>> A fork/pull-request workflow is state-of-the-art nowadays in software >>>>> development and way better than a patch-file based workflow IMHO. >>>>> >>>>> It would be great to have such a fork/pull-request workflow also for >>>>> OpenJFX! >>>>> >>>>> -Florian > > From jonathan.giles at oracle.com Wed Mar 18 00:09:52 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 18 Mar 2015 13:09:52 +1300 Subject: OpenJFX mirror at BitBucket? In-Reply-To: References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> Message-ID: <5508C250.1060709@oracle.com> BitBucket supports generation of patches from pull requests. My suggestion was that community members who wanted to use BitBucket to collaborate and / or easily keep their work current with the repo could do so, and when they create their pull request, they can have bitbucket generate the patch file for submission 'the old fashioned way'. -- Jonathan On 18/03/2015 1:03 p.m., Tomas Mikula wrote: > Legal issues could be resolved by requiring a signed OCA before each > pull request is merged. But anyway, if OpenJDK project does not accept > pull requests, who is going to create the patches? If patches are > painful for individual developers, they are going to be super painful > for the person who is supposed to get the accepted PRs back to > OpenJDK. > > OTOH, one-way mirrors should be easy enough to maintain by anyone who > has access to a server where they can set up a cron task to > periodically pull from OpenJDK repos and push to bitbucket repos. > Whoever forks the mirror and makes changes would still have to submit > patches directly to OpenJDK. > > Tomas > > On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles > wrote: >> There is no issue with members of the community using BitBucket to develop >> their patches. I just don't think it is a wise use of our limited time to >> maintain a mirror. This seems something that interested community members >> can do if they want. The main issue is as Kevin mentioned - someone has to >> submit the patch officially, and that someone has to have signed an OCA >> stating that they are owners of the code and IP being submitted. It would >> pay to very carefully track who has contributed code to a certain patch >> file, as all contributors will need to have signed an OCA. >> >> -- Jonathan >> >> >> On 18/03/2015 11:12 a.m., Florian Brunner wrote: >>> Wouldn't it be possible for the OpenJFX team to officially maintain a >>> mirror at >>> BitBucket themselves and use the same criteria for accepting a >>> pull-request as >>> for accepting a patch-file? Then you're sure that you can synchronize it >>> with >>> the main repositories without any legal or quality issues. >>> >>> The contributors could link their forks and pull-requests in JIRA for >>> documentation purposes. >>> >>> It would really be great if we could move on with this. >>> >>> -Florian >>> >>> Am Dienstag, 17. M?rz 2015, 15.02:01 schrieb Kevin Rushforth: >>>> Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror >>>> for your own experiments, that is certainly something you could do >>>> (subject to the GPLv2 + CLASSPATH license terms). >>>> >>>> For those patches to then be incorporated into the openjfx repos on >>>> hg.openjdk.java.net they need to go through the existing openjdk >>>> mechanism (which requires a signed OCA) as patches / webrevs, just like >>>> any other openjdk project. We cannot take patches directly from a >>>> BitBucket repo. >>>> >>>> -- Kevin >>>> >>>> Jonathan Giles wrote: >>>>> There was a mirror, but it was unofficial and one-way (OpenJDK -> >>>>> BitBucket). I believe (although my memory may be failing me) that it >>>>> was operated by Danno, so he might have more to say. >>>>> >>>>> In regards to fork / pull-request vs patch-file, I have no arguments >>>>> there. Of course, OpenJFX is part of the OpenJDK, and therefore makes >>>>> use of the OpenJDK infrastructure. My main point is that any movement >>>>> regarding infrastructure is guided by an over-arching infrastructure >>>>> team, in conjunction with the OpenJDK masters. OpenJFX can't work >>>>> independent of this. >>>>> >>>>> -- Jonathan >>>>> >>>>> On 18/03/2015 10:50 a.m., Florian Brunner wrote: >>>>>> Hi, >>>>>> >>>>>> AFAIK there is/ was a mirror of OpenJFX at BitBucket. >>>>>> >>>>>> I think the URL was https://bitbucket.org/openjfxmirrors, but it's >>>>>> not valid >>>>>> anymore. >>>>>> >>>>>> Is there still a mirror of OpenJFX at BitBucket? >>>>>> >>>>>> A fork/pull-request workflow is state-of-the-art nowadays in software >>>>>> development and way better than a patch-file based workflow IMHO. >>>>>> >>>>>> It would be great to have such a fork/pull-request workflow also for >>>>>> OpenJFX! >>>>>> >>>>>> -Florian >> From tomas.mikula at gmail.com Wed Mar 18 00:19:21 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Tue, 17 Mar 2015 20:19:21 -0400 Subject: OpenJFX mirror at BitBucket? In-Reply-To: <5508C250.1060709@oracle.com> References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> <5508C250.1060709@oracle.com> Message-ID: But we still need this one-way mirror, from which users can fork, right? My assumption is that bitbucket will not keep track of how much you diverged from the OpenJDK repo you initially cloned. It will, however, tell you how much you diverged from a bitbucket repo that you forked. On Tue, Mar 17, 2015 at 8:09 PM, Jonathan Giles wrote: > BitBucket supports generation of patches from pull requests. My suggestion > was that community members who wanted to use BitBucket to collaborate and / > or easily keep their work current with the repo could do so, and when they > create their pull request, they can have bitbucket generate the patch file > for submission 'the old fashioned way'. > > -- Jonathan > > On 18/03/2015 1:03 p.m., Tomas Mikula wrote: >> >> Legal issues could be resolved by requiring a signed OCA before each >> pull request is merged. But anyway, if OpenJDK project does not accept >> pull requests, who is going to create the patches? If patches are >> painful for individual developers, they are going to be super painful >> for the person who is supposed to get the accepted PRs back to >> OpenJDK. >> >> OTOH, one-way mirrors should be easy enough to maintain by anyone who >> has access to a server where they can set up a cron task to >> periodically pull from OpenJDK repos and push to bitbucket repos. >> Whoever forks the mirror and makes changes would still have to submit >> patches directly to OpenJDK. >> >> Tomas >> >> On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles >> wrote: >>> >>> There is no issue with members of the community using BitBucket to >>> develop >>> their patches. I just don't think it is a wise use of our limited time to >>> maintain a mirror. This seems something that interested community members >>> can do if they want. The main issue is as Kevin mentioned - someone has >>> to >>> submit the patch officially, and that someone has to have signed an OCA >>> stating that they are owners of the code and IP being submitted. It would >>> pay to very carefully track who has contributed code to a certain patch >>> file, as all contributors will need to have signed an OCA. >>> >>> -- Jonathan >>> >>> >>> On 18/03/2015 11:12 a.m., Florian Brunner wrote: >>>> >>>> Wouldn't it be possible for the OpenJFX team to officially maintain a >>>> mirror at >>>> BitBucket themselves and use the same criteria for accepting a >>>> pull-request as >>>> for accepting a patch-file? Then you're sure that you can synchronize it >>>> with >>>> the main repositories without any legal or quality issues. >>>> >>>> The contributors could link their forks and pull-requests in JIRA for >>>> documentation purposes. >>>> >>>> It would really be great if we could move on with this. >>>> >>>> -Florian >>>> >>>> Am Dienstag, 17. M?rz 2015, 15.02:01 schrieb Kevin Rushforth: >>>>> >>>>> Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror >>>>> for your own experiments, that is certainly something you could do >>>>> (subject to the GPLv2 + CLASSPATH license terms). >>>>> >>>>> For those patches to then be incorporated into the openjfx repos on >>>>> hg.openjdk.java.net they need to go through the existing openjdk >>>>> mechanism (which requires a signed OCA) as patches / webrevs, just like >>>>> any other openjdk project. We cannot take patches directly from a >>>>> BitBucket repo. >>>>> >>>>> -- Kevin >>>>> >>>>> Jonathan Giles wrote: >>>>>> >>>>>> There was a mirror, but it was unofficial and one-way (OpenJDK -> >>>>>> BitBucket). I believe (although my memory may be failing me) that it >>>>>> was operated by Danno, so he might have more to say. >>>>>> >>>>>> In regards to fork / pull-request vs patch-file, I have no arguments >>>>>> there. Of course, OpenJFX is part of the OpenJDK, and therefore makes >>>>>> use of the OpenJDK infrastructure. My main point is that any movement >>>>>> regarding infrastructure is guided by an over-arching infrastructure >>>>>> team, in conjunction with the OpenJDK masters. OpenJFX can't work >>>>>> independent of this. >>>>>> >>>>>> -- Jonathan >>>>>> >>>>>> On 18/03/2015 10:50 a.m., Florian Brunner wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> AFAIK there is/ was a mirror of OpenJFX at BitBucket. >>>>>>> >>>>>>> I think the URL was https://bitbucket.org/openjfxmirrors, but it's >>>>>>> not valid >>>>>>> anymore. >>>>>>> >>>>>>> Is there still a mirror of OpenJFX at BitBucket? >>>>>>> >>>>>>> A fork/pull-request workflow is state-of-the-art nowadays in software >>>>>>> development and way better than a patch-file based workflow IMHO. >>>>>>> >>>>>>> It would be great to have such a fork/pull-request workflow also for >>>>>>> OpenJFX! >>>>>>> >>>>>>> -Florian >>> >>> > From jonathan.giles at oracle.com Wed Mar 18 00:21:16 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 18 Mar 2015 13:21:16 +1300 Subject: OpenJFX mirror at BitBucket? In-Reply-To: References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> <5508C250.1060709@oracle.com> Message-ID: Correct. -- Jonathan On 18 March 2015 13:19:21 GMT+13:00, Tomas Mikula wrote: >But we still need this one-way mirror, from which users can fork, >right? My assumption is that bitbucket will not keep track of how much >you diverged from the OpenJDK repo you initially cloned. It will, >however, tell you how much you diverged from a bitbucket repo that you >forked. > >On Tue, Mar 17, 2015 at 8:09 PM, Jonathan Giles > wrote: >> BitBucket supports generation of patches from pull requests. My >suggestion >> was that community members who wanted to use BitBucket to collaborate >and / >> or easily keep their work current with the repo could do so, and when >they >> create their pull request, they can have bitbucket generate the patch >file >> for submission 'the old fashioned way'. >> >> -- Jonathan >> >> On 18/03/2015 1:03 p.m., Tomas Mikula wrote: >>> >>> Legal issues could be resolved by requiring a signed OCA before each >>> pull request is merged. But anyway, if OpenJDK project does not >accept >>> pull requests, who is going to create the patches? If patches are >>> painful for individual developers, they are going to be super >painful >>> for the person who is supposed to get the accepted PRs back to >>> OpenJDK. >>> >>> OTOH, one-way mirrors should be easy enough to maintain by anyone >who >>> has access to a server where they can set up a cron task to >>> periodically pull from OpenJDK repos and push to bitbucket repos. >>> Whoever forks the mirror and makes changes would still have to >submit >>> patches directly to OpenJDK. >>> >>> Tomas >>> >>> On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles >>> wrote: >>>> >>>> There is no issue with members of the community using BitBucket to >>>> develop >>>> their patches. I just don't think it is a wise use of our limited >time to >>>> maintain a mirror. This seems something that interested community >members >>>> can do if they want. The main issue is as Kevin mentioned - someone >has >>>> to >>>> submit the patch officially, and that someone has to have signed an >OCA >>>> stating that they are owners of the code and IP being submitted. It >would >>>> pay to very carefully track who has contributed code to a certain >patch >>>> file, as all contributors will need to have signed an OCA. >>>> >>>> -- Jonathan >>>> >>>> >>>> On 18/03/2015 11:12 a.m., Florian Brunner wrote: >>>>> >>>>> Wouldn't it be possible for the OpenJFX team to officially >maintain a >>>>> mirror at >>>>> BitBucket themselves and use the same criteria for accepting a >>>>> pull-request as >>>>> for accepting a patch-file? Then you're sure that you can >synchronize it >>>>> with >>>>> the main repositories without any legal or quality issues. >>>>> >>>>> The contributors could link their forks and pull-requests in JIRA >for >>>>> documentation purposes. >>>>> >>>>> It would really be great if we could move on with this. >>>>> >>>>> -Florian >>>>> >>>>> Am Dienstag, 17. M?rz 2015, 15.02:01 schrieb Kevin Rushforth: >>>>>> >>>>>> Right. If you wanted to revive the unofficial OpenJFX bitbucket >mirror >>>>>> for your own experiments, that is certainly something you could >do >>>>>> (subject to the GPLv2 + CLASSPATH license terms). >>>>>> >>>>>> For those patches to then be incorporated into the openjfx repos >on >>>>>> hg.openjdk.java.net they need to go through the existing openjdk >>>>>> mechanism (which requires a signed OCA) as patches / webrevs, >just like >>>>>> any other openjdk project. We cannot take patches directly from a >>>>>> BitBucket repo. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> Jonathan Giles wrote: >>>>>>> >>>>>>> There was a mirror, but it was unofficial and one-way (OpenJDK >-> >>>>>>> BitBucket). I believe (although my memory may be failing me) >that it >>>>>>> was operated by Danno, so he might have more to say. >>>>>>> >>>>>>> In regards to fork / pull-request vs patch-file, I have no >arguments >>>>>>> there. Of course, OpenJFX is part of the OpenJDK, and therefore >makes >>>>>>> use of the OpenJDK infrastructure. My main point is that any >movement >>>>>>> regarding infrastructure is guided by an over-arching >infrastructure >>>>>>> team, in conjunction with the OpenJDK masters. OpenJFX can't >work >>>>>>> independent of this. >>>>>>> >>>>>>> -- Jonathan >>>>>>> >>>>>>> On 18/03/2015 10:50 a.m., Florian Brunner wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> AFAIK there is/ was a mirror of OpenJFX at BitBucket. >>>>>>>> >>>>>>>> I think the URL was https://bitbucket.org/openjfxmirrors, but >it's >>>>>>>> not valid >>>>>>>> anymore. >>>>>>>> >>>>>>>> Is there still a mirror of OpenJFX at BitBucket? >>>>>>>> >>>>>>>> A fork/pull-request workflow is state-of-the-art nowadays in >software >>>>>>>> development and way better than a patch-file based workflow >IMHO. >>>>>>>> >>>>>>>> It would be great to have such a fork/pull-request workflow >also for >>>>>>>> OpenJFX! >>>>>>>> >>>>>>>> -Florian >>>> >>>> >> From chien.yang at oracle.com Wed Mar 18 01:21:17 2015 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 17 Mar 2015 18:21:17 -0700 Subject: Code Review Request For RT-40245: Regression: Mac (prism-sw) rendering is corrupted Message-ID: <5508D30D.4060003@oracle.com> Hi Kevin and Jim, Please review the proposed fix: JIRA: https://javafx-jira.kenai.com/browse/RT-40245 Webrev: http://cr.openjdk.java.net/~ckyang/RT-40245/webrev.00/ Thanks, - Chien From kevin.rushforth at oracle.com Wed Mar 18 01:31:19 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Mar 2015 18:31:19 -0700 Subject: Code Review Request For RT-40245: Regression: Mac (prism-sw) rendering is corrupted In-Reply-To: <5508D30D.4060003@oracle.com> References: <5508D30D.4060003@oracle.com> Message-ID: <5508D567.1000405@oracle.com> Since this is Mac glass code, Morris needs to review it as well. -- Kevin Chien Yang wrote: > Hi Kevin and Jim, > > Please review the proposed fix: > > JIRA: https://javafx-jira.kenai.com/browse/RT-40245 > Webrev: http://cr.openjdk.java.net/~ckyang/RT-40245/webrev.00/ > > Thanks, > - Chien From powers.anirvan at gmail.com Wed Mar 18 04:44:59 2015 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Wed, 18 Mar 2015 10:14:59 +0530 Subject: OpenJFX mirror at BitBucket? In-Reply-To: References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> <5508C250.1060709@oracle.com> Message-ID: Looks like the page https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow is outdated. It links to the BitBucket repo and mentions that one of the ways to provide a patch is to create a pull request on BitBucket. On 18 March 2015 at 05:51, Jonathan Giles wrote: > Correct. > -- Jonathan > > On 18 March 2015 13:19:21 GMT+13:00, Tomas Mikula > wrote: > >But we still need this one-way mirror, from which users can fork, > >right? My assumption is that bitbucket will not keep track of how much > >you diverged from the OpenJDK repo you initially cloned. It will, > >however, tell you how much you diverged from a bitbucket repo that you > >forked. > > > >On Tue, Mar 17, 2015 at 8:09 PM, Jonathan Giles > > wrote: > >> BitBucket supports generation of patches from pull requests. My > >suggestion > >> was that community members who wanted to use BitBucket to collaborate > >and / > >> or easily keep their work current with the repo could do so, and when > >they > >> create their pull request, they can have bitbucket generate the patch > >file > >> for submission 'the old fashioned way'. > >> > >> -- Jonathan > >> > >> On 18/03/2015 1:03 p.m., Tomas Mikula wrote: > >>> > >>> Legal issues could be resolved by requiring a signed OCA before each > >>> pull request is merged. But anyway, if OpenJDK project does not > >accept > >>> pull requests, who is going to create the patches? If patches are > >>> painful for individual developers, they are going to be super > >painful > >>> for the person who is supposed to get the accepted PRs back to > >>> OpenJDK. > >>> > >>> OTOH, one-way mirrors should be easy enough to maintain by anyone > >who > >>> has access to a server where they can set up a cron task to > >>> periodically pull from OpenJDK repos and push to bitbucket repos. > >>> Whoever forks the mirror and makes changes would still have to > >submit > >>> patches directly to OpenJDK. > >>> > >>> Tomas > >>> > >>> On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles > >>> wrote: > >>>> > >>>> There is no issue with members of the community using BitBucket to > >>>> develop > >>>> their patches. I just don't think it is a wise use of our limited > >time to > >>>> maintain a mirror. This seems something that interested community > >members > >>>> can do if they want. The main issue is as Kevin mentioned - someone > >has > >>>> to > >>>> submit the patch officially, and that someone has to have signed an > >OCA > >>>> stating that they are owners of the code and IP being submitted. It > >would > >>>> pay to very carefully track who has contributed code to a certain > >patch > >>>> file, as all contributors will need to have signed an OCA. > >>>> > >>>> -- Jonathan > >>>> > >>>> > >>>> On 18/03/2015 11:12 a.m., Florian Brunner wrote: > >>>>> > >>>>> Wouldn't it be possible for the OpenJFX team to officially > >maintain a > >>>>> mirror at > >>>>> BitBucket themselves and use the same criteria for accepting a > >>>>> pull-request as > >>>>> for accepting a patch-file? Then you're sure that you can > >synchronize it > >>>>> with > >>>>> the main repositories without any legal or quality issues. > >>>>> > >>>>> The contributors could link their forks and pull-requests in JIRA > >for > >>>>> documentation purposes. > >>>>> > >>>>> It would really be great if we could move on with this. > >>>>> > >>>>> -Florian > >>>>> > >>>>> Am Dienstag, 17. M?rz 2015, 15.02:01 schrieb Kevin Rushforth: > >>>>>> > >>>>>> Right. If you wanted to revive the unofficial OpenJFX bitbucket > >mirror > >>>>>> for your own experiments, that is certainly something you could > >do > >>>>>> (subject to the GPLv2 + CLASSPATH license terms). > >>>>>> > >>>>>> For those patches to then be incorporated into the openjfx repos > >on > >>>>>> hg.openjdk.java.net they need to go through the existing openjdk > >>>>>> mechanism (which requires a signed OCA) as patches / webrevs, > >just like > >>>>>> any other openjdk project. We cannot take patches directly from a > >>>>>> BitBucket repo. > >>>>>> > >>>>>> -- Kevin > >>>>>> > >>>>>> Jonathan Giles wrote: > >>>>>>> > >>>>>>> There was a mirror, but it was unofficial and one-way (OpenJDK > >-> > >>>>>>> BitBucket). I believe (although my memory may be failing me) > >that it > >>>>>>> was operated by Danno, so he might have more to say. > >>>>>>> > >>>>>>> In regards to fork / pull-request vs patch-file, I have no > >arguments > >>>>>>> there. Of course, OpenJFX is part of the OpenJDK, and therefore > >makes > >>>>>>> use of the OpenJDK infrastructure. My main point is that any > >movement > >>>>>>> regarding infrastructure is guided by an over-arching > >infrastructure > >>>>>>> team, in conjunction with the OpenJDK masters. OpenJFX can't > >work > >>>>>>> independent of this. > >>>>>>> > >>>>>>> -- Jonathan > >>>>>>> > >>>>>>> On 18/03/2015 10:50 a.m., Florian Brunner wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> AFAIK there is/ was a mirror of OpenJFX at BitBucket. > >>>>>>>> > >>>>>>>> I think the URL was https://bitbucket.org/openjfxmirrors, but > >it's > >>>>>>>> not valid > >>>>>>>> anymore. > >>>>>>>> > >>>>>>>> Is there still a mirror of OpenJFX at BitBucket? > >>>>>>>> > >>>>>>>> A fork/pull-request workflow is state-of-the-art nowadays in > >software > >>>>>>>> development and way better than a patch-file based workflow > >IMHO. > >>>>>>>> > >>>>>>>> It would be great to have such a fork/pull-request workflow > >also for > >>>>>>>> OpenJFX! > >>>>>>>> > >>>>>>>> -Florian > >>>> > >>>> > >> > -- Anirvan From dalibor.topic at oracle.com Wed Mar 18 05:31:42 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 18 Mar 2015 06:31:42 +0100 Subject: OpenJFX mirror at BitBucket? In-Reply-To: References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> Message-ID: <55090DBE.3090304@oracle.com> On 18.03.2015 01:03, Tomas Mikula wrote: > Legal issues could be resolved by requiring a signed OCA before each > pull request is merged. Or we could simply require changes to come in the way we do now and avoid having to deal with another set of side issues altogether. A development model where individual contributors work on their own individual changes, and then submit them separately is much easier to deal with for reviewers than one where some random things happen on bitbucket, someone after a while sends in a random pull request and then you have to spend weeks sorting out who contributed to the files in the pull request, how to contact them, if they are covered under the OCA, etc. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From hastebrot at gmail.com Wed Mar 18 05:50:45 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 18 Mar 2015 06:50:45 +0100 Subject: OpenJFX mirror at BitBucket? In-Reply-To: <55090DBE.3090304@oracle.com> References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> <55090DBE.3090304@oracle.com> Message-ID: >then you have to spend weeks sorting out who contributed to the files in the pull request Is it common to have multiple authors for a single pull request? >how to contact them, if they are covered under the OCA Google [1] (googlebot), Mozilla [2] (rust-highfive robot) and Microsoft [3] (msftclas bot) solve this issue, by using automatic bots that welcome the contributors and keep an list of already signed CLAs. [1] https://github.com/Polymer/polymer/pull/1247#issuecomment-76956855 [2] https://github.com/rust-lang/rust/pull/23466#issuecomment-82750848 [3] https://github.com/Microsoft/TypeScript/pull/2376 Regards, Benjamin On Wed, Mar 18, 2015 at 6:31 AM, dalibor topic wrote: > On 18.03.2015 01:03, Tomas Mikula wrote: > >> Legal issues could be resolved by requiring a signed OCA before each >> pull request is merged. >> > > Or we could simply require changes to come in the way we do now and avoid > having to deal with another set of side issues altogether. > > A development model where individual contributors work on their own > individual changes, and then submit them separately is much easier to deal > with for reviewers than one where some random things happen on bitbucket, > someone after a while sends in a random pull request and then you have to > spend weeks sorting out who contributed to the files in the pull request, > how to contact them, if they are covered under the OCA, etc. > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From dalibor.topic at oracle.com Wed Mar 18 07:01:05 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 18 Mar 2015 08:01:05 +0100 Subject: OpenJFX mirror at BitBucket? In-Reply-To: References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> <55090DBE.3090304@oracle.com> Message-ID: <550922B1.9090709@oracle.com> On 18.03.2015 06:50, Benjamin Gudehus wrote: > >then you have to spend weeks sorting out who contributed to the files > in the pull request > > Is it common to have multiple authors for a single pull request? It's fairly easy to create scenarios with multiple authors: A forks away, patches, B forks from A, patches again and submits some sort of 'pull request' to the mailing list incorporating both change sets. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From hastebrot at gmail.com Wed Mar 18 07:24:33 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 18 Mar 2015 08:24:33 +0100 Subject: OpenJFX mirror at BitBucket? In-Reply-To: <550922B1.9090709@oracle.com> References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> <55090DBE.3090304@oracle.com> <550922B1.9090709@oracle.com> Message-ID: Ah I see, that's reasonable. Using patch files sounds like the change sets will be really scattered. I first thought about an "official" Bitbucket mirror that acts as a gate and only accepts small pull requests where every author identified by his/her email address has accepted the OCA/CLA. There also is a synchronization between the main repository and the mirror, where the default branch is merged between both. I don't know if this is feasible, sounds like a lot of coordination work, e.g. the people from Node.js and its fork io.js have some problems with coordination between both repositories. On 3/18/15, dalibor topic wrote: > On 18.03.2015 06:50, Benjamin Gudehus wrote: >> >then you have to spend weeks sorting out who contributed to the files >> in the pull request >> >> Is it common to have multiple authors for a single pull request? > > It's fairly easy to create scenarios with multiple authors: > > A forks away, patches, B forks from A, patches again and submits some > sort of 'pull request' to the mailing list incorporating both change sets. > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From hastebrot at gmail.com Wed Mar 18 07:52:17 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 18 Mar 2015 08:52:17 +0100 Subject: OpenJFX mirror at BitBucket? In-Reply-To: References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> <55090DBE.3090304@oracle.com> <550922B1.9090709@oracle.com> Message-ID: Maybe a crazy idea: If we have a main repository and a Bitbucket mirror, we could add a hook on every commit to the main repository that replicates the commits to the mirror. If someone opens a pull request a reviewer (with commit rights to the main repository) can review the pull and comment with "r+" (review positive), then a bot will check if the pull is mergeable to the main repository and runs the complete tests suite. If the pull is not mergeable the bot will try to automatically merge changes to the default branch from the main repository into the PRs branch. If the merge or tests fail the bot will add a comment to the PR. Mozilla Rust's bot "bors" is an example for a bot that works in a similar way in practice. With ~50 merged commits last week [1]. There is a recent article (yesterday) that writes about bors "successor" [2]. Unfortunately bors is written with Git in mind. There is also a viewable queue for the pull request auto-merge bot at [3]. [1] https://github.com/bors [2] http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrastructure/ [3] http://buildbot.rust-lang.org/bors/bors.html On 3/18/15, Benjamin Gudehus wrote: > Ah I see, that's reasonable. > > Using patch files sounds like the change sets will be really > scattered. I first thought about an "official" Bitbucket mirror that > acts as a gate and only accepts small pull requests where every author > identified by his/her email address has accepted the OCA/CLA. There > also is a synchronization between the main repository and the mirror, > where the default branch is merged between both. I don't know if this > is feasible, sounds like a lot of coordination work, e.g. the people > from Node.js and its fork io.js have some problems with coordination > between both repositories. > > > > > > On 3/18/15, dalibor topic wrote: >> On 18.03.2015 06:50, Benjamin Gudehus wrote: >>> >then you have to spend weeks sorting out who contributed to the files >>> in the pull request >>> >>> Is it common to have multiple authors for a single pull request? >> >> It's fairly easy to create scenarios with multiple authors: >> >> A forks away, patches, B forks from A, patches again and submits some >> sort of 'pull request' to the mailing list incorporating both change >> sets. >> >> cheers, >> dalibor topic >> -- >> Dalibor Topic | Principal Product Manager >> Phone: +494089091214 | Mobile: +491737185961 >> >> >> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> Gesch?ftsf?hrer: J?rgen Kunz >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher >> >> Oracle is committed to developing >> practices and products that help protect the environment >> > From dalibor.topic at oracle.com Wed Mar 18 08:03:49 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 18 Mar 2015 09:03:49 +0100 Subject: OpenJFX mirror at BitBucket? In-Reply-To: References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> <55090DBE.3090304@oracle.com> <550922B1.9090709@oracle.com> Message-ID: <55093165.1060906@oracle.com> On 18.03.2015 08:24, Benjamin Gudehus wrote: > I don't know if this > is feasible, sounds like a lot of coordination work, e.g. the people > from Node.js and its fork io.js have some problems with coordination > between both repositories. Typically, even in the 'friendly fork' scenario, such setups don't work out very well over the long term, as the work required by actual humans to coordinate between different repositories accumulating changes at a different pace, in conjunction with internal interface drift, leads to the problem that the relative 'payoff' for the humans putting that work in tends to go towards zero over time as differences tend to increase, rather than decrease. You have to consider the feasibility of doing something once separately from the viability of doing something over and over again, and having to deal with more than one way to do it over and over again. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From kevin.rushforth at oracle.com Wed Mar 18 18:38:55 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Mar 2015 11:38:55 -0700 Subject: OpenJFX mirror at BitBucket? In-Reply-To: References: <4448565.lx0cmW0kx3@andor> <5508A2E7.3000809@oracle.com> <5508A459.7060906@oracle.com> <44586436.hfhyBupV1v@andor> <5508A921.2000503@oracle.com> <5508C250.1060709@oracle.com> Message-ID: <5509C63F.3050409@oracle.com> I will change the Wiki then. I wasn't even aware that this was on the Wiki, and we never have worked out what it would mean to accept a contribution via a pull request. -- Kevin Anirvan Sarkar wrote: > Looks like the page > https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow is > outdated. > > It links to the BitBucket repo and mentions that one of the ways to provide > a patch is to create a pull request on BitBucket. > > On 18 March 2015 at 05:51, Jonathan Giles wrote: > > >> Correct. >> -- Jonathan >> >> On 18 March 2015 13:19:21 GMT+13:00, Tomas Mikula >> wrote: >> >>> But we still need this one-way mirror, from which users can fork, >>> right? My assumption is that bitbucket will not keep track of how much >>> you diverged from the OpenJDK repo you initially cloned. It will, >>> however, tell you how much you diverged from a bitbucket repo that you >>> forked. >>> >>> On Tue, Mar 17, 2015 at 8:09 PM, Jonathan Giles >>> wrote: >>> >>>> BitBucket supports generation of patches from pull requests. My >>>> >>> suggestion >>> >>>> was that community members who wanted to use BitBucket to collaborate >>>> >>> and / >>> >>>> or easily keep their work current with the repo could do so, and when >>>> >>> they >>> >>>> create their pull request, they can have bitbucket generate the patch >>>> >>> file >>> >>>> for submission 'the old fashioned way'. >>>> >>>> -- Jonathan >>>> >>>> On 18/03/2015 1:03 p.m., Tomas Mikula wrote: >>>> >>>>> Legal issues could be resolved by requiring a signed OCA before each >>>>> pull request is merged. But anyway, if OpenJDK project does not >>>>> >>> accept >>> >>>>> pull requests, who is going to create the patches? If patches are >>>>> painful for individual developers, they are going to be super >>>>> >>> painful >>> >>>>> for the person who is supposed to get the accepted PRs back to >>>>> OpenJDK. >>>>> >>>>> OTOH, one-way mirrors should be easy enough to maintain by anyone >>>>> >>> who >>> >>>>> has access to a server where they can set up a cron task to >>>>> periodically pull from OpenJDK repos and push to bitbucket repos. >>>>> Whoever forks the mirror and makes changes would still have to >>>>> >>> submit >>> >>>>> patches directly to OpenJDK. >>>>> >>>>> Tomas >>>>> >>>>> On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles >>>>> wrote: >>>>> >>>>>> There is no issue with members of the community using BitBucket to >>>>>> develop >>>>>> their patches. I just don't think it is a wise use of our limited >>>>>> >>> time to >>> >>>>>> maintain a mirror. This seems something that interested community >>>>>> >>> members >>> >>>>>> can do if they want. The main issue is as Kevin mentioned - someone >>>>>> >>> has >>> >>>>>> to >>>>>> submit the patch officially, and that someone has to have signed an >>>>>> >>> OCA >>> >>>>>> stating that they are owners of the code and IP being submitted. It >>>>>> >>> would >>> >>>>>> pay to very carefully track who has contributed code to a certain >>>>>> >>> patch >>> >>>>>> file, as all contributors will need to have signed an OCA. >>>>>> >>>>>> -- Jonathan >>>>>> >>>>>> >>>>>> On 18/03/2015 11:12 a.m., Florian Brunner wrote: >>>>>> >>>>>>> Wouldn't it be possible for the OpenJFX team to officially >>>>>>> >>> maintain a >>> >>>>>>> mirror at >>>>>>> BitBucket themselves and use the same criteria for accepting a >>>>>>> pull-request as >>>>>>> for accepting a patch-file? Then you're sure that you can >>>>>>> >>> synchronize it >>> >>>>>>> with >>>>>>> the main repositories without any legal or quality issues. >>>>>>> >>>>>>> The contributors could link their forks and pull-requests in JIRA >>>>>>> >>> for >>> >>>>>>> documentation purposes. >>>>>>> >>>>>>> It would really be great if we could move on with this. >>>>>>> >>>>>>> -Florian >>>>>>> >>>>>>> Am Dienstag, 17. M?rz 2015, 15.02:01 schrieb Kevin Rushforth: >>>>>>> >>>>>>>> Right. If you wanted to revive the unofficial OpenJFX bitbucket >>>>>>>> >>> mirror >>> >>>>>>>> for your own experiments, that is certainly something you could >>>>>>>> >>> do >>> >>>>>>>> (subject to the GPLv2 + CLASSPATH license terms). >>>>>>>> >>>>>>>> For those patches to then be incorporated into the openjfx repos >>>>>>>> >>> on >>> >>>>>>>> hg.openjdk.java.net they need to go through the existing openjdk >>>>>>>> mechanism (which requires a signed OCA) as patches / webrevs, >>>>>>>> >>> just like >>> >>>>>>>> any other openjdk project. We cannot take patches directly from a >>>>>>>> BitBucket repo. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> Jonathan Giles wrote: >>>>>>>> >>>>>>>>> There was a mirror, but it was unofficial and one-way (OpenJDK >>>>>>>>> >>> -> >>> >>>>>>>>> BitBucket). I believe (although my memory may be failing me) >>>>>>>>> >>> that it >>> >>>>>>>>> was operated by Danno, so he might have more to say. >>>>>>>>> >>>>>>>>> In regards to fork / pull-request vs patch-file, I have no >>>>>>>>> >>> arguments >>> >>>>>>>>> there. Of course, OpenJFX is part of the OpenJDK, and therefore >>>>>>>>> >>> makes >>> >>>>>>>>> use of the OpenJDK infrastructure. My main point is that any >>>>>>>>> >>> movement >>> >>>>>>>>> regarding infrastructure is guided by an over-arching >>>>>>>>> >>> infrastructure >>> >>>>>>>>> team, in conjunction with the OpenJDK masters. OpenJFX can't >>>>>>>>> >>> work >>> >>>>>>>>> independent of this. >>>>>>>>> >>>>>>>>> -- Jonathan >>>>>>>>> >>>>>>>>> On 18/03/2015 10:50 a.m., Florian Brunner wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> AFAIK there is/ was a mirror of OpenJFX at BitBucket. >>>>>>>>>> >>>>>>>>>> I think the URL was https://bitbucket.org/openjfxmirrors, but >>>>>>>>>> >>> it's >>> >>>>>>>>>> not valid >>>>>>>>>> anymore. >>>>>>>>>> >>>>>>>>>> Is there still a mirror of OpenJFX at BitBucket? >>>>>>>>>> >>>>>>>>>> A fork/pull-request workflow is state-of-the-art nowadays in >>>>>>>>>> >>> software >>> >>>>>>>>>> development and way better than a patch-file based workflow >>>>>>>>>> >>> IMHO. >>> >>>>>>>>>> It would be great to have such a fork/pull-request workflow >>>>>>>>>> >>> also for >>> >>>>>>>>>> OpenJFX! >>>>>>>>>> >>>>>>>>>> -Florian >>>>>>>>>> >>>>>> > > > > From c.keimel at emsw.de Thu Mar 19 08:53:32 2015 From: c.keimel at emsw.de (Keimel, Christoph) Date: Thu, 19 Mar 2015 08:53:32 +0000 Subject: Behavior of TitledPane concerning the ENTER key and focus Message-ID: <8FF6D5A0093A1041873F086CCB503A2D4E858C07@EM08VMSX.emsw.local> Hello I would like to address two difficulties we are having with TitledPane: - TitledPaneBehavior sets up a KeyBinding for ENTER to trigger the TitledPane to toggle its expanded property. (Issue A) - TitledPane accepts the focus even when is not collapsible (Issue B) *** Why I would like to change this *** The main issue with (A) is that TitledPane and default buttons don?t work well together. Regardless of where the default button is in the scene, it can?t be fired by pressing ENTER anymore as soon as the focus is on any control which is a descendent of a TitledPane. A similar bug has been reported concerning the ComboBox [1]. We are currently migrating a government application to JavaFX (on Windows). The user interface layout has been designed with the tool wxDesigner. These declarative ui design files are currently transformed to FXML on the fly and then loaded. (Once the migration is complete SceneBuilder will be used to work on FXML directly). So we have no control over the layout of the ui. The designers really like to use the windows group box to create labeled sections inside of their (potentially very large and complex) forms to give them a better structure (recommended by the accessibility guidelines). The closest thing to the group box concept in JavaFX is the TitledPane. The designers also like to have a default button in every window (a soft requirement of the accessibility guidelines). Since almost all input controls are somehow a descendent of a TitledPane (which are even nested sometimes) the default button is effectively not accessible with ENTER during input. This will be treated as a Regression by our customer, so we somehow have to make it work. The fact that TitledPane accepts the focus even when it is not collapsible (B) is a different, minor issue. The problem here is that the focus is not visible when it is on the TitledPane, because the ?toggle button? of the TitledPane is not visible. This violates a soft requirement of the accessibility guidelines. [1]: [Default Button] Button set to default is not reacting ComboBox enter key - https://javafx-jira.kenai.com/browse/RT-34620 *** My technical understanding of A *** The ENTER key is registered as a KeyBinding to toggle the expanded property of TitledPane. The key biding is always set in the constructor of TitledPaneBehavior independent of the properties of the TitledPane. If a key binding is registered for a KeyEvent, then this event will be consumed in the bubbling phase (independent of any action actually being executed). The default button registers an accelerator for ENTER with the Scene. The accelerator is activated for the KeyEvent ENTER when the event bubbling reaches the scene only if the event has not been consumed during event processing. *** Considerations to A *** Looking at it from an ?accessibility? point of view, one key binding is enough. TitledPane also registers the SPACE key to toggle its expanded state. This is consistent with other controls like Button, CheckBox, RadioBox. From my point of view, the small triangle on the top left corner of the TitledPane is pretty much like a button, so this makes sense. Do we need the additional ENTER key binding? Ok, let?s assume we do. In that case the KeyEvent for ENTER should only be consumed, if it is actually handled by the control (when the toggle is performed). This will only be the case if the TitledPane is collapsible and has the focus. Currently the KeyEvent is always consumed when it passes through TitledPane by the default implementation of BehaviourBase.callActionForEvent regardless of whether it actually triggers an action or not. *** Conclusion *** The direct approach to (A) could be to override BehaviourBase .callActionForEvent in TitledPaneBehaviour to customize the event consummation. A general approach might be to extend the API of BehaviourBase, so that events are not necessarily consumed when the key binding does not really fire an action. I see that there is some reconstruction underway in this area with RT-21598 [2]. But from my point of view the simplest thing to do would be to drop the key binding for ENTER in TitledPane all together, which I would like to hereby propose (Solution A-II). To fix the minor issue of the hidden focus (B) it should be enough to bind the TitledPane.focusTraversableProperty to TitledPane.collapsibleProperty. [2]: Move BehaviorBase into public API - https://javafx-jira.kenai.com/browse/RT-21598 *** Next steps *** I am unsure of the next steps to take. Does it make sense to create issues for A and B? (Sorry for creating RT-40166 [3] prematurely.) Does it make sense to start to work on these issues, or will this be resolved in the course of the work on RT-21598 [2]? [3]: https://javafx-jira.kenai.com/browse/RT-40166 *** Workaround *** In the meantime I am using a workaround to customize all TitledPanes after loading the FXML which above. The code can be viewed here: TitledPaneCustomizer [4] With a small test case here: TitledPaneTest [5] [4]: https://github.com/ckeimel/fx-utils/blob/master/de.emsw.fx/src/de/emsw/fx/customizer/TitledPaneCustomizer.java [5]: https://github.com/ckeimel/fx-utils/blob/master/de.emsw.fx/test/test/de/emsw/fx/customizer/TitledPaneTest.java Thanks for your attention. Cheers, Christoph -- Christoph Keimel EM-SOFTWARE GmbH Oskar-Messter-Stra?e 29 85737 Ismaning Tel: 089 / 996547-26 Fax: 089 / 996547-99 Internet: http://www.emsw.de E-Mail: c.keimel at emsw.de Gesch?ftsf?hrer: Dipl.-Inf. (FH) Georg Engl UST-Id-Nr.: DE 131 175 644, HRB 80271 M?nchen From leif.samuelsson at oracle.com Thu Mar 19 16:48:57 2015 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Thu, 19 Mar 2015 09:48:57 -0700 Subject: [8u] Review request: RT-40280 Refactor duplicated editor code in ComboBox and DatePicker skins. Message-ID: <550AFDF9.6080105@oracle.com> Hi Jonathan, Please review this fix involving skins based on ComboBoListViewSkin. https://javafx-jira.kenai.com/browse/RT-40280 http://cr.openjdk.java.net/~leifs/rt40280/webrev.01/ Thanks, Leif From chien.yang at oracle.com Fri Mar 20 00:28:50 2015 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 19 Mar 2015 17:28:50 -0700 Subject: Code Review Request For RT-37862: [ScenePulseListener] NPE in synchronizeSceneProperties Message-ID: <550B69C2.8060704@oracle.com> Hi Kevin, Please review the proposed fix. JIRA: https://javafx-jira.kenai.com/browse/RT-37862 Thanks, - Chien From jonathan.giles at oracle.com Fri Mar 20 00:30:32 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 20 Mar 2015 13:30:32 +1300 Subject: Behavior of TitledPane concerning the ENTER key and focus In-Reply-To: <8FF6D5A0093A1041873F086CCB503A2D4E858C07@EM08VMSX.emsw.local> References: <8FF6D5A0093A1041873F086CCB503A2D4E858C07@EM08VMSX.emsw.local> Message-ID: <550B6A28.5060906@oracle.com> Hi Christoph, It would be best to repost this into the jira issue (RT-40166), so that all context is recorded there. If you do that we can carry on the discussion. In general, I agree with you - we should consider removing the ENTER key binding, so this should be considered further. -- Jonathan On 19/03/2015 9:53 p.m., Keimel, Christoph wrote: > Hello > > I would like to address two difficulties we are having with TitledPane: > - TitledPaneBehavior sets up a KeyBinding for ENTER to trigger the TitledPane to toggle its expanded property. (Issue A) > - TitledPane accepts the focus even when is not collapsible (Issue B) > > > *** Why I would like to change this *** > > The main issue with (A) is that TitledPane and default buttons don?t work well together. Regardless of where the default button is in the scene, it can?t be fired by pressing ENTER anymore as soon as the focus is on any control which is a descendent of a TitledPane. A similar bug has been reported concerning the ComboBox [1]. > > We are currently migrating a government application to JavaFX (on Windows). The user interface layout has been designed with the tool wxDesigner. These declarative ui design files are currently transformed to FXML on the fly and then loaded. (Once the migration is complete SceneBuilder will be used to work on FXML directly). So we have no control over the layout of the ui. The designers really like to use the windows group box to create labeled sections inside of their (potentially very large and complex) forms to give them a better structure (recommended by the accessibility guidelines). The closest thing to the group box concept in JavaFX is the TitledPane. > > The designers also like to have a default button in every window (a soft requirement of the accessibility guidelines). Since almost all input controls are somehow a descendent of a TitledPane (which are even nested sometimes) the default button is effectively not accessible with ENTER during input. This will be treated as a Regression by our customer, so we somehow have to make it work. > > The fact that TitledPane accepts the focus even when it is not collapsible (B) is a different, minor issue. The problem here is that the focus is not visible when it is on the TitledPane, because the ?toggle button? of the TitledPane is not visible. This violates a soft requirement of the accessibility guidelines. > > [1]: [Default Button] Button set to default is not reacting ComboBox enter key - https://javafx-jira.kenai.com/browse/RT-34620 > > > *** My technical understanding of A *** > > The ENTER key is registered as a KeyBinding to toggle the expanded property of TitledPane. The key biding is always set in the constructor of TitledPaneBehavior independent of the properties of the TitledPane. If a key binding is registered for a KeyEvent, then this event will be consumed in the bubbling phase (independent of any action actually being executed). > > The default button registers an accelerator for ENTER with the Scene. The accelerator is activated for the KeyEvent ENTER when the event bubbling reaches the scene only if the event has not been consumed during event processing. > > > *** Considerations to A *** > > Looking at it from an ?accessibility? point of view, one key binding is enough. TitledPane also registers the SPACE key to toggle its expanded state. This is consistent with other controls like Button, CheckBox, RadioBox. From my point of view, the small triangle on the top left corner of the TitledPane is pretty much like a button, so this makes sense. Do we need the additional ENTER key binding? > > Ok, let?s assume we do. In that case the KeyEvent for ENTER should only be consumed, if it is actually handled by the control (when the toggle is performed). This will only be the case if the TitledPane is collapsible and has the focus. Currently the KeyEvent is always consumed when it passes through TitledPane by the default implementation of BehaviourBase.callActionForEvent regardless of whether it actually triggers an action or not. > > > *** Conclusion *** > > The direct approach to (A) could be to override BehaviourBase .callActionForEvent in TitledPaneBehaviour to customize the event consummation. A general approach might be to extend the API of BehaviourBase, so that events are not necessarily consumed when the key binding does not really fire an action. I see that there is some reconstruction underway in this area with RT-21598 [2]. > > But from my point of view the simplest thing to do would be to drop the key binding for ENTER in TitledPane all together, which I would like to hereby propose (Solution A-II). > > To fix the minor issue of the hidden focus (B) it should be enough to bind the TitledPane.focusTraversableProperty to TitledPane.collapsibleProperty. > > [2]: Move BehaviorBase into public API - https://javafx-jira.kenai.com/browse/RT-21598 > > > *** Next steps *** > > I am unsure of the next steps to take. Does it make sense to create issues for A and B? (Sorry for creating RT-40166 [3] prematurely.) > > Does it make sense to start to work on these issues, or will this be resolved in the course of the work on RT-21598 [2]? > > [3]: https://javafx-jira.kenai.com/browse/RT-40166 > > > *** Workaround *** > > In the meantime I am using a workaround to customize all TitledPanes after loading the FXML which above. > > The code can be viewed here: TitledPaneCustomizer [4] > With a small test case here: TitledPaneTest [5] > > [4]: https://github.com/ckeimel/fx-utils/blob/master/de.emsw.fx/src/de/emsw/fx/customizer/TitledPaneCustomizer.java > [5]: https://github.com/ckeimel/fx-utils/blob/master/de.emsw.fx/test/test/de/emsw/fx/customizer/TitledPaneTest.java > > > Thanks for your attention. > > Cheers, > Christoph > -- > Christoph Keimel > EM-SOFTWARE GmbH > Oskar-Messter-Stra?e 29 > 85737 Ismaning > > Tel: 089 / 996547-26 > Fax: 089 / 996547-99 > Internet: http://www.emsw.de > E-Mail: c.keimel at emsw.de > > Gesch?ftsf?hrer: Dipl.-Inf. (FH) Georg Engl UST-Id-Nr.: DE 131 175 644, HRB 80271 M?nchen > From vadim.pakhnushev at oracle.com Fri Mar 20 14:30:32 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 20 Mar 2015 17:30:32 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <550C2F08.40800@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From hjohn at xs4all.nl Sat Mar 21 16:01:58 2015 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 21 Mar 2015 17:01:58 +0100 Subject: The trouble with Skins In-Reply-To: <5503E3CB.4070506@tbee.org> References: <5503E3CB.4070506@tbee.org> Message-ID: <550D95F6.5090706@xs4all.nl> On 14/03/2015 08:31, Tom Eugelink wrote: > Hi Tomas, > > I have looked into it, but not yet attempted, but I did do a lot of > custom controls. And I agree that it is dubious that a control is a > node, and has the properties that come with it. I try to maintain a > strict separation in my controls in JFXtras; controls only have > functional methods, the skin and CSS do all the layout. For example > the gauge I've ported from Enzo; my version does not have a > setFillColor() like the one in Enzo, that is something that the user > needs to do through CSS. > > That said, if a control were only a model, than it would not be a > control, right? We would create model-skins, so there is something > that differentiates a control from a model. To me that is an > abstraction of the skin. For example: not knowning HOW it is rendered, > a textbox does know that it can receive the focus, it is implicit to > what it is. So there is a certain logic for allowing controls to have > rudimentary rendering info, as long as it does not expose the actual > layout details. > > Looking at ListView, there is a logic in that a list can scroll, so > onScroll on the control makes sense. Whether that scrolling is done > via a scrollbar or buttons is a skin detail that should not leak out. > So the fact that ListView does not have a scroll position makes sense > to me. As someone that has been tempted to write a new Control that replaces ListView atleast half a dozen times now because of restrictions or idioms that don't match my needs, I'd disagree. A ListView doesn't need to scroll at all. An application that isn't mouse or touchscreen controlled (keyboard or remote controlled for example) has zero need for scrollbars except maybe as information to show the relative size of the view. A List of items could be paged only, or they could flip. I'd like to be able to take a List, and wrap it in a ScrollBarView... or in a PagerView, FlipOverView or CoverFlowView (with 30 new properties to set things like reflections, 3d parameters, distance between items, etc). It is possible to do this with Skins, but it feels like a hack rather than simply a different Look&Feel in the end. After all, a ListView is a container for an unbounded list of items. I can think of half a dozen ways of how that can be shown to the user, and the current ListView is just one way to do it. The promise of Skins here is that I could just change the look & feel, but unfortunately way too many details of the "default" look & feel leak through in the Control itself. --John > > Tom > > > On 14-3-2015 04:33, Tomas Mikula wrote: >> A quick poll: >> >> Has anyone ever implemented a custom skin for some of the more complex >> controls like ListView, TableView, TreeView, TextArea? >> >> The problem I have with the Control/Skin architecture is that a >> Control, being a Node in the scene graph, cannot be a pure model (in >> the MVC sense) - it is inherently a view (in the MVC sense). What is >> the model of a check box? For me, a model of a check box is a boolean >> property; certainly not something that has boundsInParent or >> onZoomFinished properties. CheckBox is hardly a model. It is a view. >> Everything in the scene graph is inherently a view. >> >> There is this idea that the view aspect of a control is implemented by >> the skin. The control itself does not know what the skin looks like or >> even what skin class is used. So a ListView knows about its items, but >> it does not know about its scroll position. But users sometimes want >> to know the scroll position. Why should there be onScrollProperty, but >> not way to get the current scroll position? Why should there be >> TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There >> is no good way to implement the latter methods using custom skins. The >> ListView or TextArea don't know anything about the skin, thus they >> don't know anything about the current scroll position or caret bounds. >> They cannot ask the skin, because there might be no skin yet, and even >> if there is, all they know about it is that it is an instance of >> Skin - not much one can do with it (certainly not get caret >> bounds). >> >> I'm leaning more and more towards not supporting custom skins at all. >> The whole idea of overriding skins via CSS looks to me like dependency >> injection via CSS, except without any possibility to constrain the >> type of what can be injected. >> >> I would like to know the community opinion on this. Even hear your >> success story how skins are awesome, if there is such. >> >> Regards, >> Tomas > From tbee at tbee.org Sat Mar 21 16:48:40 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 21 Mar 2015 17:48:40 +0100 Subject: The trouble with Skins In-Reply-To: <550D95F6.5090706@xs4all.nl> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> Message-ID: <550DA0E8.8020609@tbee.org> On 21-3-2015 17:01, John Hendrikx wrote: > On 14/03/2015 08:31, Tom Eugelink wrote: >> Hi Tomas, >> >> I have looked into it, but not yet attempted, but I did do a lot of custom controls. And I agree that it is dubious that a control is a node, and has the properties that come with it. I try to maintain a strict separation in my controls in JFXtras; controls only have functional methods, the skin and CSS do all the layout. For example the gauge I've ported from Enzo; my version does not have a setFillColor() like the one in Enzo, that is something that the user needs to do through CSS. >> >> That said, if a control were only a model, than it would not be a control, right? We would create model-skins, so there is something that differentiates a control from a model. To me that is an abstraction of the skin. For example: not knowning HOW it is rendered, a textbox does know that it can receive the focus, it is implicit to what it is. So there is a certain logic for allowing controls to have rudimentary rendering info, as long as it does not expose the actual layout details. >> >> Looking at ListView, there is a logic in that a list can scroll, so onScroll on the control makes sense. Whether that scrolling is done via a scrollbar or buttons is a skin detail that should not leak out. So the fact that ListView does not have a scroll position makes sense to me. > > As someone that has been tempted to write a new Control that replaces ListView atleast half a dozen times now because of restrictions or idioms that don't match my needs, I'd disagree. A ListView doesn't need to scroll at all. An application that isn't mouse or touchscreen controlled (keyboard or remote controlled for example) has zero need for scrollbars except maybe as information to show the relative size of the view. > > A List of items could be paged only, or they could flip. I'd like to be able to take a List, and wrap it in a ScrollBarView... or in a PagerView, FlipOverView or CoverFlowView (with 30 new properties to set things like reflections, 3d parameters, distance between items, etc). It is possible to do this with Skins, but it feels like a hack rather than simply a different Look&Feel in the end. > > After all, a ListView is a container for an unbounded list of items. I can think of half a dozen ways of how that can be shown to the user, and the current ListView is just one way to do it. The promise of Skins here is that I could just change the look & feel, but unfortunately way too many details of the "default" look & feel leak through in the Control itself. Maybe it is the definition of "scroll", because I don't think we have the same concept. For me scrolling means: moving certain items out of view and other into view. Now, that can be done by scrollbar and mouse, or touch and scrollbar, or by clicking on buttons or flip over a page. Basically a book does the same than a paper scroll; only in steps instead of fluent. So to me all these are just specific renderings of the scroll concept. One maybe could also have called it "onPaging". So yes, you are right, and I still think it is scrolling. Tom From tomas.mikula at gmail.com Sat Mar 21 17:47:15 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sat, 21 Mar 2015 13:47:15 -0400 Subject: The trouble with Skins In-Reply-To: <550D95F6.5090706@xs4all.nl> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> Message-ID: So Skins prevent us from getting visual details of the Control (such as scroll position, position of item on screen, ...), because it is Skin-specific, but at the same time they fail to customize the look & feel, because visual presentation leaks into the Control anyway. On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx wrote: > On 14/03/2015 08:31, Tom Eugelink wrote: >> >> Hi Tomas, >> >> I have looked into it, but not yet attempted, but I did do a lot of custom >> controls. And I agree that it is dubious that a control is a node, and has >> the properties that come with it. I try to maintain a strict separation in >> my controls in JFXtras; controls only have functional methods, the skin and >> CSS do all the layout. For example the gauge I've ported from Enzo; my >> version does not have a setFillColor() like the one in Enzo, that is >> something that the user needs to do through CSS. >> >> That said, if a control were only a model, than it would not be a control, >> right? We would create model-skins, so there is something that >> differentiates a control from a model. To me that is an abstraction of the >> skin. For example: not knowning HOW it is rendered, a textbox does know that >> it can receive the focus, it is implicit to what it is. So there is a >> certain logic for allowing controls to have rudimentary rendering info, as >> long as it does not expose the actual layout details. >> >> Looking at ListView, there is a logic in that a list can scroll, so >> onScroll on the control makes sense. Whether that scrolling is done via a >> scrollbar or buttons is a skin detail that should not leak out. So the fact >> that ListView does not have a scroll position makes sense to me. > > > As someone that has been tempted to write a new Control that replaces > ListView atleast half a dozen times now because of restrictions or idioms > that don't match my needs, I'd disagree. A ListView doesn't need to scroll > at all. An application that isn't mouse or touchscreen controlled (keyboard > or remote controlled for example) has zero need for scrollbars except maybe > as information to show the relative size of the view. > > A List of items could be paged only, or they could flip. I'd like to be > able to take a List, and wrap it in a ScrollBarView... or in a PagerView, > FlipOverView or CoverFlowView (with 30 new properties to set things like > reflections, 3d parameters, distance between items, etc). It is possible > to do this with Skins, but it feels like a hack rather than simply a > different Look&Feel in the end. > > After all, a ListView is a container for an unbounded list of items. I can > think of half a dozen ways of how that can be shown to the user, and the > current ListView is just one way to do it. The promise of Skins here is > that I could just change the look & feel, but unfortunately way too many > details of the "default" look & feel leak through in the Control itself. > > --John > >> >> Tom >> >> >> On 14-3-2015 04:33, Tomas Mikula wrote: >>> >>> A quick poll: >>> >>> Has anyone ever implemented a custom skin for some of the more complex >>> controls like ListView, TableView, TreeView, TextArea? >>> >>> The problem I have with the Control/Skin architecture is that a >>> Control, being a Node in the scene graph, cannot be a pure model (in >>> the MVC sense) - it is inherently a view (in the MVC sense). What is >>> the model of a check box? For me, a model of a check box is a boolean >>> property; certainly not something that has boundsInParent or >>> onZoomFinished properties. CheckBox is hardly a model. It is a view. >>> Everything in the scene graph is inherently a view. >>> >>> There is this idea that the view aspect of a control is implemented by >>> the skin. The control itself does not know what the skin looks like or >>> even what skin class is used. So a ListView knows about its items, but >>> it does not know about its scroll position. But users sometimes want >>> to know the scroll position. Why should there be onScrollProperty, but >>> not way to get the current scroll position? Why should there be >>> TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There >>> is no good way to implement the latter methods using custom skins. The >>> ListView or TextArea don't know anything about the skin, thus they >>> don't know anything about the current scroll position or caret bounds. >>> They cannot ask the skin, because there might be no skin yet, and even >>> if there is, all they know about it is that it is an instance of >>> Skin - not much one can do with it (certainly not get caret >>> bounds). >>> >>> I'm leaning more and more towards not supporting custom skins at all. >>> The whole idea of overriding skins via CSS looks to me like dependency >>> injection via CSS, except without any possibility to constrain the >>> type of what can be injected. >>> >>> I would like to know the community opinion on this. Even hear your >>> success story how skins are awesome, if there is such. >>> >>> Regards, >>> Tomas >> >> > From tbee at tbee.org Sat Mar 21 18:10:48 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 21 Mar 2015 19:10:48 +0100 Subject: The trouble with Skins In-Reply-To: References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> Message-ID: <550DB428.1070601@tbee.org> I don't understanding how you see that. On 21-3-2015 18:47, Tomas Mikula wrote: > So Skins prevent us from getting visual details of the Control (such > as scroll position, position of item on screen, ...), because it is > Skin-specific, but at the same time they fail to customize the look & > feel, because visual presentation leaks into the Control anyway. > > On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx wrote: >> On 14/03/2015 08:31, Tom Eugelink wrote: >>> Hi Tomas, >>> >>> I have looked into it, but not yet attempted, but I did do a lot of custom >>> controls. And I agree that it is dubious that a control is a node, and has >>> the properties that come with it. I try to maintain a strict separation in >>> my controls in JFXtras; controls only have functional methods, the skin and >>> CSS do all the layout. For example the gauge I've ported from Enzo; my >>> version does not have a setFillColor() like the one in Enzo, that is >>> something that the user needs to do through CSS. >>> >>> That said, if a control were only a model, than it would not be a control, >>> right? We would create model-skins, so there is something that >>> differentiates a control from a model. To me that is an abstraction of the >>> skin. For example: not knowning HOW it is rendered, a textbox does know that >>> it can receive the focus, it is implicit to what it is. So there is a >>> certain logic for allowing controls to have rudimentary rendering info, as >>> long as it does not expose the actual layout details. >>> >>> Looking at ListView, there is a logic in that a list can scroll, so >>> onScroll on the control makes sense. Whether that scrolling is done via a >>> scrollbar or buttons is a skin detail that should not leak out. So the fact >>> that ListView does not have a scroll position makes sense to me. >> >> As someone that has been tempted to write a new Control that replaces >> ListView atleast half a dozen times now because of restrictions or idioms >> that don't match my needs, I'd disagree. A ListView doesn't need to scroll >> at all. An application that isn't mouse or touchscreen controlled (keyboard >> or remote controlled for example) has zero need for scrollbars except maybe >> as information to show the relative size of the view. >> >> A List of items could be paged only, or they could flip. I'd like to be >> able to take a List, and wrap it in a ScrollBarView... or in a PagerView, >> FlipOverView or CoverFlowView (with 30 new properties to set things like >> reflections, 3d parameters, distance between items, etc). It is possible >> to do this with Skins, but it feels like a hack rather than simply a >> different Look&Feel in the end. >> >> After all, a ListView is a container for an unbounded list of items. I can >> think of half a dozen ways of how that can be shown to the user, and the >> current ListView is just one way to do it. The promise of Skins here is >> that I could just change the look & feel, but unfortunately way too many >> details of the "default" look & feel leak through in the Control itself. >> >> --John >> >>> Tom >>> >>> >>> On 14-3-2015 04:33, Tomas Mikula wrote: >>>> A quick poll: >>>> >>>> Has anyone ever implemented a custom skin for some of the more complex >>>> controls like ListView, TableView, TreeView, TextArea? >>>> >>>> The problem I have with the Control/Skin architecture is that a >>>> Control, being a Node in the scene graph, cannot be a pure model (in >>>> the MVC sense) - it is inherently a view (in the MVC sense). What is >>>> the model of a check box? For me, a model of a check box is a boolean >>>> property; certainly not something that has boundsInParent or >>>> onZoomFinished properties. CheckBox is hardly a model. It is a view. >>>> Everything in the scene graph is inherently a view. >>>> >>>> There is this idea that the view aspect of a control is implemented by >>>> the skin. The control itself does not know what the skin looks like or >>>> even what skin class is used. So a ListView knows about its items, but >>>> it does not know about its scroll position. But users sometimes want >>>> to know the scroll position. Why should there be onScrollProperty, but >>>> not way to get the current scroll position? Why should there be >>>> TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There >>>> is no good way to implement the latter methods using custom skins. The >>>> ListView or TextArea don't know anything about the skin, thus they >>>> don't know anything about the current scroll position or caret bounds. >>>> They cannot ask the skin, because there might be no skin yet, and even >>>> if there is, all they know about it is that it is an instance of >>>> Skin - not much one can do with it (certainly not get caret >>>> bounds). >>>> >>>> I'm leaning more and more towards not supporting custom skins at all. >>>> The whole idea of overriding skins via CSS looks to me like dependency >>>> injection via CSS, except without any possibility to constrain the >>>> type of what can be injected. >>>> >>>> I would like to know the community opinion on this. Even hear your >>>> success story how skins are awesome, if there is such. >>>> >>>> Regards, >>>> Tomas >>> From tomas.mikula at gmail.com Sat Mar 21 18:20:29 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sat, 21 Mar 2015 14:20:29 -0400 Subject: The trouble with Skins In-Reply-To: <550DB428.1070601@tbee.org> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DB428.1070601@tbee.org> Message-ID: On Sat, Mar 21, 2015 at 2:10 PM, Tom Eugelink wrote: > I don't understanding how you see that. > > > > On 21-3-2015 18:47, Tomas Mikula wrote: >> >> So Skins prevent us from getting visual details of the Control (such >> as scroll position, position of item on screen, ...), because it is >> Skin-specific, I suppose this part is clear? >> but at the same time they fail to customize the look & >> feel, because visual presentation leaks into the Control anyway. This is a summary of John's email. Tomas >> >> On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx wrote: >>> >>> On 14/03/2015 08:31, Tom Eugelink wrote: >>>> >>>> Hi Tomas, >>>> >>>> I have looked into it, but not yet attempted, but I did do a lot of >>>> custom >>>> controls. And I agree that it is dubious that a control is a node, and >>>> has >>>> the properties that come with it. I try to maintain a strict separation >>>> in >>>> my controls in JFXtras; controls only have functional methods, the skin >>>> and >>>> CSS do all the layout. For example the gauge I've ported from Enzo; my >>>> version does not have a setFillColor() like the one in Enzo, that is >>>> something that the user needs to do through CSS. >>>> >>>> That said, if a control were only a model, than it would not be a >>>> control, >>>> right? We would create model-skins, so there is something that >>>> differentiates a control from a model. To me that is an abstraction of >>>> the >>>> skin. For example: not knowning HOW it is rendered, a textbox does know >>>> that >>>> it can receive the focus, it is implicit to what it is. So there is a >>>> certain logic for allowing controls to have rudimentary rendering info, >>>> as >>>> long as it does not expose the actual layout details. >>>> >>>> Looking at ListView, there is a logic in that a list can scroll, so >>>> onScroll on the control makes sense. Whether that scrolling is done via >>>> a >>>> scrollbar or buttons is a skin detail that should not leak out. So the >>>> fact >>>> that ListView does not have a scroll position makes sense to me. >>> >>> >>> As someone that has been tempted to write a new Control that replaces >>> ListView atleast half a dozen times now because of restrictions or idioms >>> that don't match my needs, I'd disagree. A ListView doesn't need to >>> scroll >>> at all. An application that isn't mouse or touchscreen controlled >>> (keyboard >>> or remote controlled for example) has zero need for scrollbars except >>> maybe >>> as information to show the relative size of the view. >>> >>> A List of items could be paged only, or they could flip. I'd like to be >>> able to take a List, and wrap it in a ScrollBarView... or in a PagerView, >>> FlipOverView or CoverFlowView (with 30 new properties to set things like >>> reflections, 3d parameters, distance between items, etc). It is >>> possible >>> to do this with Skins, but it feels like a hack rather than simply a >>> different Look&Feel in the end. >>> >>> After all, a ListView is a container for an unbounded list of items. I >>> can >>> think of half a dozen ways of how that can be shown to the user, and the >>> current ListView is just one way to do it. The promise of Skins here is >>> that I could just change the look & feel, but unfortunately way too many >>> details of the "default" look & feel leak through in the Control itself. >>> >>> --John >>> >>>> Tom >>>> >>>> >>>> On 14-3-2015 04:33, Tomas Mikula wrote: >>>>> >>>>> A quick poll: >>>>> >>>>> Has anyone ever implemented a custom skin for some of the more complex >>>>> controls like ListView, TableView, TreeView, TextArea? >>>>> >>>>> The problem I have with the Control/Skin architecture is that a >>>>> Control, being a Node in the scene graph, cannot be a pure model (in >>>>> the MVC sense) - it is inherently a view (in the MVC sense). What is >>>>> the model of a check box? For me, a model of a check box is a boolean >>>>> property; certainly not something that has boundsInParent or >>>>> onZoomFinished properties. CheckBox is hardly a model. It is a view. >>>>> Everything in the scene graph is inherently a view. >>>>> >>>>> There is this idea that the view aspect of a control is implemented by >>>>> the skin. The control itself does not know what the skin looks like or >>>>> even what skin class is used. So a ListView knows about its items, but >>>>> it does not know about its scroll position. But users sometimes want >>>>> to know the scroll position. Why should there be onScrollProperty, but >>>>> not way to get the current scroll position? Why should there be >>>>> TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There >>>>> is no good way to implement the latter methods using custom skins. The >>>>> ListView or TextArea don't know anything about the skin, thus they >>>>> don't know anything about the current scroll position or caret bounds. >>>>> They cannot ask the skin, because there might be no skin yet, and even >>>>> if there is, all they know about it is that it is an instance of >>>>> Skin - not much one can do with it (certainly not get caret >>>>> bounds). >>>>> >>>>> I'm leaning more and more towards not supporting custom skins at all. >>>>> The whole idea of overriding skins via CSS looks to me like dependency >>>>> injection via CSS, except without any possibility to constrain the >>>>> type of what can be injected. >>>>> >>>>> I would like to know the community opinion on this. Even hear your >>>>> success story how skins are awesome, if there is such. >>>>> >>>>> Regards, >>>>> Tomas >>>> >>>> > From swpalmer at gmail.com Sat Mar 21 18:46:50 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 21 Mar 2015 14:46:50 -0400 Subject: The trouble with Skins In-Reply-To: <550D95F6.5090706@xs4all.nl> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> Message-ID: But that's not right. A *List* is 'a container for an unbounded list of items". A ListView is a specific type of control that gives you a view to that list *in a specific way*. It has properties in addition to the list itself. It *should* have a scroll position because that is a property of that kind of control - even though the skin will implement it. These controls are visible elements and must expose properties that will ultimately be implemented in the skin. They must be Nodes. Otherwise they will be far too cumbersome to use. You may not need to expose where the scroll bars are, or get access to arrow buttons, etc., but you should have access to what items are visible, what the scroll position is, etc. you should be able to change the scroll position programmatically without knowing the skin. A page based view is a different kind of control. It can still use a List model, but flipping to a page system from a scrollable list is not something I would expect when changing the look and feel. I might expect to have the view change from pixel-based scrolling to line based scrolling, or have up/down arrows at one end of the scroll bar instead of each end. Scott > On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx wrote: > > As someone that has been tempted to write a new Control that replaces ListView atleast half a dozen times now because of restrictions or idioms that don't match my needs, I'd disagree. A ListView doesn't need to scroll at all. An application that isn't mouse or touchscreen controlled (keyboard or remote controlled for example) has zero need for scrollbars except maybe as information to show the relative size of the view. > > A List of items could be paged only, or they could flip. I'd like to be able to take a List, and wrap it in a ScrollBarView... or in a PagerView, FlipOverView or CoverFlowView (with 30 new properties to set things like reflections, 3d parameters, distance between items, etc). It is possible to do this with Skins, but it feels like a hack rather than simply a different Look&Feel in the end. > > After all, a ListView is a container for an unbounded list of items. I can think of half a dozen ways of how that can be shown to the user, and the current ListView is just one way to do it. The promise of Skins here is that I could just change the look & feel, but unfortunately way too many details of the "default" look & feel leak through in the Control itself > > --John. From tbee at tbee.org Sat Mar 21 18:53:02 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 21 Mar 2015 19:53:02 +0100 Subject: The trouble with Skins In-Reply-To: References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> Message-ID: <550DBE0E.7090207@tbee.org> A page based view can perfectly be a list view; I would have no problem having a paging skin or a scrollbar skin for ListView. On 21-3-2015 19:46, Scott Palmer wrote: > But that's not right. A *List* is 'a container for an unbounded list of items". A ListView is a specific type of control that gives you a view to that list *in a specific way*. It has properties in addition to the list itself. It *should* have a scroll position because that is a property of that kind of control - even though the skin will implement it. These controls are visible elements and must expose properties that will ultimately be implemented in the skin. They must be Nodes. Otherwise they will be far too cumbersome to use. > You may not need to expose where the scroll bars are, or get access to arrow buttons, etc., but you should have access to what items are visible, what the scroll position is, etc. you should be able to change the scroll position programmatically without knowing the skin. > > A page based view is a different kind of control. It can still use a List model, but flipping to a page system from a scrollable list is not something I would expect when changing the look and feel. I might expect to have the view change from pixel-based scrolling to line based scrolling, or have up/down arrows at one end of the scroll bar instead of each end. > > Scott > >> On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx wrote: >> >> As someone that has been tempted to write a new Control that replaces ListView atleast half a dozen times now because of restrictions or idioms that don't match my needs, I'd disagree. A ListView doesn't need to scroll at all. An application that isn't mouse or touchscreen controlled (keyboard or remote controlled for example) has zero need for scrollbars except maybe as information to show the relative size of the view. >> >> A List of items could be paged only, or they could flip. I'd like to be able to take a List, and wrap it in a ScrollBarView... or in a PagerView, FlipOverView or CoverFlowView (with 30 new properties to set things like reflections, 3d parameters, distance between items, etc). It is possible to do this with Skins, but it feels like a hack rather than simply a different Look&Feel in the end. >> >> After all, a ListView is a container for an unbounded list of items. I can think of half a dozen ways of how that can be shown to the user, and the current ListView is just one way to do it. The promise of Skins here is that I could just change the look & feel, but unfortunately way too many details of the "default" look & feel leak through in the Control itself >> >> --John. From swpalmer at gmail.com Sat Mar 21 19:32:11 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 21 Mar 2015 15:32:11 -0400 Subject: The trouble with Skins In-Reply-To: <550DBE0E.7090207@tbee.org> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> Message-ID: <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> My point is that there are many ways to display the same data set, but they shouldn't all be crammed into a single control type. Particularly one that changes radically based on the skin just because the data model can be represented by the same data structure. For a ListView it could still fit if it was a list that "scrolled" a page at a time, perhaps that was a bad example. I would still expect the control to be a Node and to have direct access via the control to the current "scroll" position. I would not expect a ListView to have a page-based API, nor would I expect to get access to such an API by accessing the Skin. The skin is an implementation detail that should remain distinct from how my program interacts with the control. Scott > On Mar 21, 2015, at 2:53 PM, Tom Eugelink wrote: > > A page based view can perfectly be a list view; I would have no problem having a paging skin or a scrollbar skin for ListView. > > > >> On 21-3-2015 19:46, Scott Palmer wrote: >> But that's not right. A *List* is 'a container for an unbounded list of items". A ListView is a specific type of control that gives you a view to that list *in a specific way*. It has properties in addition to the list itself. It *should* have a scroll position because that is a property of that kind of control - even though the skin will implement it. These controls are visible elements and must expose properties that will ultimately be implemented in the skin. They must be Nodes. Otherwise they will be far too cumbersome to use. >> You may not need to expose where the scroll bars are, or get access to arrow buttons, etc., but you should have access to what items are visible, what the scroll position is, etc. you should be able to change the scroll position programmatically without knowing the skin. >> >> A page based view is a different kind of control. It can still use a List model, but flipping to a page system from a scrollable list is not something I would expect when changing the look and feel. I might expect to have the view change from pixel-based scrolling to line based scrolling, or have up/down arrows at one end of the scroll bar instead of each end. >> >> Scott >> >>> On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx wrote: >>> >>> As someone that has been tempted to write a new Control that replaces ListView atleast half a dozen times now because of restrictions or idioms that don't match my needs, I'd disagree. A ListView doesn't need to scroll at all. An application that isn't mouse or touchscreen controlled (keyboard or remote controlled for example) has zero need for scrollbars except maybe as information to show the relative size of the view. >>> >>> A List of items could be paged only, or they could flip. I'd like to be able to take a List, and wrap it in a ScrollBarView... or in a PagerView, FlipOverView or CoverFlowView (with 30 new properties to set things like reflections, 3d parameters, distance between items, etc). It is possible to do this with Skins, but it feels like a hack rather than simply a different Look&Feel in the end. >>> >>> After all, a ListView is a container for an unbounded list of items. I can think of half a dozen ways of how that can be shown to the user, and the current ListView is just one way to do it. The promise of Skins here is that I could just change the look & feel, but unfortunately way too many details of the "default" look & feel leak through in the Control itself >>> >>> --John. > From hjohn at xs4all.nl Sat Mar 21 23:12:28 2015 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 22 Mar 2015 00:12:28 +0100 Subject: The trouble with Skins In-Reply-To: <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> Message-ID: <550DFADC.30304@xs4all.nl> For me, I'd like to simply change the Look and Feel and have the same data presented differently (perhaps related to space restrictions, orientation, user preferences). Currently, this can be achieved by changing the Control, or maybe only change the Skin, depending on how radical the transformation is. I'd like that to be the same thing for all these cases and have the same general API (show item X, get position, set position, go to first item, go to last item). If Skins aren't intended for that (despite being able to change the complete appearance and even change all the navigation handling), then fine -- we'll need to do it with Controls, and have "similar" controls all implement the same interface. ListView looked to me like a very close match, that just needs a small push to get what I want (re-implementing all the "virtual" cell logic is not something I want to do for every "skin"). It could be shown as pages easily (with a nice pager in the top right corner something). This does not affect the API. I can still call "show item X", or ask for it to give me an object that represents the current position (making it possible to restore it there later). I don't need to know it is page based, or even know the page number -- just like I don't need to know there are scrollbars or what the current scroll position is. What I do need however is a way to restore the control to the exact same state it was in before (the same amount of pixels scrolled, the same item at the top, the same item at the bottom). --John On 21/03/2015 20:32, Scott Palmer wrote: > My point is that there are many ways to display the same data set, but they shouldn't all be crammed into a single control type. Particularly one that changes radically based on the skin just because the data model can be represented by the same data structure. For a ListView it could still fit if it was a list that "scrolled" a page at a time, perhaps that was a bad example. I would still expect the control to be a Node and to have direct access via the control to the current "scroll" position. I would not expect a ListView to have a page-based API, nor would I expect to get access to such an API by accessing the Skin. The skin is an implementation detail that should remain distinct from how my program interacts with the control. > > Scott > >> On Mar 21, 2015, at 2:53 PM, Tom Eugelink wrote: >> >> A page based view can perfectly be a list view; I would have no problem having a paging skin or a scrollbar skin for ListView. >> >> >> >>> On 21-3-2015 19:46, Scott Palmer wrote: >>> But that's not right. A *List* is 'a container for an unbounded list of items". A ListView is a specific type of control that gives you a view to that list *in a specific way*. It has properties in addition to the list itself. It *should* have a scroll position because that is a property of that kind of control - even though the skin will implement it. These controls are visible elements and must expose properties that will ultimately be implemented in the skin. They must be Nodes. Otherwise they will be far too cumbersome to use. >>> You may not need to expose where the scroll bars are, or get access to arrow buttons, etc., but you should have access to what items are visible, what the scroll position is, etc. you should be able to change the scroll position programmatically without knowing the skin. >>> >>> A page based view is a different kind of control. It can still use a List model, but flipping to a page system from a scrollable list is not something I would expect when changing the look and feel. I might expect to have the view change from pixel-based scrolling to line based scrolling, or have up/down arrows at one end of the scroll bar instead of each end. >>> >>> Scott >>> >>>> On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx wrote: >>>> >>>> As someone that has been tempted to write a new Control that replaces ListView atleast half a dozen times now because of restrictions or idioms that don't match my needs, I'd disagree. A ListView doesn't need to scroll at all. An application that isn't mouse or touchscreen controlled (keyboard or remote controlled for example) has zero need for scrollbars except maybe as information to show the relative size of the view. >>>> >>>> A List of items could be paged only, or they could flip. I'd like to be able to take a List, and wrap it in a ScrollBarView... or in a PagerView, FlipOverView or CoverFlowView (with 30 new properties to set things like reflections, 3d parameters, distance between items, etc). It is possible to do this with Skins, but it feels like a hack rather than simply a different Look&Feel in the end. >>>> >>>> After all, a ListView is a container for an unbounded list of items. I can think of half a dozen ways of how that can be shown to the user, and the current ListView is just one way to do it. The promise of Skins here is that I could just change the look& feel, but unfortunately way too many details of the "default" look& feel leak through in the Control itself >>>> >>>> --John. From tbee at tbee.org Sun Mar 22 08:59:01 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 22 Mar 2015 09:59:01 +0100 Subject: The trouble with Skins In-Reply-To: <550DFADC.30304@xs4all.nl> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> Message-ID: <550E8455.4090107@tbee.org> On 22-3-2015 00:12, John Hendrikx wrote: > > What I do need however is a way to restore the control to the exact same state it was in before (the same amount of pixels scrolled, the same item at the top, the same item at the bottom). That is an interesting use case. Can you describe it a bit more? Tom From hjohn at xs4all.nl Sun Mar 22 12:53:37 2015 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 22 Mar 2015 13:53:37 +0100 Subject: The trouble with Skins In-Reply-To: <550E8455.4090107@tbee.org> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <550E8455.4090107@tbee.org> Message-ID: <550EBB51.20104@xs4all.nl> On 22/03/2015 09:59, Tom Eugelink wrote: > On 22-3-2015 00:12, John Hendrikx wrote: >> >> What I do need however is a way to restore the control to the exact >> same state it was in before (the same amount of pixels scrolled, the >> same item at the top, the same item at the bottom). > > That is an interesting use case. Can you describe it a bit more? > > Tom > My app works more like a browser, so when I "go back", I expect the same screen layout again (even though I have to reconstruct the screen again). With a ListView, this cannot be done as the #scrollTo method only shows an item. It doesn't remember however if that item was somewhere in the middle, top or bottom. It's just convenient if it was in the same spot, as the user might expect it there. Just like I expect my browser to go back to the same spot helps me a bit (eg: I clicked the link at the bottom of the screen somewhere, and there was something else interesting to the left of it -- that fails if it is now somewhere else). --John From hastebrot at gmail.com Sun Mar 22 13:33:51 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Sun, 22 Mar 2015 14:33:51 +0100 Subject: The trouble with Skins In-Reply-To: <550EBB51.20104@xs4all.nl> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <550E8455.4090107@tbee.org> <550EBB51.20104@xs4all.nl> Message-ID: Hi John, if your app has something like "pages" this could work. You could use a StackPane and put the first page (for example a list view) into it. When a state change occurs (for example a list item is clicked and we move over to a detail view) we could put this second page over the first page in the StackPane. If a "jump to previous page" action is fired then the element on top of the StackPane is pop()'ed and we see the ListView with the previous scroll offset. --Benjamin On Sun, Mar 22, 2015 at 1:53 PM, John Hendrikx wrote: > On 22/03/2015 09:59, Tom Eugelink wrote: > >> On 22-3-2015 00:12, John Hendrikx wrote: >> >>> >>> What I do need however is a way to restore the control to the exact same >>> state it was in before (the same amount of pixels scrolled, the same item >>> at the top, the same item at the bottom). >>> >> >> That is an interesting use case. Can you describe it a bit more? >> >> Tom >> >> My app works more like a browser, so when I "go back", I expect the same > screen layout again (even though I have to reconstruct the screen again). > With a ListView, this cannot be done as the #scrollTo method only shows an > item. It doesn't remember however if that item was somewhere in the > middle, top or bottom. It's just convenient if it was in the same spot, as > the user might expect it there. Just like I expect my browser to go back > to the same spot helps me a bit (eg: I clicked the link at the bottom of > the screen somewhere, and there was something else interesting to the left > of it -- that fails if it is now somewhere else). > > --John > From tbee at tbee.org Sun Mar 22 15:18:19 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 22 Mar 2015 16:18:19 +0100 Subject: The trouble with Skins In-Reply-To: <550EBB51.20104@xs4all.nl> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <550E8455.4090107@tbee.org> <550EBB51.20104@xs4all.nl> Message-ID: <550EDD3B.9060403@tbee.org> On 22-3-2015 13:53, John Hendrikx wrote: > On 22/03/2015 09:59, Tom Eugelink wrote: >> On 22-3-2015 00:12, John Hendrikx wrote: >>> >>> What I do need however is a way to restore the control to the exact same state it was in before (the same amount of pixels scrolled, the same item at the top, the same item at the bottom). >> >> That is an interesting use case. Can you describe it a bit more? >> >> Tom >> > My app works more like a browser, so when I "go back", I expect the same screen layout again (even though I have to reconstruct the screen again). With a ListView, this cannot be done as the #scrollTo method only shows an item. It doesn't remember however if that item was somewhere in the middle, top or bottom. It's just convenient if it was in the same spot, as the user might expect it there. Just like I expect my browser to go back to the same spot helps me a bit (eg: I clicked the link at the bottom of the screen somewhere, and there was something else interesting to the left of it -- that fails if it is now somewhere else). > Ah, ok. So I am curious; even though the browser main scrollbar might return to the position you were before (or even when refreshing a site might do), will it also return divs-with-scrollbar to the same position? I doubt it. But HTML is much more low level than JavaFX's controls; if you were to build a JavaFX screen just using primitive controls, so create your own list with a pane and a scrollbar, then that scrollbar's API is available and you can do what you want. As soon as you start encapsulating things, then it becomes more interesting. Does for example JSF's list control allow you to specify the scroll position, or JQuery tables? From hjohn at xs4all.nl Sun Mar 22 15:37:30 2015 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 22 Mar 2015 16:37:30 +0100 Subject: The trouble with Skins In-Reply-To: <550EDD3B.9060403@tbee.org> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <550E8455.4090107@tbee.org> <550EBB51.20104@xs4all.nl> <550EDD3B.9060403@tbee.org> Message-ID: <550EE1BA.7030807@xs4all.nl> On 22/03/2015 16:18, Tom Eugelink wrote: > > On 22-3-2015 13:53, John Hendrikx wrote: >> On 22/03/2015 09:59, Tom Eugelink wrote: >>> On 22-3-2015 00:12, John Hendrikx wrote: >>>> >>>> What I do need however is a way to restore the control to the exact >>>> same state it was in before (the same amount of pixels scrolled, >>>> the same item at the top, the same item at the bottom). >>> >>> That is an interesting use case. Can you describe it a bit more? >>> >>> Tom >>> >> My app works more like a browser, so when I "go back", I expect the >> same screen layout again (even though I have to reconstruct the >> screen again). With a ListView, this cannot be done as the #scrollTo >> method only shows an item. It doesn't remember however if that item >> was somewhere in the middle, top or bottom. It's just convenient if >> it was in the same spot, as the user might expect it there. Just >> like I expect my browser to go back to the same spot helps me a bit >> (eg: I clicked the link at the bottom of the screen somewhere, and >> there was something else interesting to the left of it -- that fails >> if it is now somewhere else). >> > > Ah, ok. So I am curious; even though the browser main scrollbar might > return to the position you were before (or even when refreshing a site > might do), will it also return divs-with-scrollbar to the same > position? I doubt it. > > But HTML is much more low level than JavaFX's controls; if you were to > build a JavaFX screen just using primitive controls, so create your > own list with a pane and a scrollbar, then that scrollbar's API is > available and you can do what you want. As soon as you start > encapsulating things, then it becomes more interesting. Does for > example JSF's list control allow you to specify the scroll position, > or JQuery tables? > Okay, in what way does that change the fact that I'd like to show the user a screen that was how he left it? I could keep the entire page in memory I suppose, but I'd even like it to be the same between restarts (when navigating to the same part of the system again). Anyway, it's super easy to do, the List just has to expose the scroll position in pixels, and allow me to put it back there -- exactly how I solved it with a custom control. --John From richard.bair at oracle.com Mon Mar 23 18:07:22 2015 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 23 Mar 2015 11:07:22 -0700 Subject: The trouble with Skins In-Reply-To: <550DFADC.30304@xs4all.nl> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> Message-ID: <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> tl;dr; I lean toward keeping the Control API as view-agnostic as possible, but where view details become essential to the operation of the control, then define the Control to always include those specific view details. ============================================================================ Very interesting discussion, I?m enjoying reading through it. The following is a bit of background as to where my head was when we were designing this. In Swing we had a similar concept to the Skins, they were the various UI delegates. In theory they allowed you to change the look of a Swing component (and they did) ? but there were all kinds of ?view specific? details that leaked into it, and also in the Swing components. With JavaFX, I wanted to go down more of a purist route, where the Skin would literally do all the UI (view) and the control would be the controller. OK, the Control was a Node because it made more sense conceptually to put a Button into a scene graph than to create a Button, associate it with a view, put the View into the scene graph, and somewhere stash the controller so you could get it back later. And for something like a Button, it works well. Almost as soon as we?d gone down this road we got into the various problems you guys have been discussion around scroll bars and view positions. If you?re using the standard UI, then you kind of want to have access to these properties so you can get the UX right. However if we add these properties to ListView, then it would go down the road of saying ?ListView displays a list of items and has a scroll bar or at least a scroll position and you have convenience API for making certain items visible, etc?. Another very common complaint was about how to go about knowing the size of a cell for a specific list view item. You?d really want an API on ListView that said ?getCell(item)? and then you got the cell, at least assuming it was visible, otherwise since it is virtualized it doesn?t make a whole lot of sense. But anyway, if you don?t know whether the skin even does virtualization, then how can you define these semantics in a way that is broadly consistent and usable? Basically it comes down to having the API on the controller (Control) and restricting what kinds of skins can be created per control or having users cast the skin to a concrete type and work with the Skin directly for such things. If we were a dynamic language we could be dirty and munge the two together into a single thing (dynamic properties), but with its own set of trade-offs (you have to know what kind of skin you?re dealing with, and if you get it wrong, your app breaks). As time went on we ended up adding more view-specific functionality to the controls (even adding view state via the CSS background API etc!!). I don?t know what the right answer is for this design question, but where we were heading was a place where you would have different UI controls for different ?classes? of controls. So a ListView with scrollbars is our ListView, and a PagingListView or something would probably be different. They could have a common base class if we designed it such, otherwise they would just have those similarities that are consistent between the two classes of control. That is why I find this actually quite appropriate: > So Skins prevent us from getting visual details of the Control (such > as scroll position, position of item on screen, ...), because it is > Skin-specific, but at the same time they fail to customize the look & > feel, because visual presentation leaks into the Control anyway. This is the design balance! If you get it wrong, you get exactly what you?re saying here. In the end, I lean toward keeping the Control API as view-agnostic as possible, but where view details become essential to the operation of the control, then define the Control to always include those specific view details. From tbee at tbee.org Mon Mar 23 18:42:40 2015 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 23 Mar 2015 19:42:40 +0100 Subject: The trouble with Skins In-Reply-To: <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> Message-ID: <55105EA0.7030100@tbee.org> On 23-3-2015 19:07, Richard Bair wrote: > In the end, I lean toward keeping the Control API as view-agnostic as possible, but where view details become essential to the operation of the control, then define the Control to always include those specific view details. Thanks for sharing the conceptual vision, Richard. It seems JFXtras controls are on the right(ous) path then; e.g. the SimpleMetroArcGauge only has three properties: min, max and value, plus a list of segments with just a min and max. All the styling is done through CSS. From krueger at lesspain.de Mon Mar 23 18:45:09 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Mon, 23 Mar 2015 19:45:09 +0100 Subject: The trouble with Skins In-Reply-To: <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> Message-ID: On Mon, Mar 23, 2015 at 7:07 PM, Richard Bair wrote: > tl;dr; I lean toward keeping the Control API as view-agnostic as possible, > but where view details become essential to the operation of the control, > then define the Control to always include those specific view details. > > > ============================================================================ > > Very interesting discussion, I?m enjoying reading through it. The > following is a bit of background as to where my head was when we were > designing this. > > In Swing we had a similar concept to the Skins, they were the various UI > delegates. In theory they allowed you to change the look of a Swing > component (and they did) ? but there were all kinds of ?view specific? > details that leaked into it, and also in the Swing components. With JavaFX, > I wanted to go down more of a purist route, where the Skin would literally > do all the UI (view) and the control would be the controller. OK, the > Control was a Node because it made more sense conceptually to put a Button > into a scene graph than to create a Button, associate it with a view, put > the View into the scene graph, and somewhere stash the controller so you > could get it back later. And for something like a Button, it works well. > > Almost as soon as we?d gone down this road we got into the various > problems you guys have been discussion around scroll bars and view > positions. If you?re using the standard UI, then you kind of want to have > access to these properties so you can get the UX right. However if we add > these properties to ListView, then it would go down the road of saying > ?ListView displays a list of items and has a scroll bar or at least a > scroll position and you have convenience API for making certain items > visible, etc?. > > Another very common complaint was about how to go about knowing the size > of a cell for a specific list view item. You?d really want an API on > ListView that said ?getCell(item)? and then you got the cell, at least > assuming it was visible, otherwise since it is virtualized it doesn?t make > a whole lot of sense. But anyway, if you don?t know whether the skin even > does virtualization, then how can you define these semantics in a way that > is broadly consistent and usable? > > Basically it comes down to having the API on the controller (Control) and > restricting what kinds of skins can be created per control or having users > cast the skin to a concrete type and work with the Skin directly for such > things. If we were a dynamic language we could be dirty and munge the two > together into a single thing (dynamic properties), but with its own set of > trade-offs (you have to know what kind of skin you?re dealing with, and if > you get it wrong, your app breaks). > > As time went on we ended up adding more view-specific functionality to the > controls (even adding view state via the CSS background API etc!!). I don?t > know what the right answer is for this design question, but where we were > heading was a place where you would have different UI controls for > different ?classes? of controls. So a ListView with scrollbars is our > ListView, and a PagingListView or something would probably be different. > They could have a common base class if we designed it such, otherwise they > would just have those similarities that are consistent between the two > classes of control. > > That is why I find this actually quite appropriate: > > > So Skins prevent us from getting visual details of the Control (such > > as scroll position, position of item on screen, ...), because it is > > Skin-specific, but at the same time they fail to customize the look & > > feel, because visual presentation leaks into the Control anyway. > > > This is the design balance! If you get it wrong, you get exactly what > you?re saying here. > > In the end, I lean toward keeping the Control API as view-agnostic as > possible, but where view details become essential to the operation of the > control, then define the Control to always include those specific view > details. > > Not understanding the discussion in-depth, I just hope that solving issues like https://javafx-jira.kenai.com/browse/RT-39917 is possible within the current design. If such limitations are something one has to live with, it is not possible to create a UX that can compete with other toolkits including Swing. At the moment this is a brick wall we seem to be hitting porting our product from Swing to JFX. From richard.bair at oracle.com Mon Mar 23 18:50:38 2015 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 23 Mar 2015 11:50:38 -0700 Subject: The trouble with Skins In-Reply-To: References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> Message-ID: <4A5AD531-F403-40CD-8176-1F252D84870C@oracle.com> Sounds like this may be a case of "where view details become essential to the operation of the control, then define the Control to always include those specific view details.? > On Mar 23, 2015, at 11:45 AM, Robert Kr?ger wrote: > > > > On Mon, Mar 23, 2015 at 7:07 PM, Richard Bair > wrote: > tl;dr; I lean toward keeping the Control API as view-agnostic as possible, but where view details become essential to the operation of the control, then define the Control to always include those specific view details. > > ============================================================================ > > Very interesting discussion, I?m enjoying reading through it. The following is a bit of background as to where my head was when we were designing this. > > In Swing we had a similar concept to the Skins, they were the various UI delegates. In theory they allowed you to change the look of a Swing component (and they did) ? but there were all kinds of ?view specific? details that leaked into it, and also in the Swing components. With JavaFX, I wanted to go down more of a purist route, where the Skin would literally do all the UI (view) and the control would be the controller. OK, the Control was a Node because it made more sense conceptually to put a Button into a scene graph than to create a Button, associate it with a view, put the View into the scene graph, and somewhere stash the controller so you could get it back later. And for something like a Button, it works well. > > Almost as soon as we?d gone down this road we got into the various problems you guys have been discussion around scroll bars and view positions. If you?re using the standard UI, then you kind of want to have access to these properties so you can get the UX right. However if we add these properties to ListView, then it would go down the road of saying ?ListView displays a list of items and has a scroll bar or at least a scroll position and you have convenience API for making certain items visible, etc?. > > Another very common complaint was about how to go about knowing the size of a cell for a specific list view item. You?d really want an API on ListView that said ?getCell(item)? and then you got the cell, at least assuming it was visible, otherwise since it is virtualized it doesn?t make a whole lot of sense. But anyway, if you don?t know whether the skin even does virtualization, then how can you define these semantics in a way that is broadly consistent and usable? > > Basically it comes down to having the API on the controller (Control) and restricting what kinds of skins can be created per control or having users cast the skin to a concrete type and work with the Skin directly for such things. If we were a dynamic language we could be dirty and munge the two together into a single thing (dynamic properties), but with its own set of trade-offs (you have to know what kind of skin you?re dealing with, and if you get it wrong, your app breaks). > > As time went on we ended up adding more view-specific functionality to the controls (even adding view state via the CSS background API etc!!). I don?t know what the right answer is for this design question, but where we were heading was a place where you would have different UI controls for different ?classes? of controls. So a ListView with scrollbars is our ListView, and a PagingListView or something would probably be different. They could have a common base class if we designed it such, otherwise they would just have those similarities that are consistent between the two classes of control. > > That is why I find this actually quite appropriate: > > > So Skins prevent us from getting visual details of the Control (such > > as scroll position, position of item on screen, ...), because it is > > Skin-specific, but at the same time they fail to customize the look & > > feel, because visual presentation leaks into the Control anyway. > > > This is the design balance! If you get it wrong, you get exactly what you?re saying here. > > In the end, I lean toward keeping the Control API as view-agnostic as possible, but where view details become essential to the operation of the control, then define the Control to always include those specific view details. > > > Not understanding the discussion in-depth, I just hope that solving issues like https://javafx-jira.kenai.com/browse/RT-39917 is possible within the current design. If such limitations are something one has to live with, it is not possible to create a UX that can compete with other toolkits including Swing. At the moment this is a brick wall we seem to be hitting porting our product from Swing to JFX. From tomas.mikula at gmail.com Mon Mar 23 19:30:08 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Mon, 23 Mar 2015 15:30:08 -0400 Subject: The trouble with Skins In-Reply-To: <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> Message-ID: Thank you, Richard, for your response. On Mon, Mar 23, 2015 at 2:07 PM, Richard Bair wrote: > tl;dr; I lean toward keeping the Control API as view-agnostic as possible, but where view details become essential to the operation of the control, then define the Control to always include those specific view details. This makes sense, but leaves no middle ground. Either the control fits the Skinnable concept (like Button or CheckBox or SimpleMetroArcGauge), or the Control has to include specific view details. In the latter case, these cannot be delegated to the skin, because Control does not know what API is available on the Skin. There is no way for ListView to say that it only accepts skins that implement ListViewSkin interface. Thus, the control has to implement those view details itself, making it effectively a skin-less control. Therefore, there is no middle ground where the Control handles some view-specific details and leaves the rest up to the Skin. Note that passing information (even view-specific) from Control to Skin works somewhat well: at worst the Control can define a new event type that the Skin will observe (such as the ScrollToEvent fired on ListView to order the Skin to scroll). It is the other way that is problematic: when the Control needs to get view-specific information from the Skin. Of course this can be solved (I have done it myself), but at the cost of ugly API on the Control. Tomas From kevin.rushforth at oracle.com Mon Mar 23 20:13:37 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Mar 2015 13:13:37 -0700 Subject: 8u-dev repo unlocked; one more week for automatic 8u --> 9 syncing Message-ID: <551073F1.6030304@oracle.com> The 8u-dev repo is now unlocked after today's sanity testing. As a reminder the automatic syncing of changesets from 8u-dev --> 9-dev will continue for one more week. Any changeset pushed to 8u-dev before 1am next Monday, Mar 30, will make its way to 9-dev without your needing to do anything. After that it will become the individual developer's responsibility to push changesets to 9-dev (and then backport to 8u-dev). -- Kevin From tbee at tbee.org Mon Mar 23 20:15:28 2015 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 23 Mar 2015 21:15:28 +0100 Subject: The trouble with Skins In-Reply-To: References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> Message-ID: <55107460.2090807@tbee.org> On 23-3-2015 20:30, Tomas Mikula wrote: > Control does not know what API is available on the Skin I have many controls that require a skin that implements a certain interface (refresh() is often present). Granted, this is not something that is compiler checkable via the setSkin method, but it can fail quickly at runtime. Works for me. https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-agenda/src/main/java/jfxtras/internal/scene/control/skin/agenda/AgendaSkin.java Tom From tomas.mikula at gmail.com Mon Mar 23 21:03:01 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Mon, 23 Mar 2015 17:03:01 -0400 Subject: The trouble with Skins In-Reply-To: <55107460.2090807@tbee.org> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> <55107460.2090807@tbee.org> Message-ID: Sure, it is a workaround that works, but I don't think type cast should be the recommended way to do this (or to do anything). Tomas On Mon, Mar 23, 2015 at 4:15 PM, Tom Eugelink wrote: > On 23-3-2015 20:30, Tomas Mikula wrote: >> >> Control does not know what API is available on the Skin > > > I have many controls that require a skin that implements a certain interface > (refresh() is often present). Granted, this is not something that is > compiler checkable via the setSkin method, but it can fail quickly at > runtime. Works for me. > > https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-agenda/src/main/java/jfxtras/internal/scene/control/skin/agenda/AgendaSkin.java > > > Tom From tbee at tbee.org Mon Mar 23 21:08:36 2015 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 23 Mar 2015 22:08:36 +0100 Subject: The trouble with Skins In-Reply-To: References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> <55107460.2090807@tbee.org> Message-ID: <551080D4.8050509@tbee.org> Suppose control would support have generics type, to make the requirement on the Skin formal. Control Control Then getSkin would expose information for every skin the control has, without polluting the control's API. Would that work for you? Tom On 23-3-2015 22:03, Tomas Mikula wrote: > Sure, it is a workaround that works, but I don't think type cast > should be the recommended way to do this (or to do anything). > > Tomas > > On Mon, Mar 23, 2015 at 4:15 PM, Tom Eugelink wrote: >> On 23-3-2015 20:30, Tomas Mikula wrote: >>> Control does not know what API is available on the Skin >> >> I have many controls that require a skin that implements a certain interface >> (refresh() is often present). Granted, this is not something that is >> compiler checkable via the setSkin method, but it can fail quickly at >> runtime. Works for me. >> >> https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-agenda/src/main/java/jfxtras/internal/scene/control/skin/agenda/AgendaSkin.java >> >> >> Tom From tomas.mikula at gmail.com Mon Mar 23 21:54:20 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Mon, 23 Mar 2015 17:54:20 -0400 Subject: The trouble with Skins In-Reply-To: <551080D4.8050509@tbee.org> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <2B83E9B4-D10A-418E-922A-1159F1CBB30B@oracle.com> <55107460.2090807@tbee.org> <551080D4.8050509@tbee.org> Message-ID: Yes, I think that would be much better than the current situation. On Mon, Mar 23, 2015 at 5:08 PM, Tom Eugelink wrote: > Suppose control would support have generics type, to make the requirement on > the Skin formal. > > Control > Control > > Then getSkin would expose information for every skin the control has, > without polluting the control's API. Would that work for you? > > Tom > > > On 23-3-2015 22:03, Tomas Mikula wrote: >> >> Sure, it is a workaround that works, but I don't think type cast >> should be the recommended way to do this (or to do anything). >> >> Tomas >> >> On Mon, Mar 23, 2015 at 4:15 PM, Tom Eugelink wrote: >>> >>> On 23-3-2015 20:30, Tomas Mikula wrote: >>>> >>>> Control does not know what API is available on the Skin >>> >>> >>> I have many controls that require a skin that implements a certain >>> interface >>> (refresh() is often present). Granted, this is not something that is >>> compiler checkable via the setSkin method, but it can fail quickly at >>> runtime. Works for me. >>> >>> >>> https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-agenda/src/main/java/jfxtras/internal/scene/control/skin/agenda/AgendaSkin.java >>> >>> >>> Tom > > From phidias51 at gmail.com Tue Mar 24 19:19:00 2015 From: phidias51 at gmail.com (Mark Fortner) Date: Tue, 24 Mar 2015 12:19:00 -0700 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> Message-ID: I think the real "killer app" with JavaFX is the fact that you can maintain a single codebase that runs on iOS, Android, and every desktop you can think of without doubling or tripling development and maintenance costs. SceneBuilder means that graphic designers and UX gurus can play an integral role in the development process without creating "throwaway artifacts". They can leverage their CSS, and graphic design skills, to make a truly rich user experience, that developers can build upon. No more wireframes or comps that you can't build on. You don't have to deal with the headaches, and additional costs that come with having to maintain multiple code bases. When I show some of the YouTube videos of JavaFX in action on mobile platforms, and then show SceneBuilder, people are floored. Currently mobile developers are banging their heads dealing with mobile web, hybrid and native application stacks, and all of the headaches that those environments engender. Different IDEs, different languages, maintaining the LnF and branding across those platforms, maintaining the functionality across those platforms, that when they see something like JavaFX, you can see the interest in moving to a simpler development stack. Why Oracle isn't marketing the hell out of this, I don't know. But they're missing a real opportunity to take back the mobile mindshare they've lost. JavaONE can't be the only venue where you talk about this. This should be talked up and demonstrated at every mobile developer conference that you can think of. Cheers, Mark On Thu, Mar 5, 2015 at 12:46 AM, Johan Vos wrote: > I think it is really important to make a clear distinction between Oracle > as a (database/middleware) company and Oracle as the Java Steward. > > As a Java Steward, Oracle is dedicated to the future of Java, which > includes JavaFX. The Oracle engineers contribute most of the code and > provide excellent support and communication to the community. > > As a company, Oracle can decide that e.g. a commercially supported > SceneBuilder, or JavaFX on embedded, or whatever... is not in line with > their business goals. However, this does not mean that the technology is > not good or has no chance in another business constellation. I am not in > the business of selling cars, but that does not mean I don't believe in the > car industry. > > Personally, I think that both SceneBuilder and JavaFX on Pi could lead to > more revenue on the backend, but if Oracle doesn't see it this way, hey > it's their business decision :) > > Good enough, they take their job as a Java Steward serious, and that shows > by the many great features that have been added in JavaFX 8u40. > > - Johan > > > > > 2015-03-04 23:18 GMT+01:00 Tobias Bley : > > > In the past there were 2 bad signs from Oracle concerning JavaFX: end of > > support for JavaFX on RaspPi and SceneBuilder... > > > > So does have JavaFX a future? > > > > Tobi > > > > > > > Am 04.03.2015 um 23:14 schrieb Mike Hearn : > > > > > > That's great Johan, but ...... what does this mean, exactly? Is SB > > > effectively dead at this point? Short of some horrifically convoluted > > > corporate politics I can't understand why Oracle would develop an > > > application but not provide downloads of it. Does this mean SB won't be > > > upgraded past 8u40? > > > > > > I mean - I don't think it's unreasonable of me to be surprised by this, > > and > > > I thought I followed JFX development pretty closely. What's the story > > here? > > > > > > On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos wrote: > > > > > >> Oracle stated that they won't release new binaries for SceneBuilder, > but > > >> since the code is open-source and BSD licensed, third parties and the > > Java > > >> Community in general can create binaries based on the SceneBuilder > > sources. > > >> This is what we did at Gluon (http://gluonhq.com), and the result can > > be > > >> downloaded at http://gluonhq.com/products/downloads/ > > >> This download is based on the latest 8u40 source code in OpenJFX. It > > >> includes the 8u40 Controls (e.g. Spinner, Dialogs). > > >> > > >> Hope this is helpful. > > >> > > >> - Johan > > >> > > >> 2015-03-04 16:31 GMT+01:00 Mike Hearn : > > >> > > >>> Hi Kevin, > > >>> > > >>> Scene Builder source code is available in the OpenJFX repo under the > > BSD > > >>>> license, but separate binaries are no longer being released as of > > 8u40. > > >>> > > >>> > > >>> I'm a bit confused what this means. > > >>> > > >>> People who want to use Scene Builder are expected to compile it > > themselves > > >>> from now on? Does that really make sense? Presumably the idea here is > > that > > >>> SB will be integrated into IDEs and will no longer have any purpose > as > > a > > >>> standalone app, but I'm not sure we're ready to go there yet - the > last > > >>> time I tried the SB integration into IntelliJ it was extremely basic > > and > > >>> far below the experience of the dedicated app. > > >>> > > >>> As just one example, UI design benefits a lot from maximal screen > > space. > > >>> IDE embeddings often don't provide that. > > >>> > > >> > > >> > > > > > From kevin.rushforth at oracle.com Tue Mar 24 20:05:01 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Mar 2015 13:05:01 -0700 Subject: [8u] post-commit review for: RT-40341: Update copyright header for files modified in 2015 Message-ID: <5511C36D.50205@oracle.com> JIRA: https://javafx-jira.kenai.com/browse/RT-40341 Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e1295ea74649 Simple change to update copyright dates for all files modified in 2015. -- Kevin From felix.bembrick at gmail.com Tue Mar 24 20:26:55 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Wed, 25 Mar 2015 07:26:55 +1100 Subject: 8u40 is released In-Reply-To: References: <54F6324D.1060601@oracle.com> <54F71AE6.907@oracle.com> <091BE10A-6824-4D2F-8B09-1B002AB02FC4@ultramixer.com> Message-ID: That would all be wonderful Mark if JavaFX was in fact viable on iOS and Android which, right at the moment, it isn't. Gluon and RoboVM are doing their best to make this happen but, in my opinion, they are about 100 developers and $50M short of being able to make something that's really going to change the world. I may be wrong - the guys involved are true Java legends and geniuses - but they lack resources and I am not sure where those resources are going to appear from. Felix On 25 March 2015 at 06:19, Mark Fortner wrote: > I think the real "killer app" with JavaFX is the fact that you can maintain > a single codebase that runs on iOS, Android, and every desktop you can > think of without doubling or tripling development and maintenance costs. > SceneBuilder means that graphic designers and UX gurus can play an integral > role in the development process without creating "throwaway artifacts". > They can leverage their CSS, and graphic design skills, to make a truly > rich user experience, that developers can build upon. No more wireframes > or comps that you can't build on. > > You don't have to deal with the headaches, and additional costs that come > with having to maintain multiple code bases. When I show some of the > YouTube videos of JavaFX in action on mobile platforms, and then show > SceneBuilder, people are floored. > > Currently mobile developers are banging their heads dealing with mobile > web, hybrid and native application stacks, and all of the headaches that > those environments engender. Different IDEs, different languages, > maintaining the LnF and branding across those platforms, maintaining the > functionality across those platforms, that when they see something like > JavaFX, you can see the interest in moving to a simpler development stack. > > Why Oracle isn't marketing the hell out of this, I don't know. But they're > missing a real opportunity to take back the mobile mindshare they've lost. > JavaONE can't be the only venue where you talk about this. This should be > talked up and demonstrated at every mobile developer conference that you > can think of. > > Cheers, > > Mark > > > On Thu, Mar 5, 2015 at 12:46 AM, Johan Vos wrote: > > > I think it is really important to make a clear distinction between Oracle > > as a (database/middleware) company and Oracle as the Java Steward. > > > > As a Java Steward, Oracle is dedicated to the future of Java, which > > includes JavaFX. The Oracle engineers contribute most of the code and > > provide excellent support and communication to the community. > > > > As a company, Oracle can decide that e.g. a commercially supported > > SceneBuilder, or JavaFX on embedded, or whatever... is not in line with > > their business goals. However, this does not mean that the technology is > > not good or has no chance in another business constellation. I am not in > > the business of selling cars, but that does not mean I don't believe in > the > > car industry. > > > > Personally, I think that both SceneBuilder and JavaFX on Pi could lead to > > more revenue on the backend, but if Oracle doesn't see it this way, hey > > it's their business decision :) > > > > Good enough, they take their job as a Java Steward serious, and that > shows > > by the many great features that have been added in JavaFX 8u40. > > > > - Johan > > > > > > > > > > 2015-03-04 23:18 GMT+01:00 Tobias Bley : > > > > > In the past there were 2 bad signs from Oracle concerning JavaFX: end > of > > > support for JavaFX on RaspPi and SceneBuilder... > > > > > > So does have JavaFX a future? > > > > > > Tobi > > > > > > > > > > Am 04.03.2015 um 23:14 schrieb Mike Hearn : > > > > > > > > That's great Johan, but ...... what does this mean, exactly? Is SB > > > > effectively dead at this point? Short of some horrifically convoluted > > > > corporate politics I can't understand why Oracle would develop an > > > > application but not provide downloads of it. Does this mean SB won't > be > > > > upgraded past 8u40? > > > > > > > > I mean - I don't think it's unreasonable of me to be surprised by > this, > > > and > > > > I thought I followed JFX development pretty closely. What's the story > > > here? > > > > > > > > On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos wrote: > > > > > > > >> Oracle stated that they won't release new binaries for SceneBuilder, > > but > > > >> since the code is open-source and BSD licensed, third parties and > the > > > Java > > > >> Community in general can create binaries based on the SceneBuilder > > > sources. > > > >> This is what we did at Gluon (http://gluonhq.com), and the result > can > > > be > > > >> downloaded at http://gluonhq.com/products/downloads/ > > > >> This download is based on the latest 8u40 source code in OpenJFX. It > > > >> includes the 8u40 Controls (e.g. Spinner, Dialogs). > > > >> > > > >> Hope this is helpful. > > > >> > > > >> - Johan > > > >> > > > >> 2015-03-04 16:31 GMT+01:00 Mike Hearn : > > > >> > > > >>> Hi Kevin, > > > >>> > > > >>> Scene Builder source code is available in the OpenJFX repo under > the > > > BSD > > > >>>> license, but separate binaries are no longer being released as of > > > 8u40. > > > >>> > > > >>> > > > >>> I'm a bit confused what this means. > > > >>> > > > >>> People who want to use Scene Builder are expected to compile it > > > themselves > > > >>> from now on? Does that really make sense? Presumably the idea here > is > > > that > > > >>> SB will be integrated into IDEs and will no longer have any purpose > > as > > > a > > > >>> standalone app, but I'm not sure we're ready to go there yet - the > > last > > > >>> time I tried the SB integration into IntelliJ it was extremely > basic > > > and > > > >>> far below the experience of the dedicated app. > > > >>> > > > >>> As just one example, UI design benefits a lot from maximal screen > > > space. > > > >>> IDE embeddings often don't provide that. > > > >>> > > > >> > > > >> > > > > > > > > > From kevin.rushforth at oracle.com Tue Mar 24 21:04:19 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Mar 2015 14:04:19 -0700 Subject: [9] post-commit review for: RT-40341: Update copyright header for files modified in 2015 Message-ID: <5511D153.2020906@oracle.com> JIRA: https://javafx-jira.kenai.com/browse/RT-40341 Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/53cecfdd9b0d Follow-on changes for files that are new (or newly modified) in FX 9. -- Kevin From tbee at tbee.org Tue Mar 24 22:47:11 2015 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 24 Mar 2015 23:47:11 +0100 Subject: The trouble with Skins In-Reply-To: <550EBB51.20104@xs4all.nl> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <550E8455.4090107@tbee.org> <550EBB51.20104@xs4all.nl> Message-ID: <5511E96F.2060403@tbee.org> On 22-3-2015 13:53, John Hendrikx wrote: > On 22/03/2015 09:59, Tom Eugelink wrote: >> On 22-3-2015 00:12, John Hendrikx wrote: >>> >>> What I do need however is a way to restore the control to the exact same state it was in before (the same amount of pixels scrolled, the same item at the top, the same item at the bottom). >> I was thinking; maybe you are approaching this from the wrong angle by trying to break open the controls. How about inspecting the node tree, after it has been constructed (all skins have created their nodes)? After all, a ListView will insert a scrollpane into the tree, which will insert a scrollbar. You could analyze the resulting node tree and search for the scrollbars, then record their scroll values. The trick would be to identify the correct one again to reset the value. You may be able to derrive an identifier from the tree path to the scrollbar, assuming it would be identical before and after. Or maybe better, you could place a UUID in the node's properties and also use that UUID for storing the recorded values. Could that work? Tom From kevin.rushforth at oracle.com Tue Mar 24 23:21:58 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Mar 2015 16:21:58 -0700 Subject: [8u60] review request: RT-36726: Update to Newer Version of WebKit Message-ID: <5511F196.2030208@oracle.com> Anton, Can you do a sanity check of the following issue to backport the new WebKit to 8u60? https://javafx-jira.kenai.com/browse/RT-40055 ( backport of https://javafx-jira.kenai.com/browse/RT-36726 ) All of the review information is in the JIRA. Barring anything unforeseen, I will push this to 8u-dev tomorrow (Wednesday) afternoon or Thursday morning. -- Kevin From tomas.mikula at gmail.com Tue Mar 24 23:23:21 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Tue, 24 Mar 2015 19:23:21 -0400 Subject: The trouble with Skins In-Reply-To: <5511E96F.2060403@tbee.org> References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <550E8455.4090107@tbee.org> <550EBB51.20104@xs4all.nl> <5511E96F.2060403@tbee.org> Message-ID: On Tue, Mar 24, 2015 at 6:47 PM, Tom Eugelink wrote: > On 22-3-2015 13:53, John Hendrikx wrote: >> >> On 22/03/2015 09:59, Tom Eugelink wrote: >>> >>> On 22-3-2015 00:12, John Hendrikx wrote: >>>> >>>> >>>> What I do need however is a way to restore the control to the exact same >>>> state it was in before (the same amount of pixels scrolled, the same item at >>>> the top, the same item at the bottom). >>> >>> > > I was thinking; maybe you are approaching this from the wrong angle by > trying to break open the controls. How about inspecting the node tree, after > it has been constructed (all skins have created their nodes)? After all, a > ListView will insert a scrollpane into the tree, which will insert a > scrollbar. You could analyze the resulting node tree and search for the > scrollbars, then record their scroll values. > > The trick would be to identify the correct one again to reset the value. You > may be able to derrive an identifier from the tree path to the scrollbar, > assuming it would be identical before and after. Or maybe better, you could > place a UUID in the node's properties and also use that UUID for storing the > recorded values. Could that work? > I'm sure you could make it work this way, but 1) it is a lot of work and 2) it is very fragile. It will break when ListView internals change or when the ListView is loaded with a different skin on restart. So it's a matter of how badly John wants this done. Btw, "inspecting the node tree" seems like "break open the controls" to me. I think it is OK to say that ListView does not support this; my more general question was how should one proceed when writing a custom control that supports some view-specific details and at the same time wants to have customizable (i.e. skinnable) look & feel. Tomas From Fabrizio.Giudici at tidalwave.it Wed Mar 25 18:16:44 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 25 Mar 2015 19:16:44 +0100 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 Message-ID: Hello. I got my PI 2 since a few days and I'd like to develop in JavaFX on it. I've read the January announcement from Oracle about the end of support for JavaFX... sigh. In these days I'm just checking whether the development with JavaFX on the PI 2 is feasable or a pain in the ass. On this purpose, I've prepared a small application with just a couple of screens and testing deployment. First, I'd like to thank a lot those who are working for the OpenJFX port as a patch for the missing Oracle part. Following the simple instructions to "patch" the Oracle JDK 1.8.0_33 I've been able to build a somewhat working system. Now, the problems. I'm testing with two JDKs: * the one pre-installed in Raspbian: java.version: 1.8.0 + javafx.runtime.version: 8.0.0-b132 * the "patched" one: java.version: 1.8.0_33 + javafx.runtime.version: 8.0.60-ea (Wed Mar 25 00:04:40 UTC 2015) First problem. It occurs with both JDKs. My application starts at fullscreen, but it isn't really covering the whole screen. It is actually smaller. There's a strip at the right and the bottom side where I can see a few columns/rows of characters from the underlying console. Is there any bug in this area? Workarounds? Second problem. It only happens with the "patched" JDK. When I run my app from the command line I see: Udev: Failed to write to /sys/class/input/mice/uevent Check that you have permission to access input devices Udev: Failed to write to /sys/class/input/event0/uevent Check that you have permission to access input devices Udev: Failed to write to /sys/class/input/event1/uevent Check that you have permission to access input devices Udev: Failed to write to /sys/class/input/input0/uevent Check that you have permission to access input devices Udev: Failed to write to /sys/class/input/input1/uevent Check that you have permission to access input devices I'm aware that Raspbian requires certain groups for accessing some features. I'm running as the 'fritz' user in the following groups: fritz adm dialout cdrom sudo audio video plugdev games users netdev input pi spi gpio So it seems that there should be any problem. Actually, the problem doesn't occur with the pre-installed JDK. Of course, what's happen is that I can't control my app with neither the keyboard nor the mouse. Third problem, still with the "patched JDK". Perhaps it's just a consequence of the second. I tried to run as sudo: while I don't see the error messages, still I can't control the application. Actually I don't even see the mouse pointer. Perhaps is it just this bug: http://stackoverflow.com/questions/26296805/ ? I've seen it with JDK 1.8.0 build 25.0-b70 on my Mac OS X, and disappeared after I've upgraded to 1.8.0_40. Actually at present time I can test some more with the pre-installed JDK, but obviously I'd like to move to the latest available one as soon as possible. Please also let me know how I can help in the investigations. Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From kevin.rushforth at oracle.com Wed Mar 25 18:33:09 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Mar 2015 11:33:09 -0700 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: References: Message-ID: <5512FF65.8030700@oracle.com> Jasper just ran the 8u33 + javafx 8u60-ea earlier this week with no problems -- Ensemble8 demo just came up and ran fine. He did mention that he runs as root, so didn't run into the problem you are seeing with accessing /dev. You might try running as root or else changing the permissions. -- Kevin Fabrizio Giudici wrote: > Hello. > > I got my PI 2 since a few days and I'd like to develop in JavaFX on > it. I've read the January announcement from Oracle about the end of > support for JavaFX... sigh. In these days I'm just checking whether > the development with JavaFX on the PI 2 is feasable or a pain in the > ass. On this purpose, I've prepared a small application with just a > couple of screens and testing deployment. > > First, I'd like to thank a lot those who are working for the OpenJFX > port as a patch for the missing Oracle part. Following the simple > instructions to "patch" the Oracle JDK 1.8.0_33 I've been able to > build a somewhat working system. > > Now, the problems. I'm testing with two JDKs: > > * the one pre-installed in Raspbian: java.version: 1.8.0 + > javafx.runtime.version: 8.0.0-b132 > * the "patched" one: java.version: 1.8.0_33 + javafx.runtime.version: > 8.0.60-ea (Wed Mar 25 00:04:40 UTC 2015) > > First problem. It occurs with both JDKs. My application starts at > fullscreen, but it isn't really covering the whole screen. It is > actually smaller. There's a strip at the right and the bottom side > where I can see a few columns/rows of characters from the underlying > console. Is there any bug in this area? Workarounds? > > Second problem. It only happens with the "patched" JDK. When I run my > app from the command line I see: > > Udev: Failed to write to /sys/class/input/mice/uevent > Check that you have permission to access input devices > Udev: Failed to write to /sys/class/input/event0/uevent > Check that you have permission to access input devices > Udev: Failed to write to /sys/class/input/event1/uevent > Check that you have permission to access input devices > Udev: Failed to write to /sys/class/input/input0/uevent > Check that you have permission to access input devices > Udev: Failed to write to /sys/class/input/input1/uevent > Check that you have permission to access input devices > > I'm aware that Raspbian requires certain groups for accessing some > features. I'm running as the 'fritz' user in the following groups: > > fritz adm dialout cdrom sudo audio video plugdev games users > netdev input pi spi gpio > > So it seems that there should be any problem. Actually, the problem > doesn't occur with the pre-installed JDK. Of course, what's happen is > that I can't control my app with neither the keyboard nor the mouse. > > Third problem, still with the "patched JDK". Perhaps it's just a > consequence of the second. I tried to run as sudo: while I don't see > the error messages, still I can't control the application. Actually I > don't even see the mouse pointer. Perhaps is it just this bug: > > http://stackoverflow.com/questions/26296805/ ? > > I've seen it with JDK 1.8.0 build 25.0-b70 on my Mac OS X, and > disappeared after I've upgraded to 1.8.0_40. > > Actually at present time I can test some more with the pre-installed > JDK, but obviously I'd like to move to the latest available one as > soon as possible. > > Please also let me know how I can help in the investigations. > > Thanks. > > From Fabrizio.Giudici at tidalwave.it Wed Mar 25 19:28:06 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 25 Mar 2015 20:28:06 +0100 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: <5512FF65.8030700@oracle.com> References: <5512FF65.8030700@oracle.com> Message-ID: On Wed, 25 Mar 2015 19:33:09 +0100, Kevin Rushforth wrote: > Jasper just ran the 8u33 + javafx 8u60-ea earlier this week with no > problems -- Ensemble8 demo just came up and ran fine. He did mention > that he runs as root, so didn't run into the problem you are seeing with > accessing /dev. You might try running as root or else changing the > permissions. As I wrote, my application runs at full screen (stage.setFullScreen(true)), while Ensemble8 doesn't. Anyway, if I run Ensemble8 and press the maximise button, the window doesn't grow to the whole screen, but leaves some room at the right and bottom border, just like I see my app. Also - I changed Ensemble8 to run at fullscreen as follows: % diff ./src/EnsembleFullScreen/src/ensemble/Ensemble2.java ./src/Ensemble/src/ensemble/Ensemble2.java 124c124 < //stage.setTitle("Ensemble"); --- > stage.setTitle("Ensemble"); 138,140c138 < //stage.initStyle(StageStyle.UNDECORATED); < stage.setFullScreen(true); < System.err.println("full screen"); --- > stage.initStyle(StageStyle.UNDECORATED); Same video problems: it doesn't cover all the screen. I can also see that the upper left corner of the application is off-screen (the whole window seems to be shifted upward and leftward). It's not a monitor overscan problem (at least, not only an overscan problem), since I can see the characters in the underlying console at their right place. What I see is that keyboard navigation and mouse work with Ensemble2 modified at full-screen, so I'll look again at my code about this issue. If you want some more info, or screenshots, let me know. My app is also open source, so I can share the code, but I need to fix a couple of things so it doesn't depend on Maven snapshot artifacts (also, my Hudson is in maintenance and I can't confirm the app can be compiled from the outside world). I'll alter post to oss.sonatype.org the binaries, so if someone wants to try it, just let me know. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From johan at lodgon.com Wed Mar 25 19:39:05 2015 From: johan at lodgon.com (Johan Vos) Date: Wed, 25 Mar 2015 20:39:05 +0100 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: References: <5512FF65.8030700@oracle.com> Message-ID: Hi Fabrizio, Is the Pi 2 behaving differently than the "old" Pi? I don't have a 2 yet, but I have no issues on the old one -- did you run your app on both? - Johan 2015-03-25 20:28 GMT+01:00 Fabrizio Giudici : > On Wed, 25 Mar 2015 19:33:09 +0100, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > > Jasper just ran the 8u33 + javafx 8u60-ea earlier this week with no >> problems -- Ensemble8 demo just came up and ran fine. He did mention that >> he runs as root, so didn't run into the problem you are seeing with >> accessing /dev. You might try running as root or else changing the >> permissions. >> > > As I wrote, my application runs at full screen > (stage.setFullScreen(true)), while Ensemble8 doesn't. Anyway, if I run > Ensemble8 and press the maximise button, the window doesn't grow to the > whole screen, but leaves some room at the right and bottom border, just > like I see my app. > > Also - I changed Ensemble8 to run at fullscreen as follows: > > % diff ./src/EnsembleFullScreen/src/ensemble/Ensemble2.java > ./src/Ensemble/src/ensemble/Ensemble2.java > 124c124 > < //stage.setTitle("Ensemble"); > --- > >> stage.setTitle("Ensemble"); >> > 138,140c138 > < //stage.initStyle(StageStyle.UNDECORATED); > < stage.setFullScreen(true); > < System.err.println("full screen"); > --- > >> stage.initStyle(StageStyle.UNDECORATED); >> > > Same video problems: it doesn't cover all the screen. I can also see that > the upper left corner of the application is off-screen (the whole window > seems to be shifted upward and leftward). It's not a monitor overscan > problem (at least, not only an overscan problem), since I can see the > characters in the underlying console at their right place. > > What I see is that keyboard navigation and mouse work with Ensemble2 > modified at full-screen, so I'll look again at my code about this issue. > > If you want some more info, or screenshots, let me know. My app is also > open source, so I can share the code, but I need to fix a couple of things > so it doesn't depend on Maven snapshot artifacts (also, my Hudson is in > maintenance and I can't confirm the app can be compiled from the outside > world). I'll alter post to oss.sonatype.org the binaries, so if someone > wants to try it, just let me know. > > > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it > From Fabrizio.Giudici at tidalwave.it Wed Mar 25 20:03:55 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 25 Mar 2015 21:03:55 +0100 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: References: <5512FF65.8030700@oracle.com> Message-ID: On Wed, 25 Mar 2015 20:39:05 +0100, Johan Vos wrote: > Hi Fabrizio, > > Is the Pi 2 behaving differently than the "old" Pi? I don't have a 2 yet, > but I have no issues on the old one -- did you run your app on both? > Unfortunately I can't answer, since this is my first PI. I resisted for many months to the desire to buy and play with it, and I surrendered only a few days ago :o) So it's highly possible it's something on my side - but I just prepared my PI 2 with the NOOBS sdcard, in the standard way... -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From David.Hill at Oracle.com Wed Mar 25 20:04:28 2015 From: David.Hill at Oracle.com (David Hill) Date: Wed, 25 Mar 2015 16:04:28 -0400 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: References: <5512FF65.8030700@oracle.com> Message-ID: <551314CC.6030300@Oracle.com> On 3/25/15, 3:28 PM, Fabrizio Giudici wrote: Two possibilities - Did you up the allocated vram ? (I think this might not be a factor on newer Raspbians, they were going to a dynamic split). Does X11 fill the full screen when it runs ? It would be interesting to know what FX thinks the screen is sized at, -Dprism.verbose=true Dave > On Wed, 25 Mar 2015 19:33:09 +0100, Kevin Rushforth wrote: > >> Jasper just ran the 8u33 + javafx 8u60-ea earlier this week with no problems -- Ensemble8 demo just came up and ran fine. He did mention that he runs as root, so didn't run into the problem you are seeing with accessing /dev. You might try running as root or else changing the permissions. > > As I wrote, my application runs at full screen (stage.setFullScreen(true)), while Ensemble8 doesn't. Anyway, if I run Ensemble8 and press the maximise button, the window doesn't grow to the whole screen, but leaves some room at the right and bottom border, just like I see my app. > > Also - I changed Ensemble8 to run at fullscreen as follows: > > % diff ./src/EnsembleFullScreen/src/ensemble/Ensemble2.java ./src/Ensemble/src/ensemble/Ensemble2.java > 124c124 > < //stage.setTitle("Ensemble"); > --- >> stage.setTitle("Ensemble"); > 138,140c138 > < //stage.initStyle(StageStyle.UNDECORATED); > < stage.setFullScreen(true); > < System.err.println("full screen"); > --- >> stage.initStyle(StageStyle.UNDECORATED); > > Same video problems: it doesn't cover all the screen. I can also see that the upper left corner of the application is off-screen (the whole window seems to be shifted upward and leftward). It's not a monitor overscan problem (at least, not only an overscan problem), since I can see the characters in the underlying console at their right place. > > What I see is that keyboard navigation and mouse work with Ensemble2 modified at full-screen, so I'll look again at my code about this issue. > > If you want some more info, or screenshots, let me know. My app is also open source, so I can share the code, but I need to fix a couple of things so it doesn't depend on Maven snapshot artifacts (also, my Hudson is in maintenance and I can't confirm the app can be compiled from the outside world). I'll alter post to oss.sonatype.org the binaries, so if someone wants to try it, just let me know. > > > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From Fabrizio.Giudici at tidalwave.it Wed Mar 25 20:17:06 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 25 Mar 2015 21:17:06 +0100 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: <551314CC.6030300@Oracle.com> References: <5512FF65.8030700@oracle.com> <551314CC.6030300@Oracle.com> Message-ID: On Wed, 25 Mar 2015 21:04:28 +0100, David Hill wrote: > On 3/25/15, 3:28 PM, Fabrizio Giudici wrote: > > Two possibilities - > > Did you up the allocated vram ? (I think this might not be a factor on > newer Raspbians, they were going to a dynamic split). Yes. It just didn't work with the standard setting. > > Does X11 fill the full screen when it runs ? Yes. It covers the same area as the text console. There's quite a thick black border around, but it's perfectly symmetrical and empty. > It would be interesting to know what FX thinks the screen is sized at, > -Dprism.verbose=true Full log from launch to main screen rendered below (including my own app logging, but it dumps the java properties and could be useful). Prism pipeline init order: es2 sw Using native-based Pisces rasterizer Using dirty region optimizations Using system sized mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2_monocle succeeded. GLFactory using com.sun.prism.es2.MonocleGLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline Maximum supported texture size: 2048 Non power of two texture support = true Maximum number of vertex attributes = 8 Maximum number of uniform vertex components = 544 Maximum number of uniform fragment components = 544 Maximum number of varying components = 32 Maximum number of texture units usable in a vertex shader = 8 Maximum number of texture units usable in a fragment shader = 8 Graphics Vendor: Broadcom Renderer: VideoCore IV HW Version: OpenGL ES 2.0 vsync: true vpipe: true 20:14:45.509 [JavaFX-Launcher ] INFO it.tidalwave.ui.javafx.JavaFXApplicationWithSplash - init() 20:14:47.310 [X Application Thread] INFO it.tidalwave.ui.javafx.JavaFXApplicationWithSplash - start(javafx.stage.Stage at 1e9696b) 20:14:49.113 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - awt.toolkit: sun.awt.X11.XToolkit 20:14:49.115 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - com.sun.javafx.gestures.rotate: true 20:14:49.116 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - com.sun.javafx.gestures.scroll: true 20:14:49.117 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - com.sun.javafx.gestures.zoom: true 20:14:49.118 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - com.sun.javafx.isEmbedded: true 20:14:49.119 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - com.sun.javafx.scene.control.skin.FXVK.cache: true 20:14:49.120 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - doNativeComposite: true 20:14:49.122 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - embedded: monocle 20:14:49.122 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - file.encoding: ANSI_X3.4-1968 20:14:49.123 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - file.encoding.pkg: sun.io 20:14:49.124 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - file.separator: / 20:14:49.125 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - glass.platform: Monocle 20:14:49.126 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.awt.graphicsenv: sun.awt.X11GraphicsEnvironment 20:14:49.127 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.awt.printerjob: sun.print.PSPrinterJob 20:14:49.128 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.class.path: ./lib/aopalliance-1.0.jar:./lib/aquafx-0.1.jar:./lib/aspectjrt-1.8.1.jar:./lib/aspectjweaver-1.8.1.jar:./lib/bsh-2.0b4.jar:./lib/hamcrest-all-1.3.jar:./lib/it-tidalwave-bluemarine2-application-javafx-1.0-ALPHA-1-SNAPSHOT.jar:./lib/it-tidalwave-bluemarine2-model-1.0-ALPHA-1-SNAPSHOT.jar:./lib/it-tidalwave-bluemarine2-ui-1.0-ALPHA-1-SNAPSHOT.jar:./lib/it-tidalwave-bluemarine2-ui-javafx-1.0-ALPHA-1-SNAPSHOT.jar:./lib/it-tidalwave-messagebus-1.0.21-SNAPSHOT.jar:./lib/it-tidalwave-messagebus-spring-1.0.21-SNAPSHOT.jar:./lib/it-tidalwave-role-1.0.3-SNAPSHOT.jar:./lib/it-tidalwave-role-spring-1.0.45-SNAPSHOT.jar:./lib/it-tidalwave-role-ui-javafx-1.0-ALPHA-1-SNAPSHOT.jar:./lib/it-tidalwave-util-1.12.28-SNAPSHOT.jar:./lib/it-tidalwave-util-java8supplement-1.12-SNAPSHOT.jar:./lib/it-tidalwave-util-logging-1.1.42-SNAPSHOT.jar:./lib/it-tidalwave-util-test-1.0.36-SNAPSHOT.jar:./lib/javax.inject-1.jar:./lib/jcl-over-slf4j-1.7.5.jar:./lib/jcommander-1.27.jar:./lib/jsr305-1.3.7.jar:./lib/junit-4.7.j ar:./lib/logback-classic-1.0.13.jar:./lib/logback-core-1.0.13.jar:./lib/lombok-1.12.6.jar:./lib/mockito-all-1.9.5.jar:./lib/org.incava.util.diff-1.1.0.jar:./lib/slf4j-api-1.7.5.jar:./lib/spring-aop-4.0.2.RELEASE.jar:./lib/spring-aspects-4.0.2.RELEASE.jar:./lib/spring-beans-4.0.2.RELEASE.jar:./lib/spring-context-4.0.2.RELEASE.jar:./lib/spring-core-4.0.2.RELEASE.jar:./lib/spring-expression-4.0.2.RELEASE.jar:./lib/testng-6.8.8.jar 20:14:49.130 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.class.version: 52.0 20:14:49.131 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.endorsed.dirs: /home/fritz/bluemarine/jre/lib/endorsed 20:14:49.132 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.ext.dirs: /home/fritz/bluemarine/jre/lib/ext:/usr/java/packages/lib/ext 20:14:49.133 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.home: /home/fritz/bluemarine/jre 20:14:49.134 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.io.tmpdir: /tmp 20:14:49.136 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.library.path: /usr/java/packages/lib/arm:/lib:/usr/lib 20:14:49.137 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.runtime.name: Java(TM) SE Runtime Environment 20:14:49.138 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.runtime.version: 1.8.0_33-b05 20:14:49.139 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.specification.name: Java Platform API Specification 20:14:49.140 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.specification.vendor: Oracle Corporation 20:14:49.141 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.specification.version: 1.8 20:14:49.142 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.vendor: Oracle Corporation 20:14:49.143 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.vendor.url: http://java.oracle.com/ 20:14:49.144 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.vendor.url.bug: http://bugreport.sun.com/bugreport/ 20:14:49.145 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.version: 1.8.0_33 20:14:49.146 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.vm.info: mixed mode 20:14:49.146 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.vm.name: Java HotSpot(TM) Client VM 20:14:49.147 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.vm.specification.name: Java Virtual Machine Specification 20:14:49.148 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.vm.specification.vendor: Oracle Corporation 20:14:49.149 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.vm.specification.version: 1.8 20:14:49.150 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.vm.vendor: Oracle Corporation 20:14:49.152 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.vm.version: 25.33-b05 20:14:49.153 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - javafx.runtime.version: 8.0.60-ea (Wed Mar 25 00:04:40 UTC 2015) 20:14:49.154 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - javafx.version: 8.0.60-ea 20:14:49.155 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - line.separator: 20:14:49.157 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - os.arch: arm 20:14:49.158 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - os.name: Linux 20:14:49.159 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - os.version: 3.18.7-v7+ 20:14:49.161 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - path.separator: : 20:14:49.162 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - prism.eglfb: true 20:14:49.163 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - prism.glDepthSize: 0 20:14:49.164 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - prism.lcdtext: false 20:14:49.165 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - prism.maxvram: 128m 20:14:49.166 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - prism.order: es2,sw 20:14:49.167 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - prism.targetvram: 112m 20:14:49.168 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - prism.verbose: true 20:14:49.170 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.arch.abi: gnueabihf 20:14:49.171 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.arch.data.model: 32 20:14:49.172 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.boot.class.path: /home/fritz/bluemarine/jre/lib/resources.jar:/home/fritz/bluemarine/jre/lib/rt.jar:/home/fritz/bluemarine/jre/lib/sunrsasign.jar:/home/fritz/bluemarine/jre/lib/jsse.jar:/home/fritz/bluemarine/jre/lib/jce.jar:/home/fritz/bluemarine/jre/lib/charsets.jar:/home/fritz/bluemarine/jre/lib/jfr.jar:/home/fritz/bluemarine/jre/classes 20:14:49.173 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.boot.library.path: /home/fritz/bluemarine/jre/lib/arm 20:14:49.175 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.cpu.endian: little 20:14:49.176 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.cpu.isalist: 20:14:49.177 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.io.unicode.encoding: UnicodeLittle 20:14:49.179 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.java.command: it.tidalwave.bluemarine2.ui.impl.javafx.Main 20:14:49.180 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.java.launcher: SUN_STANDARD 20:14:49.182 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.jnu.encoding: ANSI_X3.4-1968 20:14:49.183 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.management.compiler: HotSpot Client Compiler 20:14:49.184 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - sun.os.patch.level: unknown 20:14:49.186 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - use.egl: true 20:14:49.187 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - use.gles2: true 20:14:49.188 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - user.country: US 20:14:49.190 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - user.dir: /home/fritz/bluemarine 20:14:49.191 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - user.home: /root 20:14:49.192 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - user.language: en 20:14:49.194 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - user.name: root 20:14:49.195 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - user.timezone: Etc/UTC ES2ResourceFactory: Prism - createStockShader: AlphaOne_Color.frag max rectangle texture cell size = 62 wrap rectangle texture = 2 x 2 ES2ResourceFactory: Prism - createStockShader: AlphaTexture_Color.frag ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag 20:14:50.229 [pool-2-thread-1 ] INFO o.s.context.support.ClassPathXmlApplicationContext - Refreshing org.springframework.context.support.ClassPathXmlApplicationContext at 1c50ff8: startup date [Wed Mar 25 20:14:50 UTC 2015]; root of context hierarchy 20:14:59.016 [pool-2-thread-1 ] INFO o.s.beans.factory.xml.XmlBeanDefinitionReader - Loading XML bean definitions from URL [jar:file:/home/fritz/bluemarine/lib/it-tidalwave-bluemarine2-application-javafx-1.0-ALPHA-1-SNAPSHOT.jar!/META-INF/JavaFXApplicationAutoBeans.xml] 20:15:00.181 [pool-2-thread-1 ] INFO o.s.beans.factory.xml.XmlBeanDefinitionReader - Loading XML bean definitions from URL [jar:file:/home/fritz/bluemarine/lib/it-tidalwave-bluemarine2-ui-1.0-ALPHA-1-SNAPSHOT.jar!/META-INF/UIAutoBeans.xml] 20:15:00.436 [pool-2-thread-1 ] INFO o.s.beans.factory.xml.XmlBeanDefinitionReader - Loading XML bean definitions from URL [jar:file:/home/fritz/bluemarine/lib/it-tidalwave-bluemarine2-ui-javafx-1.0-ALPHA-1-SNAPSHOT.jar!/META-INF/JavaFxUIAutoBeans.xml] 20:15:00.604 [pool-2-thread-1 ] INFO o.s.beans.factory.xml.XmlBeanDefinitionReader - Loading XML bean definitions from URL [jar:file:/home/fritz/bluemarine/lib/it-tidalwave-role-ui-javafx-1.0-ALPHA-1-SNAPSHOT.jar!/META-INF/JavaFXAutoBeans.xml] 20:15:01.523 [pool-2-thread-1 ] INFO o.s.b.f.a.AutowiredAnnotationBeanPostProcessor - JSR-330 'javax.inject.Inject' annotation found and supported for autowiring 20:15:03.231 [pool-2-thread-1 ] DEBUG it.tidalwave.role.spi.RoleManagerSupport - Configured roles: 20:15:03.427 [pool-2-thread-1 ] INFO o.s.scheduling.concurrent.ThreadPoolTaskExecutor - Initializing ExecutorService 'applicationMessageBusTaskExecutor' 20:15:03.577 [pool-2-thread-1 ] TRACE it.tidalwave.role.spi.ContextSampler - >>>> contexts at construction time: [] 20:15:03.721 [pool-2-thread-1 ] INFO o.s.scheduling.concurrent.ThreadPoolTaskExecutor - Initializing ExecutorService 'javafxBinderExecutor' 20:15:04.367 [pool-2-thread-1 ] TRACE it.tidalwave.role.spi.ContextSampler - >>>> contexts at construction time: [] 20:15:04.395 [pool-2-thread-1 ] TRACE it.tidalwave.role.spi.ContextSampler - >>>> contexts at construction time: [] 20:15:04.411 [pool-2-thread-1 ] TRACE it.tidalwave.role.spi.ContextSampler - >>>> contexts at construction time: [] 20:15:04.552 [X Application Thread] TRACE it.tidalwave.role.ui.javafx.impl.JavaFXSafeProxy - >>>> safely invoking public abstract void it.tidalwave.bluemarine2.ui.mainscreen.MainScreenPresentation.bind(java.util.Collection,it.tidalwave.role.ui.UserAction) 20:15:04.570 [pool-2-thread-1 ] TRACE it.tidalwave.messagebus.MessageBusHelper - registerMessageListener(void it.tidalwave.bluemarine2.ui.mainscreen.impl.DefaultMainScreenPresentationControl.onPowerOnNotification(it.tidalwave.bluemarine2.ui.commons.PowerOnNotification)) 20:15:04.576 [pool-2-thread-1 ] DEBUG it.tidalwave.messagebus.spi.MessageBusSupport - subscribe(class it.tidalwave.bluemarine2.ui.commons.PowerOnNotification, MessageBusAdapterFactory.MessageBusListenerAdapter(method=void it.tidalwave.bluemarine2.ui.mainscreen.impl.DefaultMainScreenPresentationControl.onPowerOnNotification(it.tidalwave.bluemarine2.ui.commons.PowerOnNotification))) 20:15:04.745 [pool-2-thread-1 ] TRACE it.tidalwave.messagebus.MessageBusHelper - registerMessageListener(void it.tidalwave.bluemarine2.ui.stillimage.impl.DefaultStillImageExplorerPresentationControl.onOpenStillImageExplorerRequest(it.tidalwave.bluemarine2.ui.commons.OpenStillImageExplorerRequest)) 20:15:04.747 [pool-2-thread-1 ] DEBUG it.tidalwave.messagebus.spi.MessageBusSupport - subscribe(class it.tidalwave.bluemarine2.ui.commons.OpenStillImageExplorerRequest, MessageBusAdapterFactory.MessageBusListenerAdapter(method=void it.tidalwave.bluemarine2.ui.stillimage.impl.DefaultStillImageExplorerPresentationControl.onOpenStillImageExplorerRequest(it.tidalwave.bluemarine2.ui.commons.OpenStillImageExplorerRequest))) 20:15:04.929 [pool-2-thread-1 ] TRACE it.tidalwave.messagebus.MessageBusHelper - registerMessageListener(void it.tidalwave.bluemarine2.ui.audio.impl.DefaultAudioExplorerPresentationControl.onOpenAudioExplorerRequest(it.tidalwave.bluemarine2.ui.commons.OpenAudioExplorerRequest)) 20:15:04.931 [pool-2-thread-1 ] DEBUG it.tidalwave.messagebus.spi.MessageBusSupport - subscribe(class it.tidalwave.bluemarine2.ui.commons.OpenAudioExplorerRequest, MessageBusAdapterFactory.MessageBusListenerAdapter(method=void it.tidalwave.bluemarine2.ui.audio.impl.DefaultAudioExplorerPresentationControl.onOpenAudioExplorerRequest(it.tidalwave.bluemarine2.ui.commons.OpenAudioExplorerRequest))) 20:15:05.085 [pool-2-thread-1 ] TRACE it.tidalwave.messagebus.MessageBusHelper - registerMessageListener(void it.tidalwave.bluemarine2.ui.video.impl.DefaultVideoExplorerPresentationControl.onOpenVideoExplorerRequest(it.tidalwave.bluemarine2.ui.commons.OpenVideoExplorerRequest)) 20:15:05.087 [pool-2-thread-1 ] DEBUG it.tidalwave.messagebus.spi.MessageBusSupport - subscribe(class it.tidalwave.bluemarine2.ui.commons.OpenVideoExplorerRequest, MessageBusAdapterFactory.MessageBusListenerAdapter(method=void it.tidalwave.bluemarine2.ui.video.impl.DefaultVideoExplorerPresentationControl.onOpenVideoExplorerRequest(it.tidalwave.bluemarine2.ui.commons.OpenVideoExplorerRequest))) 20:15:05.245 [X Application Thread] INFO i.t.b.u.i.j.JavaFXApplicationPresentationDelegate - initialize() 20:15:05.247 [X Application Thread] TRACE it.tidalwave.messagebus.spi.MessageBusSupport - publish(class it.tidalwave.bluemarine2.ui.commons.PowerOnNotification, it.tidalwave.bluemarine2.ui.commons.PowerOnNotification at 1a3a656) 20:15:05.254 [messageBus-1 ] TRACE i.t.m.impl.spring.MessageBusAdapterFactory - notify(it.tidalwave.bluemarine2.ui.commons.PowerOnNotification at 1a3a656) 20:15:05.258 [messageBus-1 ] INFO i.t.b.u.c.f.impl.javafx.JavaFxFlowController - showPresentation(AnchorPane[id=AnchorPane, styleClass=mainFxmlClass]) 20:15:05.350 [X Application Thread] TRACE it.tidalwave.role.ui.javafx.impl.JavaFXSafeProxy - >>>> safely invoking public abstract void it.tidalwave.bluemarine2.ui.mainscreen.MainScreenPresentation.showUp() ES2ResourceFactory: Prism - createStockShader: FillRoundRect_Color.frag ES2ResourceFactory: Prism - createStockShader: DrawRoundRect_Color.frag -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From Fabrizio.Giudici at tidalwave.it Wed Mar 25 21:23:23 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 25 Mar 2015 22:23:23 +0100 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: References: <5512FF65.8030700@oracle.com> <551314CC.6030300@Oracle.com> Message-ID: If somebody wants to try, the binaries zip of my app is here (126M, with embedded jre): https://oss.sonatype.org/content/repositories/snapshots/it/tidalwave/bluemarine2/bluemarine2-linux-armv6-embedded-jre/1.0-ALPHA-1-SNAPSHOT/bluemarine2-linux-armv6-embedded-jre-1.0-ALPHA-1-20150325.201531-2-bin.zip The sources are here (still with possibly troubled snapshots dependencies): https://bitbucket.org/tidalwave/bluemarine2-src/ Changeset from which I build the binaries is 22ccace8a18b -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From kevin.rushforth at oracle.com Wed Mar 25 23:09:44 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Mar 2015 16:09:44 -0700 Subject: HEADS-UP: [8u60] New WebKit + compiler upgrade for FX 8u60 Message-ID: <55134038.4070505@oracle.com> As a heads-up we are ready to push the updated WebKit [1] for JEP-239 [2] plus the needed compiler upgrade changes to 8u-dev tomorrow. This is similar to what we did for FX 9 about 5 weeks ago [3]. Here is a short summary of the changes: * The updated WebKit will be pushed into 8u-dev (for 8u60) tomorrow morning, Thursday, Mar 26, around 8:00 am Pacific. It would be very helpful if other committers refrained from pushing non-trivial changes tomorrow morning (Pacific time). * As was the case for FX 9, this means that our production builds will switch to the new compilers: VS2013 on Windows; Xcode 5.1.1 on Mac; gcc 4.8 on Linux. FX 8u-dev will still be buildable on the old compilers as long as you don't build WebKit (it is disabled by default). * As a reminder, this is the last week that changes pushed to 8u-dev will be automatically synced into 9-dev. I will send out an e-mail tomorrow outlining the new procedures. [1] https://javafx-jira.kenai.com/browse/RT-40055 [2] http://openjdk.java.net/jeps/239 [3] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-February/016700.html -- Kevin From rdarrylr at gmail.com Thu Mar 26 00:32:50 2015 From: rdarrylr at gmail.com (Darryl R) Date: Thu, 26 Mar 2015 00:32:50 +0000 (UTC) Subject: HEADS-UP: [8u60] New WebKit + compiler upgrade for FX 8u60 In-Reply-To: <55134038.4070505@oracle.com> References: <55134038.4070505@oracle.com> Message-ID: <891C291C8AD7CE60.18228572-2328-48A0-A264-AAFDAE95A467@mail.outlook.com> Great news. Thanks for getting this in 8. _____________________________ From: Kevin Rushforth Sent: Wednesday, March 25, 2015 7:11 PM Subject: HEADS-UP: [8u60] New WebKit + compiler upgrade for FX 8u60 To: Cc: Alexander Potochkin , Stephen Fitch As a heads-up we are ready to push the updated WebKit [1] for JEP-239 [2] plus the needed compiler upgrade changes to 8u-dev tomorrow. This is similar to what we did for FX 9 about 5 weeks ago [3].Here is a short summary of the changes:* The updated WebKit will be pushed into 8u-dev (for 8u60) tomorrow morning, Thursday, Mar 26, around 8:00 am Pacific. It would be very helpful if other committers refrained from pushing non-trivial changes tomorrow morning (Pacific time).* As was the case for FX 9, this means that our production builds will switch to the new compilers: VS2013 on Windows; Xcode 5.1.1 on Mac; gcc 4.8 on Linux. FX 8u-dev will still be buildable on the old compilers as long as you don't build WebKit (it is disabled by default).* As a reminder, this is the last week that changes pushed to 8u-dev will be automatically synced into 9-dev. I will send out an e-mail tomorrow outlining the new procedures.[1] https://javafx-jira.kenai.com/browse/RT-40055[2] http://openjdk.java.net/jeps/239[3] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-February/016700.html-- Kevin From krueger at lesspain.de Thu Mar 26 16:36:54 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Thu, 26 Mar 2015 17:36:54 +0100 Subject: Packaging a JFX app in a gradle build system Message-ID: Hi, sorry for posting this here but I have tried Stackoverflow and the Oracle JFX user forum first with no responses. I am looking for the most sensible way to integrate packaging of a JavaFX application into my Gradle build. The plugin at https://bitbucket.org/shemnon/javafx-gradle does not look like it's maintained and I was wondering if there was a better way than manually hacking together a command line invocation of javapackager where I have to manually resolve all the dependency stuff myself. For OSX packaging I have successfully played around with the gradle plugin at https://code.google.com/p/gradle-macappbundle/, which offers the level of convenience that I am looking for but I thought this was something that was within the scope of the Javapackager shipped with the JDK, which I would like to use, mainly because it is a supported/maintained piece of software and supports more than just OSX. Any advice from people doing similar things or maybe the Javapackager-Developers? Best regards, Robert From tbee at tbee.org Thu Mar 26 17:27:26 2015 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 26 Mar 2015 18:27:26 +0100 Subject: The trouble with Skins In-Reply-To: References: <5503E3CB.4070506@tbee.org> <550D95F6.5090706@xs4all.nl> <550DBE0E.7090207@tbee.org> <59F660D0-EADC-4F41-BE66-CC2CE45ED9EB@gmail.com> <550DFADC.30304@xs4all.nl> <550E8455.4090107@tbee.org> <550EBB51.20104@xs4all.nl> <5511E96F.2060403@tbee.org> Message-ID: <5514417E.7070101@tbee.org> On 25-3-2015 00:23, Tomas Mikula wrote: > > I'm sure you could make it work this way, but 1) it is a lot of work > and 2) it is very fragile. It will break when ListView internals > change or when the ListView is loaded with a different skin on > restart. So it's a matter of how badly John wants this done. > > Btw, "inspecting the node tree" seems like "break open the controls" to me. Well, yes and no. This approach will single out only those nodes that need to be visually restored, cutting through any control, like ListView, like if they were not that. For example when they use a scrollbar internally. I expect this approach will be easier and less work than having to restore each and every control. > I think it is OK to say that ListView does not support this; my more > general question was how should one proceed when writing a custom > control that supports some view-specific details and at the same time > wants to have customizable (i.e. skinnable) look & feel. > I had similar concerns back when JFX 2.0 was released. Jonathan may remember the discussion; how does JavaFX enable something like Synthetica in Swing? But it in the end comes down to replacing the skins on the control and using CSS you can. I also use another trick for my custom Swing components: they borrow styling from other controls. For example, I often use JTable and then get the highlight color, etc from it, and use that so my custom component blends in automatically. In JFX this is done with CSS. So it hasn't gotten worse compared to swing. But it would be nice if, for example, the focus border was something that can be applied to a control by simply adding the class (e.g. "focused"). And that isn't the case, because the CSS needs node to attach to. Maybe something like decorators, that can apply themselves to a node, would be an approach. Tom From Fabrizio.Giudici at tidalwave.it Thu Mar 26 18:40:41 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 26 Mar 2015 19:40:41 +0100 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: <551314CC.6030300@Oracle.com> References: <5512FF65.8030700@oracle.com> <551314CC.6030300@Oracle.com> Message-ID: On Wed, 25 Mar 2015 21:04:28 +0100, David Hill wrote: > On 3/25/15, 3:28 PM, Fabrizio Giudici wrote: > > Two possibilities - > > Did you up the allocated vram ? (I think this might not be a factor on > newer Raspbians, they were going to a dynamic split). > > Does X11 fill the full screen when it runs ? > > It would be interesting to know what FX thinks the screen is sized at, > -Dprism.verbose=true Ok, I think I got it. Looking at /boot/config.txt I saw: # NOOBS Auto-generated Settings: hdmi_force_hotplug=1 config_hdmi_boost=4 overscan_left=24 overscan_right=24 overscan_top=16 overscan_bottom=16 disable_overscan=1 gpu_mem=256 I commented out all the overscan_* and set disable_overscan=0. Launching startx, I see that the graphics covers the full screen (some pixels are clipped out, so X11 would really require some overscan, even though a smaller amount). But now JavaFX covers the full screen. Also for JavaFX there are some pixels clipped out. This is not a problem for me: I think that it's up to the JavaFX application to correct for overscan, by simply putting some space around the true contents. So, the thing now is fine for me. But I think that there is a real bug: JavaFX is not correctly computing the screen area when there's that overscan settings. It's probably a low priority one - maybe it would just make sense to warn people about it. The mouse is ok, it was probably a connection fault. The keyboard navigation of buttons is still not working - still investigating. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From danno.ferrin at oracle.com Thu Mar 26 18:43:12 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Thu, 26 Mar 2015 12:43:12 -0600 Subject: Packaging a JFX app in a gradle build system In-Reply-To: References: Message-ID: It?s not abandoned, I?ve just had a lot of work on my day job at the moment. For 8u20 and later you can access most of the new features from the builder arguments. Secondary launchers and file associations will require some additions I hope to get to in the next month or so. > On Mar 26, 2015, at 10:36 AM, Robert Kr?ger wrote: > > Hi, > > sorry for posting this here but I have tried Stackoverflow and the Oracle > JFX user forum first with no responses. > > I am looking for the most sensible way to integrate packaging of a JavaFX > application into my Gradle build. > > The plugin at https://bitbucket.org/shemnon/javafx-gradle does not look > like it's maintained and I was wondering if there was a better way than > manually hacking together a command line invocation of javapackager where I > have to manually resolve all the dependency stuff myself. > > For OSX packaging I have successfully played around with the gradle plugin > at https://code.google.com/p/gradle-macappbundle/, which offers the level > of convenience that I am looking for but I thought this was something that > was within the scope of the Javapackager shipped with the JDK, which I > would like to use, mainly because it is a supported/maintained piece of > software and supports more than just OSX. > > Any advice from people doing similar things or maybe the > Javapackager-Developers? > > Best regards, > > Robert From David.Hill at Oracle.com Thu Mar 26 18:59:04 2015 From: David.Hill at Oracle.com (David Hill) Date: Thu, 26 Mar 2015 14:59:04 -0400 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: References: <5512FF65.8030700@oracle.com> <551314CC.6030300@Oracle.com> Message-ID: <551456F8.4040104@Oracle.com> On 3/26/15, 2:40 PM, Fabrizio Giudici wrote: > On Wed, 25 Mar 2015 21:04:28 +0100, David Hill wrote: > >> On 3/25/15, 3:28 PM, Fabrizio Giudici wrote: >> >> Two possibilities - >> >> Did you up the allocated vram ? (I think this might not be a factor on newer Raspbians, they were going to a dynamic split). >> >> Does X11 fill the full screen when it runs ? >> >> It would be interesting to know what FX thinks the screen is sized at, -Dprism.verbose=true > > Ok, I think I got it. Looking at /boot/config.txt I saw: Fabrizio, good to hear you are further along. If I recall the code initialization correctly, there is not any options for us to do much when opening the framebuffer channel. It is my belief that all of that is done in the kernel, which is why tinkering with that conf file makes things work. Dave > > # NOOBS Auto-generated Settings: > hdmi_force_hotplug=1 > config_hdmi_boost=4 > overscan_left=24 > overscan_right=24 > overscan_top=16 > overscan_bottom=16 > disable_overscan=1 > gpu_mem=256 > > I commented out all the overscan_* and set disable_overscan=0. Launching startx, I see that the graphics covers the full screen (some pixels are clipped out, so X11 would really require some overscan, even though a smaller amount). But now JavaFX covers the full screen. Also for JavaFX there are some pixels clipped out. This is not a problem for me: I think that it's up to the JavaFX application to correct for overscan, by simply putting some space around the true contents. > > So, the thing now is fine for me. But I think that there is a real bug: JavaFX is not correctly computing the screen area when there's that overscan settings. It's probably a low priority one - maybe it would just make sense to warn people about it. > > The mouse is ok, it was probably a connection fault. The keyboard navigation of buttons is still not working - still investigating. > > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From swpalmer at gmail.com Thu Mar 26 19:04:52 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 26 Mar 2015 15:04:52 -0400 Subject: Crash in Glass with 8u40 Message-ID: Has anyone seen this? It's just happened once so far. I haven't figured out what triggers it. Problem Event Name: APPCRASH Application Name: java.exe Application Version: 8.0.40.25 Application Timestamp: 54daf0c7 Fault Module Name: glass.dll Fault Module Version: 8.0.40.25 Fault Module Timestamp: 54daf724 Exception Code: c0000005 Exception Offset: 000000000001d28a OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 4105 Additional Information 1: 36ce Additional Information 2: 36ce6d5e424533078dcd346508862250 Additional Information 3: 6ce6 Additional Information 4: 6ce66690544144f9f054931f0d24080b Scott From krueger at lesspain.de Thu Mar 26 19:23:11 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Thu, 26 Mar 2015 20:23:11 +0100 Subject: Packaging a JFX app in a gradle build system In-Reply-To: References: Message-ID: Great! Thanks for the update! On Thu, Mar 26, 2015 at 7:43 PM, Danno Ferrin wrote: > It?s not abandoned, I?ve just had a lot of work on my day job at the > moment. > > For 8u20 and later you can access most of the new features from the > builder arguments. Secondary > launchers and file associations will require some additions I hope to get > to in the next month or so. > I am not sure I understand this correctly. Does that mean the plugin as it is now works for 8u40? At the moment I would be more than happy just to be able to package a runnable application without file associations. What do you mean by secondary launchers in this context? A second main class in a build file? Best regards, Robert From kevin.rushforth at oracle.com Thu Mar 26 19:26:00 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 Mar 2015 12:26:00 -0700 Subject: Crash in Glass with 8u40 In-Reply-To: References: Message-ID: <55145D48.4070406@oracle.com> Hard to say without an Apple crash dump or Java crash log. Did the crash produce an hs_err* file? -- Kevin Scott Palmer wrote: > Has anyone seen this? It's just happened once so far. I haven't figured > out what triggers it. > > Problem Event Name: APPCRASH > Application Name: java.exe > Application Version: 8.0.40.25 > Application Timestamp: 54daf0c7 > Fault Module Name: glass.dll > Fault Module Version: 8.0.40.25 > Fault Module Timestamp: 54daf724 > Exception Code: c0000005 > Exception Offset: 000000000001d28a > OS Version: 6.1.7601.2.1.0.256.48 > Locale ID: 4105 > Additional Information 1: 36ce > Additional Information 2: 36ce6d5e424533078dcd346508862250 > Additional Information 3: 6ce6 > Additional Information 4: 6ce66690544144f9f054931f0d24080b > > > Scott > From David.Hill at Oracle.com Thu Mar 26 19:59:01 2015 From: David.Hill at Oracle.com (David Hill) Date: Thu, 26 Mar 2015 15:59:01 -0400 Subject: Crash in Glass with 8u40 In-Reply-To: <55145D48.4070406@oracle.com> References: <55145D48.4070406@oracle.com> Message-ID: <55146505.3070909@Oracle.com> On 3/26/15, 3:26 PM, Kevin Rushforth wrote: > Hard to say without an Apple crash dump or Java crash log. Did the crash produce an hs_err* file? Windows most likely (glass.dll) Not aware of anything reported. Keep an eye out for it happening again, and perhaps we will get a better clue :-) Dave > > -- Kevin > > > Scott Palmer wrote: >> Has anyone seen this? It's just happened once so far. I haven't figured >> out what triggers it. >> >> Problem Event Name: APPCRASH >> Application Name: java.exe >> Application Version: 8.0.40.25 >> Application Timestamp: 54daf0c7 >> Fault Module Name: glass.dll >> Fault Module Version: 8.0.40.25 >> Fault Module Timestamp: 54daf724 >> Exception Code: c0000005 >> Exception Offset: 000000000001d28a >> OS Version: 6.1.7601.2.1.0.256.48 >> Locale ID: 4105 >> Additional Information 1: 36ce >> Additional Information 2: 36ce6d5e424533078dcd346508862250 >> Additional Information 3: 6ce6 >> Additional Information 4: 6ce66690544144f9f054931f0d24080b >> >> >> Scott -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From swpalmer at gmail.com Thu Mar 26 21:18:21 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 26 Mar 2015 17:18:21 -0400 Subject: Crash in Glass with 8u40 In-Reply-To: <55146505.3070909@Oracle.com> References: <55145D48.4070406@oracle.com> <55146505.3070909@Oracle.com> Message-ID: No hs_err* file created. I believe it happened when the process was told to terminate. I'll file an issue if I can get anything substantial to report. Cheers, Scott On Thu, Mar 26, 2015 at 3:59 PM, David Hill wrote: > On 3/26/15, 3:26 PM, Kevin Rushforth wrote: > >> Hard to say without an Apple crash dump or Java crash log. Did the crash >> produce an hs_err* file? >> > > Windows most likely (glass.dll) > > Not aware of anything reported. Keep an eye out for it happening again, > and perhaps we will get a better clue :-) > > Dave > > >> -- Kevin >> >> >> Scott Palmer wrote: >> >>> Has anyone seen this? It's just happened once so far. I haven't figured >>> out what triggers it. >>> >>> Problem Event Name: APPCRASH >>> Application Name: java.exe >>> Application Version: 8.0.40.25 >>> Application Timestamp: 54daf0c7 >>> Fault Module Name: glass.dll >>> Fault Module Version: 8.0.40.25 >>> Fault Module Timestamp: 54daf724 >>> Exception Code: c0000005 >>> Exception Offset: 000000000001d28a >>> OS Version: 6.1.7601.2.1.0.256.48 >>> Locale ID: 4105 >>> Additional Information 1: 36ce >>> Additional Information 2: 36ce6d5e424533078dcd346508862250 >>> Additional Information 3: 6ce6 >>> Additional Information 4: 6ce66690544144f9f054931f0d24080b >>> >>> >>> Scott >>> >> > > -- > David Hill > Java Embedded Development > > "A man's feet should be planted in his country, but his eyes should survey > the world." > -- George Santayana (1863 - 1952) > > From Fabrizio.Giudici at tidalwave.it Thu Mar 26 23:03:59 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Fri, 27 Mar 2015 00:03:59 +0100 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: References: <5512FF65.8030700@oracle.com> <551314CC.6030300@Oracle.com> Message-ID: On Thu, 26 Mar 2015 19:40:41 +0100, Fabrizio Giudici wrote: > The mouse is ok, it was probably a connection fault. The keyboard > navigation of buttons is still not working - still investigating. The keyboard is definitely not working with my app, even with a simple TextField. It does work with Ensemble8 and the same jre. My app works fine in Mac OS X. Sounds tricky... Is there any logging option I can activate to investigate whether keystrokes are just not received, or they get lost somewhere? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From swpalmer at gmail.com Thu Mar 26 23:16:14 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 26 Mar 2015 19:16:14 -0400 Subject: Packaging a JFX app in a gradle build system In-Reply-To: References: Message-ID: <0F525D38-9B94-48B3-9C55-48F93419F80E@gmail.com> I am successfully using the javafx gradle plugin to produce a packaged app on Windows and Linux. (Thanks Danno!) I haven't tried much with Mac yet, but I believe it will make an application bundle. Oracle should be making this part of your day job, Danno. Who do I need to bribe? :-) Scott > On Mar 26, 2015, at 3:23 PM, Robert Kr?ger wrote: > > Great! Thanks for the update! > > On Thu, Mar 26, 2015 at 7:43 PM, Danno Ferrin > wrote: > >> It?s not abandoned, I?ve just had a lot of work on my day job at the >> moment. >> >> For 8u20 and later you can access most of the new features from the >> builder arguments. Secondary > > > >> launchers and file associations will require some additions I hope to get >> to in the next month or so. > > I am not sure I understand this correctly. Does that mean the plugin as it > is now works for 8u40? At the moment I would be more than happy just to be > able to package a runnable application without file associations. What do > you mean by secondary launchers in this context? A second main class in a > build file? > > Best regards, > > Robert From kevin.rushforth at oracle.com Fri Mar 27 03:21:42 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 Mar 2015 20:21:42 -0700 Subject: PLEASE READ: Pushing changesets to FX 9-dev and 8u-dev Message-ID: <5514CCC6.3080205@oracle.com> All, The newer WebKit + compiler upgrade has been pushed to 8u-dev and we have done a successful test build on all platforms. Please let me know if you encounter any problems. This will be in 8u60-b09 EA. As I mentioned in my "heads-up" email yesterday, the workflow for FX 8u60 and 9 is changing starting next week. This is captured on the OpenJFX Wiki on the 8u60 [1] and 9 [2] pages (although it could use more detail). The highlights are as follows: * The integration deadline for the 8u60 feature freeze build is 1am Pacific on Monday, Mar 30. * I have done the final pull/merge from 8u-dev to 9-dev. On Monday morning I will manually import any changesets that are pushed to 8u-dev prior to 1am on Monday into 9-dev. * Both the 8u-dev and 9-dev repos will be locked from 1am to 1pm Pacific on Monday. No changes of any kind should be pushed to either repo (other than to fix a broken build) after 1am Pacific Monday until unlocked at 1pm Pacific Monday. This will give me a chance to manually export/import the remaining changes from 8u-dev to 9-dev. * When the repo opens back up at 1pm Pacific, bug fixes should go into 9-dev first and then to 8u-dev -- or else pushed at the same time if they are safe, simple fixes. Enhancements / features go into 9-dev only unless there is an explicit exception approved to backport them to 8u60 (note that API changes for 9 still require approval). Let me know if there are any questions about this. -- Kevin [1] https://wiki.openjdk.java.net/display/OpenJFX/8u60 [2] https://wiki.openjdk.java.net/display/OpenJFX/9 From mikegps1 at gmail.com Fri Mar 27 03:54:24 2015 From: mikegps1 at gmail.com (Mike) Date: Thu, 26 Mar 2015 20:54:24 -0700 Subject: PLEASE READ: Pushing changesets to FX 9-dev and 8u-dev In-Reply-To: <5514CCC6.3080205@oracle.com> References: <5514CCC6.3080205@oracle.com> Message-ID: Does this support webrtc? Sent from my iPhone > On Mar 26, 2015, at 8:21 PM, Kevin Rushforth wrote: > > All, > > The newer WebKit + compiler upgrade has been pushed to 8u-dev and we have done a successful test build on all platforms. Please let me know if you encounter any problems. This will be in 8u60-b09 EA. > > As I mentioned in my "heads-up" email yesterday, the workflow for FX 8u60 and 9 is changing starting next week. This is captured on the OpenJFX Wiki on the 8u60 [1] and 9 [2] pages (although it could use more detail). The highlights are as follows: > > * The integration deadline for the 8u60 feature freeze build is 1am Pacific on Monday, Mar 30. > > * I have done the final pull/merge from 8u-dev to 9-dev. On Monday morning I will manually import any changesets that are pushed to 8u-dev prior to 1am on Monday into 9-dev. > > * Both the 8u-dev and 9-dev repos will be locked from 1am to 1pm Pacific on Monday. No changes of any kind should be pushed to either repo (other than to fix a broken build) after 1am Pacific Monday until unlocked at 1pm Pacific Monday. This will give me a chance to manually export/import the remaining changes from 8u-dev to 9-dev. > > * When the repo opens back up at 1pm Pacific, bug fixes should go into 9-dev first and then to 8u-dev -- or else pushed at the same time if they are safe, simple fixes. Enhancements / features go into 9-dev only unless there is an explicit exception approved to backport them to 8u60 (note that API changes for 9 still require approval). > > Let me know if there are any questions about this. > > -- Kevin > > [1] https://wiki.openjdk.java.net/display/OpenJFX/8u60 > [2] https://wiki.openjdk.java.net/display/OpenJFX/9 > From krueger at lesspain.de Fri Mar 27 06:27:24 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Fri, 27 Mar 2015 07:27:24 +0100 Subject: Packaging a JFX app in a gradle build system In-Reply-To: <0F525D38-9B94-48B3-9C55-48F93419F80E@gmail.com> References: <0F525D38-9B94-48B3-9C55-48F93419F80E@gmail.com> Message-ID: On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer wrote: > I am successfully using the javafx gradle plugin to produce a packaged app > on Windows and Linux. (Thanks Danno!) > I haven't tried much with Mac yet, but I believe it will make an > application bundle. > > That sounds great. I will give it a try on OSX then. > Oracle should be making this part of your day job, Danno. Who do I need > to bribe? :-) > > Absolutely! Easy packaging (i.e. well integrated into a build process), especially if it's cross-platform, is a big thing to make JavaFX more attractive to developers. From navdeepsingh.sidhu95 at gmail.com Fri Mar 27 12:22:21 2015 From: navdeepsingh.sidhu95 at gmail.com (Navdeep Singh Sidhu) Date: Fri, 27 Mar 2015 17:52:21 +0530 Subject: How to use CheckBoxTreeItem instead TreeItem in TreeTable view with progressbar? Message-ID: I am experimenting with JavaFX and I am trying to add a check box Item in tree table, but it looks like it supports only simple tree item. My Code is modified version of [Oracle's TreeTableView Example][1]: public class TreeTableViewSample extends Application implements Runnable { List employees = Arrays.asList( new Employee("Ethan Williams", 30.0), new Employee("Emma Jones", 10.0), new Employee("Michael Brown", 70.0), new Employee("Anna Black", 50.0), new Employee("Rodger York", 20.0), new Employee("Susan Collins", 70.0)); /* private final ImageView depIcon = new ImageView ( new Image(getClass().getResourceAsStream("department.png")) ); */ final CheckBoxTreeItem root = new CheckBoxTreeItem<>(new Employee("Sales Department", 0.0)); final CheckBoxTreeItem root2 = new CheckBoxTreeItem<>(new Employee("Departments", 0.0)); public static void main(String[] args) { Application.launch(TreeTableViewSample.class, args); } @Override public void start(Stage stage) { root.setExpanded(true); employees.stream().forEach((employee) -> { root.getChildren().add(new CheckBoxTreeItem<>(employee)); }); stage.setTitle("Tree Table View Sample"); final Scene scene = new Scene(new Group(), 400, 400); scene.setFill(Color.LIGHTGRAY); Group sceneRoot = (Group) scene.getRoot(); TreeTableColumn empColumn = new TreeTableColumn<>("Employee"); empColumn.setPrefWidth(150); empColumn.setCellValueFactory( (TreeTableColumn.CellDataFeatures param) -> new ReadOnlyStringWrapper(param.getValue().getValue().getName()) ); TreeTableColumn salaryColumn = new TreeTableColumn<>("Salary"); salaryColumn.setPrefWidth(190); /* salaryColumn.setCellValueFactory( (TreeTableColumn.CellDataFeatures param) -> new ReadOnlyDoubleWrapper(param.getValue().getValue().getEmail()) ); */ salaryColumn.setCellFactory(ProgressBarTreeTableCell.forTreeTableColumn()); root2.getChildren().add(root); TreeTableView treeTableView = new TreeTableView<>(root2); treeTableView.getColumns().setAll(empColumn, salaryColumn); sceneRoot.getChildren().add(treeTableView); stage.setScene(scene); stage.show(); ScheduledExecutorService executorService = Executors.newScheduledThreadPool(1); executorService.scheduleAtFixedRate(this, 3, 10, TimeUnit.SECONDS); } @Override public void run() { root2.getValue().setSalary(calcSalary(root)); } public double calcSalary(TreeItem t) { Double salary = 0.0; if (!t.isLeaf()) { ObservableList> al = t.getChildren(); for (int i = 0; i < al.size(); i++) { TreeItem get = al.get(i); salary += calcSalary(get); } t.getValue().setSalary(salary); } return salary += t.getValue().getSalary(); } public class Employee { private SimpleStringProperty name; private SimpleDoubleProperty salary; public SimpleStringProperty nameProperty() { if (name == null) { name = new SimpleStringProperty(this, "name"); } return name; } public SimpleDoubleProperty salaryProperty() { if (salary == null) { salary = new SimpleDoubleProperty(this, "salary"); } return salary; } private Employee(String name, Double salary) { this.name = new SimpleStringProperty(name); this.salary = new SimpleDoubleProperty(salary); } public String getName() { return name.get(); } public void setName(String fName) { name.set(fName); } public Double getSalary() { return salary.get(); } public void setSalary(Double fName) { salary.set(fName); } } } Is there any way i can use checkboxes for tree item in the above example? I am using JavaFx 8. I am also try to create Salary Bars, which can also be used as progressbar for a task and its sub tasks. (Just playing with UI). But don't know how to connect them with the real values of employe, as i guess normal table view is different from tree table view. Thanks ! :) [1]: https://docs.oracle.com/javase/8/javafx/user-interface-tutorial/tree-table-view.htm -- Regards Navdeep Singh Sidhu From vadim.pakhnushev at oracle.com Fri Mar 27 15:37:26 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 27 Mar 2015 18:37:26 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <55157936.2010506@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. And after that there will be new rules in effect regarding pushing to 9-dev first. Happy testing! Thanks, Vadim From swpalmer at gmail.com Fri Mar 27 18:28:26 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 27 Mar 2015 14:28:26 -0400 Subject: ProgressBar has significant leaks Message-ID: I searched the bug database and though ProgressBar leaks have been reported before, they are supposed to be fixed in 8u40. I'm seeing tons of leaks in 8u40. Comparing heap dumps with jvisualvm I see in three minutes that my app has accumulated 11,000 WeakReference and BindingHelperObserver objects that appear to be associated with the ProgressBarSkin. The chain to the GC root looks like this: WeakReference BindingHelperObserver InvalidationListener[] ExpressionHelper$Generic ProgressBarSkin$1 ProgressBarSkin ProgressBar My application needs to run for a long time. (Streaming realtime video - i.e. a TV station broadcast for hours if not weeks at a time...) I suspect this may be a regression in 8u40. I will try to get that confirmed. Scott From swpalmer at gmail.com Fri Mar 27 18:36:34 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 27 Mar 2015 14:36:34 -0400 Subject: ProgressBar has significant leaks In-Reply-To: References: Message-ID: Another chain to the GC root looks like: WeakReference BindingHelperObserver InvalidationListener[] ExpressionHelper$Generic Node$NodeTransformation$2 Node$NodeTransformation StackPane ProgressBarSkin ProgressBar On Fri, Mar 27, 2015 at 2:28 PM, Scott Palmer wrote: > I searched the bug database and though ProgressBar leaks have been > reported before, they are supposed to be fixed in 8u40. I'm seeing tons of > leaks in 8u40. > > Comparing heap dumps with jvisualvm I see in three minutes that my app has > accumulated 11,000 WeakReference and BindingHelperObserver objects that > appear to be associated with the ProgressBarSkin. > > The chain to the GC root looks like this: > > WeakReference > BindingHelperObserver > InvalidationListener[] > ExpressionHelper$Generic > ProgressBarSkin$1 > ProgressBarSkin > ProgressBar > > My application needs to run for a long time. (Streaming realtime video - > i.e. a TV station broadcast for hours if not weeks at a time...) > > I suspect this may be a regression in 8u40. I will try to get that > confirmed. > > Scott > From tomas.mikula at gmail.com Fri Mar 27 19:21:23 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Fri, 27 Mar 2015 15:21:23 -0400 Subject: ProgressBar has significant leaks In-Reply-To: References: Message-ID: Looks like someone is adding weak listeners to ProgressBarSkin$1 in the first case and to Node$NodeTransformation$2 in the second case, but does not bother removing them, relying on the WeakReference to enable their garbage collection. Well, the listeners themselves get garbage collected, but the WeakReferences to them do not, until the property is invalidated. Can you figure out what ProgressBarSkin$1 and Node$NodeTransformation$2 are? These are probably properties that don't change, thus WeakListeners fail to work well with them. You could probably work around the problem by invalidating them occasionally. See also "Problem 2: Memory Leaks" in my post on "The Trouble with Weak Listeners" http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html Tomas On Fri, Mar 27, 2015 at 2:36 PM, Scott Palmer wrote: > Another chain to the GC root looks like: > > WeakReference > BindingHelperObserver > InvalidationListener[] > ExpressionHelper$Generic > Node$NodeTransformation$2 > Node$NodeTransformation > StackPane > ProgressBarSkin > ProgressBar > > > On Fri, Mar 27, 2015 at 2:28 PM, Scott Palmer wrote: > >> I searched the bug database and though ProgressBar leaks have been >> reported before, they are supposed to be fixed in 8u40. I'm seeing tons of >> leaks in 8u40. >> >> Comparing heap dumps with jvisualvm I see in three minutes that my app has >> accumulated 11,000 WeakReference and BindingHelperObserver objects that >> appear to be associated with the ProgressBarSkin. >> >> The chain to the GC root looks like this: >> >> WeakReference >> BindingHelperObserver >> InvalidationListener[] >> ExpressionHelper$Generic >> ProgressBarSkin$1 >> ProgressBarSkin >> ProgressBar >> >> My application needs to run for a long time. (Streaming realtime video - >> i.e. a TV station broadcast for hours if not weeks at a time...) >> >> I suspect this may be a regression in 8u40. I will try to get that >> confirmed. >> >> Scott >> From morris.meyer at oracle.com Fri Mar 27 19:39:01 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Fri, 27 Mar 2015 15:39:01 -0400 Subject: [8u-dev] Review request: RT-38836: JDK crash on Mac 10.10 with very large stage Message-ID: <5515B1D5.9040402@oracle.com> Kevin, David and Chien, Please review this patch, which fixes RT-38836 (a critical) and RT-23363 (a medium). It clips the frame to screen size in Glass-Mac in a similar fashion to what happens in Glass-Windows. Thanks much, --morris WEBREV - http://cr.openjdk.java.net/~morris/RT-38836.01/ JIRA - https://javafx-jira.kenai.com/browse/RT-38836 From Sergey.Bylokhov at oracle.com Fri Mar 27 20:05:12 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 27 Mar 2015 23:05:12 +0300 Subject: [8u-dev] Review request: RT-38836: JDK crash on Mac 10.10 with very large stage In-Reply-To: <5515B1D5.9040402@oracle.com> References: <5515B1D5.9040402@oracle.com> Message-ID: <5515B7F8.5070808@oracle.com> Hi, Morris. Just curiously, does it mean that after the fix, there is no way to maximize the window on two monitors in multi-monitors configuration? Does this issue affects an applets? Seems that on Windows the clipping on the screen bounds is a default native behavior. 27.03.15 22:39, Morris Meyer wrote: > Kevin, David and Chien, > > Please review this patch, which fixes RT-38836 (a critical) and > RT-23363 (a medium). It clips the frame to screen size in Glass-Mac > in a similar fashion to what happens in Glass-Windows. > > Thanks much, > > --morris > > WEBREV - http://cr.openjdk.java.net/~morris/RT-38836.01/ > JIRA - https://javafx-jira.kenai.com/browse/RT-38836 -- Best regards, Sergey. From morris.meyer at oracle.com Fri Mar 27 20:08:58 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Fri, 27 Mar 2015 16:08:58 -0400 Subject: [8u-dev] Review request: RT-38836: JDK crash on Mac 10.10 with very large stage In-Reply-To: <5515B7F8.5070808@oracle.com> References: <5515B1D5.9040402@oracle.com> <5515B7F8.5070808@oracle.com> Message-ID: <5515B8DA.3050805@oracle.com> I don't have a two monitor display setup for the Mac platform. Will run CircleApp1, CircleApp2, CircleApp3 and MaxStage in applet on both Windows 8.1 and Mac and report back. --mm On 3/27/15 4:05 PM, Sergey Bylokhov wrote: > Hi, Morris. > Just curiously, does it mean that after the fix, there is no way to > maximize the window on two monitors in multi-monitors configuration? > Does this issue affects an applets? Seems that on Windows the clipping > on the screen bounds is a default native behavior. > > 27.03.15 22:39, Morris Meyer wrote: >> Kevin, David and Chien, >> >> Please review this patch, which fixes RT-38836 (a critical) and >> RT-23363 (a medium). It clips the frame to screen size in Glass-Mac >> in a similar fashion to what happens in Glass-Windows. >> >> Thanks much, >> >> --morris >> >> WEBREV - http://cr.openjdk.java.net/~morris/RT-38836.01/ >> JIRA - https://javafx-jira.kenai.com/browse/RT-38836 > > From krueger at lesspain.de Fri Mar 27 20:52:12 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Fri, 27 Mar 2015 21:52:12 +0100 Subject: Canvas performance on Mac OS Message-ID: Hi, I have a super-simple animation implemented using AnimationTimer and Canvas where the canvas just performs a few draw operations, i.e. fills the screen with a color and then draws and fills 2-3 circles and I have already observed that each drawing operation I add, results in significant CPU load (e.g. when I draw < 10 arcs in addition to the circles, the CPU load goes up to 30-40% on a Mac Book Pro for a Canvas size of 600x600(!). Now I tested the animation in full screen mode (only with a few circles) and playback is unusable for a serious application (very choppy). Is 2D canvas performance known to be very bad on Mac or am I doing something wrong? Are there workarounds for this? Thanks, Robert From james.graham at oracle.com Fri Mar 27 20:58:43 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 27 Mar 2015 13:58:43 -0700 Subject: Canvas performance on Mac OS In-Reply-To: References: Message-ID: <5515C483.9030901@oracle.com> Hi Robert, Please file a Jira issue with a simple test case. Arcs are handled as a generalized shape rather than via a predetermined shader, but it shouldn't be that slow. Something else may be going on. Another test might be to replace the arcs with rectangles or ellipses and see if the performance changes... ...jim On 3/27/15 1:52 PM, Robert Kr?ger wrote: > Hi, > > I have a super-simple animation implemented using AnimationTimer and Canvas > where the canvas just performs a few draw operations, i.e. fills the screen > with a color and then draws and fills 2-3 circles and I have already > observed that each drawing operation I add, results in significant CPU load > (e.g. when I draw < 10 arcs in addition to the circles, the CPU load goes > up to 30-40% on a Mac Book Pro for a Canvas size of 600x600(!). > > Now I tested the animation in full screen mode (only with a few circles) > and playback is unusable for a serious application (very choppy). Is 2D > canvas performance known to be very bad on Mac or am I doing something > wrong? Are there workarounds for this? > > Thanks, > > Robert > From krueger at lesspain.de Fri Mar 27 21:10:20 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Fri, 27 Mar 2015 22:10:20 +0100 Subject: Canvas performance on Mac OS In-Reply-To: <5515C483.9030901@oracle.com> References: <5515C483.9030901@oracle.com> Message-ID: The bad full screen performance is without the arcs. It is just one call to fillRect, two to strokeOval and one to fillOval, that's all. I will build a simple test case and file an issue. On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham wrote: > Hi Robert, > > Please file a Jira issue with a simple test case. Arcs are handled as a > generalized shape rather than via a predetermined shader, but it shouldn't > be that slow. Something else may be going on. > > Another test might be to replace the arcs with rectangles or ellipses and > see if the performance changes... > > ...jim > > > On 3/27/15 1:52 PM, Robert Kr?ger wrote: > >> Hi, >> >> I have a super-simple animation implemented using AnimationTimer and >> Canvas >> where the canvas just performs a few draw operations, i.e. fills the >> screen >> with a color and then draws and fills 2-3 circles and I have already >> observed that each drawing operation I add, results in significant CPU >> load >> (e.g. when I draw < 10 arcs in addition to the circles, the CPU load goes >> up to 30-40% on a Mac Book Pro for a Canvas size of 600x600(!). >> >> Now I tested the animation in full screen mode (only with a few circles) >> and playback is unusable for a serious application (very choppy). Is 2D >> canvas performance known to be very bad on Mac or am I doing something >> wrong? Are there workarounds for this? >> >> Thanks, >> >> Robert >> >> -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From tobi at ultramixer.com Fri Mar 27 21:26:59 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 27 Mar 2015 22:26:59 +0100 Subject: Canvas performance on Mac OS In-Reply-To: References: <5515C483.9030901@oracle.com> Message-ID: In my opinion the whole graphics performance on MacOSX isn?t good at all with JavaFX?. > Am 27.03.2015 um 22:10 schrieb Robert Kr?ger : > > The bad full screen performance is without the arcs. It is just one call to > fillRect, two to strokeOval and one to fillOval, that's all. I will build a > simple test case and file an issue. > > On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham wrote: > >> Hi Robert, >> >> Please file a Jira issue with a simple test case. Arcs are handled as a >> generalized shape rather than via a predetermined shader, but it shouldn't >> be that slow. Something else may be going on. >> >> Another test might be to replace the arcs with rectangles or ellipses and >> see if the performance changes... >> >> ...jim >> >> >> On 3/27/15 1:52 PM, Robert Kr?ger wrote: >> >>> Hi, >>> >>> I have a super-simple animation implemented using AnimationTimer and >>> Canvas >>> where the canvas just performs a few draw operations, i.e. fills the >>> screen >>> with a color and then draws and fills 2-3 circles and I have already >>> observed that each drawing operation I add, results in significant CPU >>> load >>> (e.g. when I draw < 10 arcs in addition to the circles, the CPU load goes >>> up to 30-40% on a Mac Book Pro for a Canvas size of 600x600(!). >>> >>> Now I tested the animation in full screen mode (only with a few circles) >>> and playback is unusable for a serious application (very choppy). Is 2D >>> canvas performance known to be very bad on Mac or am I doing something >>> wrong? Are there workarounds for this? >>> >>> Thanks, >>> >>> Robert >>> >>> > > > -- > Robert Kr?ger > Managing Partner > Lesspain GmbH & Co. KG > > www.lesspain-software.com From cnewland at chrisnewland.com Fri Mar 27 22:08:40 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Fri, 27 Mar 2015 22:08:40 -0000 Subject: Canvas performance on Mac OS In-Reply-To: References: <5515C483.9030901@oracle.com> Message-ID: Possibly related: I can reproduce a massive (90%) performance drop on OSX between drawing a wireframe polygon on a Canvas using a series of gc.strokeLine(double x1, double y1, double x2, double y2) commands versus using a single gc.strokePolygon(double[] xPoints, double[] yPoints, int count) command. Creating the polygons manually with strokeLine() is significantly faster using the ES2Pipeline on OSX. This is reproducible in a little GitHub JavaFX benchmarking project I've created: https://github.com/chriswhocodes/DemoFX Build with ant Run with: # use strokeLine ./run.sh -c 5000 -m line result: 60 (sixty) fps # use strokePolygon ./run.sh -c 5000 -m poly result: 6 (six) fps System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM / Radeon 6970M 1024MB Looking at the code paths in javafx.scene.canvas.GraphicsContext: gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, NGCanvas.STROKE_LINE) gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, true, NGCanvas.STROKE_PATH) which involves significantly more work with adding to and flushing a GrowableDataBuffer. I've not had time to dig any deeper than this but it's surely a bug when building a poly manually is 10x faster than using the convenience method. Cheers, Chris On Fri, March 27, 2015 21:26, Tobias Bley wrote: > In my opinion the whole graphics performance on MacOSX isn???t good at > all with JavaFX???. > > >> Am 27.03.2015 um 22:10 schrieb Robert Kr??ger : >> >> >> The bad full screen performance is without the arcs. It is just one >> call to fillRect, two to strokeOval and one to fillOval, that's all. I >> will build a simple test case and file an issue. >> >> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham >> wrote: >> >> >>> Hi Robert, >>> >>> >>> Please file a Jira issue with a simple test case. Arcs are handled >>> as a generalized shape rather than via a predetermined shader, but it >>> shouldn't be that slow. Something else may be going on. >>> >>> Another test might be to replace the arcs with rectangles or ellipses >>> and see if the performance changes... >>> >>> ...jim >>> >>> >>> >>> On 3/27/15 1:52 PM, Robert Kr??ger wrote: >>> >>> >>>> Hi, >>>> >>>> >>>> I have a super-simple animation implemented using AnimationTimer >>>> and Canvas >>>> where the canvas just performs a few draw operations, i.e. fills the >>>> screen with a color and then draws and fills 2-3 circles and I have >>>> already observed that each drawing operation I add, results in >>>> significant CPU load (e.g. when I draw < 10 arcs in addition to the >>>> circles, the CPU load goes up to 30-40% on a Mac Book Pro for a >>>> Canvas size of 600x600(!). >>>> >>>> >>>> Now I tested the animation in full screen mode (only with a few >>>> circles) and playback is unusable for a serious application (very >>>> choppy). Is 2D canvas performance known to be very bad on Mac or am >>>> I doing something >>>> wrong? Are there workarounds for this? >>>> >>>> Thanks, >>>> >>>> >>>> Robert >>>> >>>> >>>> >> >> >> -- >> Robert Kr??ger >> Managing Partner >> Lesspain GmbH & Co. KG >> >> >> www.lesspain-software.com > > From adam at adamish.com Sat Mar 28 08:13:11 2015 From: adam at adamish.com (Adam Granger) Date: Sat, 28 Mar 2015 07:13:11 -0100 Subject: Unit testing recommendations for JavaFX Message-ID: <9779ff142bfd1ac932db8dc711764fd1.squirrel@webmail.adamish.com> Following migration to JavaFX I've been looking into a unit testing... Possible solutions - "home brew" - just code up a few basic methods like "find a node with given selector within given timeout", then build tests using those using JUnit / Mockito. Also used @Rule approach from http://stackoverflow.com/a/18988752/898289 for simple tests which didn't require any asynchronous behaviour. I was previously using this approach until discovered TestFX - Jemmy - seems well documented. Last release 4 years ago - no updates since JavaFX 2.2? Is this because its so good, or does anyone know whether it has been scrapped? Any plans to update for JavaFX 8? https://jemmy.java.net/ - TestFX - just started dabbling with this - seems a lot better maintained that Jemmy, however the new release 4 is still alpha and documentation is a little sparse - https://github.com/TestFX/TestFX - Squish by FrogLogic - commercial product, but only seems suitable for integration level testing. - http://doc.froglogic.com/squish/5.1/tutorial-getting-started-java_fx.html I'm interested in any recommendations this group might have or experiences of solutions I've mentioned... What solution do OpenJFX / other large FX developments use for unit testing? Many thanks, Adam. From matthieu at brouillard.fr Sat Mar 28 09:06:41 2015 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Sat, 28 Mar 2015 10:06:41 +0100 Subject: Unit testing recommendations for JavaFX In-Reply-To: <9779ff142bfd1ac932db8dc711764fd1.squirrel@webmail.adamish.com> References: <9779ff142bfd1ac932db8dc711764fd1.squirrel@webmail.adamish.com> Message-ID: Hi Adam, At AGFA Healthcare we have been using TestFX for more than a year and a half now. Regards, Matthieu On Sat, Mar 28, 2015 at 9:13 AM, Adam Granger wrote: > Following migration to JavaFX I've been looking into a unit testing... > Possible solutions > > - "home brew" - just code up a few basic methods like "find a node with > given selector within given timeout", then build tests using those using > JUnit / Mockito. Also used @Rule approach from > http://stackoverflow.com/a/18988752/898289 for simple tests which didn't > require any asynchronous behaviour. I was previously using this approach > until discovered TestFX > > - Jemmy - seems well documented. Last release 4 years ago - no updates > since JavaFX 2.2? Is this because its so good, or does anyone know > whether it has been scrapped? Any plans to update for JavaFX 8? > https://jemmy.java.net/ > > - TestFX - just started dabbling with this - seems a lot better > maintained that Jemmy, however the new release 4 is still alpha and > documentation is a little sparse - https://github.com/TestFX/TestFX > > - Squish by FrogLogic - commercial product, but only seems suitable for > integration level testing. - > http://doc.froglogic.com/squish/5.1/tutorial-getting-started-java_fx.html > > I'm interested in any recommendations this group might have or experiences > of solutions I've mentioned... What solution do OpenJFX / other large FX > developments use for unit testing? > > Many thanks, > > Adam. > > From krueger at lesspain.de Sat Mar 28 10:06:05 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Sat, 28 Mar 2015 11:06:05 +0100 Subject: Canvas performance on Mac OS In-Reply-To: References: <5515C483.9030901@oracle.com> Message-ID: This is consistent with what I am observing. Is this something that Oracle is aware of? Looking at Jira, I don't see that anyone is working on this: https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%20labels%20in%20(performance) Given that one of the One of the main reasons to use JFX for me is to be able to develop with one code base for at least OSX and Windows and the official statement what JavaFX is for, i.e. "JavaFX is a set of graphics and media packages that enables developers to design, create, test, debug, and deploy rich client applications that operate consistently across diverse platforms" and the fact that this is clearly not the case currently (8u40) as soon as I do something else than simple forms, I run into performance/quality problems on the Mac, I am a bit unsure what to make of all that. Is Mac OSX a second-class citizen as far as dev resources are concerned? Tobi and Chris, have you filed Jira Issues on Mac graphics performance that can be tracked? I will file an issue with a simple test case and hope for the best. On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland wrote: > Possibly related: > > I can reproduce a massive (90%) performance drop on OSX between drawing a > wireframe polygon on a Canvas using a series of gc.strokeLine(double x1, > double y1, double x2, double y2) commands versus using a single > gc.strokePolygon(double[] xPoints, double[] yPoints, int count) command. > > Creating the polygons manually with strokeLine() is significantly faster > using the ES2Pipeline on OSX. > > This is reproducible in a little GitHub JavaFX benchmarking project I've > created: https://github.com/chriswhocodes/DemoFX > > Build with ant > > Run with: > > # use strokeLine > ./run.sh -c 5000 -m line > result: 60 (sixty) fps > > # use strokePolygon > ./run.sh -c 5000 -m poly > result: 6 (six) fps > > System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM / Radeon > 6970M 1024MB > > Looking at the code paths in javafx.scene.canvas.GraphicsContext: > > gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, NGCanvas.STROKE_LINE) > > gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, true, > NGCanvas.STROKE_PATH) which involves significantly more work with adding > to and flushing a GrowableDataBuffer. > > I've not had time to dig any deeper than this but it's surely a bug when > building a poly manually is 10x faster than using the convenience method. > > Cheers, > > Chris > > On Fri, March 27, 2015 21:26, Tobias Bley wrote: > > In my opinion the whole graphics performance on MacOSX isn???t good at > > all with JavaFX???. > > > > > >> Am 27.03.2015 um 22:10 schrieb Robert Kr??ger : > >> > >> > >> The bad full screen performance is without the arcs. It is just one > >> call to fillRect, two to strokeOval and one to fillOval, that's all. I > >> will build a simple test case and file an issue. > >> > >> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham > >> wrote: > >> > >> > >>> Hi Robert, > >>> > >>> > >>> Please file a Jira issue with a simple test case. Arcs are handled > >>> as a generalized shape rather than via a predetermined shader, but it > >>> shouldn't be that slow. Something else may be going on. > >>> > >>> Another test might be to replace the arcs with rectangles or ellipses > >>> and see if the performance changes... > >>> > >>> ...jim > >>> > >>> > >>> > >>> On 3/27/15 1:52 PM, Robert Kr??ger wrote: > >>> > >>> > >>>> Hi, > >>>> > >>>> > >>>> I have a super-simple animation implemented using AnimationTimer > >>>> and Canvas > >>>> where the canvas just performs a few draw operations, i.e. fills the > >>>> screen with a color and then draws and fills 2-3 circles and I have > >>>> already observed that each drawing operation I add, results in > >>>> significant CPU load (e.g. when I draw < 10 arcs in addition to the > >>>> circles, the CPU load goes up to 30-40% on a Mac Book Pro for a > >>>> Canvas size of 600x600(!). > >>>> > >>>> > >>>> Now I tested the animation in full screen mode (only with a few > >>>> circles) and playback is unusable for a serious application (very > >>>> choppy). Is 2D canvas performance known to be very bad on Mac or am > >>>> I doing something > >>>> wrong? Are there workarounds for this? > >>>> > >>>> Thanks, > >>>> > >>>> > >>>> Robert > >>>> > >>>> > >>>> > >> > >> > >> -- > >> Robert Kr??ger > >> Managing Partner > >> Lesspain GmbH & Co. KG > >> > >> > >> www.lesspain-software.com > > > > > > > -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From cnewland at chrisnewland.com Sat Mar 28 10:22:55 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Sat, 28 Mar 2015 10:22:55 -0000 Subject: Canvas performance on Mac OS In-Reply-To: References: <5515C483.9030901@oracle.com> Message-ID: Hi Robert, I've not filed a Jira yet as I was hoping to find time to investigate thoroughly but when I saw your question I thought I'd better add my findings. I believe the issue is in the ES2Pipeline as if I run with -Dprism.order=sw then strokePolygon outperforms the series of strokeLine commands as expected: java -cp target/DemoFX.jar -Dprism.order=sw com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result: 44fps java -cp target/DemoFX.jar -Dprism.order=sw com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result: 60fps Will see if I can find the root cause as I've got plenty more examples where ES2Pipeline performs horribly on my Mac which should have no problem throwing around a few thousand polys. I realise there's a *lot* of indirection involved in making JavaFX support such a wide range of underlying graphics systems but I do think there's a bug here. Will file a Jira if I can contribute a bit more than "feels slow" ;) Cheers, Chris On Sat, March 28, 2015 10:06, Robert Kr??ger wrote: > This is consistent with what I am observing. Is this something that > Oracle > is aware of? Looking at Jira, I don't see that anyone is working on this: > > https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%22In% > 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%20la > bels%20in%20(performance) > > Given that one of the One of the main reasons to use JFX for me is to be > able to develop with one code base for at least OSX and Windows and the > official statement what JavaFX is for, i.e. > > "JavaFX is a set of graphics and media packages that enables developers > to design, create, test, debug, and deploy rich client applications that > operate consistently across diverse platforms" > > and the fact that this is clearly not the case currently (8u40) as soon > as I do something else than simple forms, I run into performance/quality > problems on the Mac, I am a bit unsure what to make of all that. Is Mac > OSX > a second-class citizen as far as dev resources are concerned? > > Tobi and Chris, have you filed Jira Issues on Mac graphics performance > that can be tracked? > > I will file an issue with a simple test case and hope for the best. > > > > > > On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland > > wrote: > > >> Possibly related: >> >> >> I can reproduce a massive (90%) performance drop on OSX between drawing >> a wireframe polygon on a Canvas using a series of gc.strokeLine(double >> x1, double y1, double x2, double y2) commands versus using a single >> gc.strokePolygon(double[] xPoints, double[] yPoints, int count) >> command. >> >> Creating the polygons manually with strokeLine() is significantly >> faster using the ES2Pipeline on OSX. >> >> This is reproducible in a little GitHub JavaFX benchmarking project >> I've >> created: https://github.com/chriswhocodes/DemoFX >> >> >> Build with ant >> >> >> Run with: >> >> >> # use strokeLine >> ./run.sh -c 5000 -m line >> result: 60 (sixty) fps >> >> >> # use strokePolygon >> ./run.sh -c 5000 -m poly >> result: 6 (six) fps >> >> >> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM / >> Radeon >> 6970M 1024MB >> >> >> Looking at the code paths in javafx.scene.canvas.GraphicsContext: >> >> >> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, NGCanvas.STROKE_LINE) >> >> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, true, >> NGCanvas.STROKE_PATH) which involves significantly more work with >> adding to and flushing a GrowableDataBuffer. >> >> I've not had time to dig any deeper than this but it's surely a bug >> when building a poly manually is 10x faster than using the convenience >> method. >> >> Cheers, >> >> >> Chris >> >> >> On Fri, March 27, 2015 21:26, Tobias Bley wrote: >> >>> In my opinion the whole graphics performance on MacOSX isn????????t >>> good at all with JavaFX???????. >>> >>> >>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger >>>> : >>>> >>>> >>>> >>>> The bad full screen performance is without the arcs. It is just one >>>> call to fillRect, two to strokeOval and one to fillOval, that's >>>> all. I will build a simple test case and file an issue. >>>> >>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham >>>> >>>> wrote: >>>> >>>> >>>> >>>>> Hi Robert, >>>>> >>>>> >>>>> >>>>> Please file a Jira issue with a simple test case. Arcs are >>>>> handled as a generalized shape rather than via a predetermined >>>>> shader, but it shouldn't be that slow. Something else may be >>>>> going on. >>>>> >>>>> Another test might be to replace the arcs with rectangles or >>>>> ellipses and see if the performance changes... >>>>> >>>>> ...jim >>>>> >>>>> >>>>> >>>>> >>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> I have a super-simple animation implemented using >>>>>> AnimationTimer >>>>>> and Canvas where the canvas just performs a few draw operations, >>>>>> i.e. fills the screen with a color and then draws and fills 2-3 >>>>>> circles and I have already observed that each drawing operation >>>>>> I add, results in >>>>>> significant CPU load (e.g. when I draw < 10 arcs in addition to >>>>>> the circles, the CPU load goes up to 30-40% on a Mac Book Pro >>>>>> for a Canvas size of 600x600(!). >>>>>> >>>>>> >>>>>> >>>>>> Now I tested the animation in full screen mode (only with a few >>>>>> circles) and playback is unusable for a serious application >>>>>> (very >>>>>> choppy). Is 2D canvas performance known to be very bad on Mac or >>>>>> am I doing something >>>>>> wrong? Are there workarounds for this? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> Robert >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Robert Kr????ger >>>> Managing Partner >>>> Lesspain GmbH & Co. KG >>>> >>>> >>>> >>>> www.lesspain-software.com >>> >>> >> >> >> > > > -- > Robert Kr??ger > Managing Partner > Lesspain GmbH & Co. KG > > > www.lesspain-software.com > From krueger at lesspain.de Sat Mar 28 10:46:35 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Sat, 28 Mar 2015 11:46:35 +0100 Subject: Canvas performance on Mac OS In-Reply-To: References: <5515C483.9030901@oracle.com> Message-ID: On Sat, Mar 28, 2015 at 11:22 AM, Chris Newland wrote: > Hi Robert, > > I've not filed a Jira yet as I was hoping to find time to investigate > thoroughly but when I saw your question I thought I'd better add my > findings. > > I believe the issue is in the ES2Pipeline as if I run with > -Dprism.order=sw then strokePolygon outperforms the series of strokeLine > commands as expected: > > java -cp target/DemoFX.jar -Dprism.order=sw > com.chrisnewland.demofx.DemoFXApplication -c 500 -m line > Result: 44fps > > java -cp target/DemoFX.jar -Dprism.order=sw > com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly > Result: 60fps > > Will see if I can find the root cause as I've got plenty more examples > where ES2Pipeline performs horribly on my Mac which should have no problem > throwing around a few thousand polys. > > I realise there's a *lot* of indirection involved in making JavaFX support > such a wide range of underlying graphics systems but I do think there's a > bug here. > > Will file a Jira if I can contribute a bit more than "feels slow" ;) > > Cheers, > > Chris > > Great, thanks! From krueger at lesspain.de Sat Mar 28 11:59:30 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Sat, 28 Mar 2015 12:59:30 +0100 Subject: Canvas performance on Mac OS In-Reply-To: References: <5515C483.9030901@oracle.com> Message-ID: I have filed this now: https://javafx-jira.kenai.com/browse/RT-40377 On Sat, Mar 28, 2015 at 11:06 AM, Robert Kr?ger wrote: > This is consistent with what I am observing. Is this something that Oracle > is aware of? Looking at Jira, I don't see that anyone is working on this: > > > https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%20labels%20in%20(performance) > > Given that one of the One of the main reasons to use JFX for me is to be > able to develop with one code base for at least OSX and Windows and the > official statement what JavaFX is for, i.e. > > "JavaFX is a set of graphics and media packages that enables developers to > design, create, test, debug, and deploy rich client applications that > operate consistently across diverse platforms" > > and the fact that this is clearly not the case currently (8u40) as soon as > I do something else than simple forms, I run into performance/quality > problems on the Mac, I am a bit unsure what to make of all that. Is Mac OSX > a second-class citizen as far as dev resources are concerned? > > Tobi and Chris, have you filed Jira Issues on Mac graphics performance > that can be tracked? > > I will file an issue with a simple test case and hope for the best. > > > > > On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland > wrote: > >> Possibly related: >> >> I can reproduce a massive (90%) performance drop on OSX between drawing a >> wireframe polygon on a Canvas using a series of gc.strokeLine(double x1, >> double y1, double x2, double y2) commands versus using a single >> gc.strokePolygon(double[] xPoints, double[] yPoints, int count) command. >> >> Creating the polygons manually with strokeLine() is significantly faster >> using the ES2Pipeline on OSX. >> >> This is reproducible in a little GitHub JavaFX benchmarking project I've >> created: https://github.com/chriswhocodes/DemoFX >> >> Build with ant >> >> Run with: >> >> # use strokeLine >> ./run.sh -c 5000 -m line >> result: 60 (sixty) fps >> >> # use strokePolygon >> ./run.sh -c 5000 -m poly >> result: 6 (six) fps >> >> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM / Radeon >> 6970M 1024MB >> >> Looking at the code paths in javafx.scene.canvas.GraphicsContext: >> >> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, NGCanvas.STROKE_LINE) >> >> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, true, >> NGCanvas.STROKE_PATH) which involves significantly more work with adding >> to and flushing a GrowableDataBuffer. >> >> I've not had time to dig any deeper than this but it's surely a bug when >> building a poly manually is 10x faster than using the convenience method. >> >> Cheers, >> >> Chris >> >> On Fri, March 27, 2015 21:26, Tobias Bley wrote: >> > In my opinion the whole graphics performance on MacOSX isn???t good at >> > all with JavaFX???. >> > >> > >> >> Am 27.03.2015 um 22:10 schrieb Robert Kr??ger : >> >> >> >> >> >> The bad full screen performance is without the arcs. It is just one >> >> call to fillRect, two to strokeOval and one to fillOval, that's all. I >> >> will build a simple test case and file an issue. >> >> >> >> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham >> >> wrote: >> >> >> >> >> >>> Hi Robert, >> >>> >> >>> >> >>> Please file a Jira issue with a simple test case. Arcs are handled >> >>> as a generalized shape rather than via a predetermined shader, but it >> >>> shouldn't be that slow. Something else may be going on. >> >>> >> >>> Another test might be to replace the arcs with rectangles or ellipses >> >>> and see if the performance changes... >> >>> >> >>> ...jim >> >>> >> >>> >> >>> >> >>> On 3/27/15 1:52 PM, Robert Kr??ger wrote: >> >>> >> >>> >> >>>> Hi, >> >>>> >> >>>> >> >>>> I have a super-simple animation implemented using AnimationTimer >> >>>> and Canvas >> >>>> where the canvas just performs a few draw operations, i.e. fills the >> >>>> screen with a color and then draws and fills 2-3 circles and I have >> >>>> already observed that each drawing operation I add, results in >> >>>> significant CPU load (e.g. when I draw < 10 arcs in addition to the >> >>>> circles, the CPU load goes up to 30-40% on a Mac Book Pro for a >> >>>> Canvas size of 600x600(!). >> >>>> >> >>>> >> >>>> Now I tested the animation in full screen mode (only with a few >> >>>> circles) and playback is unusable for a serious application (very >> >>>> choppy). Is 2D canvas performance known to be very bad on Mac or am >> >>>> I doing something >> >>>> wrong? Are there workarounds for this? >> >>>> >> >>>> Thanks, >> >>>> >> >>>> >> >>>> Robert >> >>>> >> >>>> >> >>>> >> >> >> >> >> >> -- >> >> Robert Kr??ger >> >> Managing Partner >> >> Lesspain GmbH & Co. KG >> >> >> >> >> >> www.lesspain-software.com >> > >> > >> >> >> > > > -- > Robert Kr?ger > Managing Partner > Lesspain GmbH & Co. KG > > www.lesspain-software.com > -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From krueger at lesspain.de Sat Mar 28 15:10:55 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Sat, 28 Mar 2015 16:10:55 +0100 Subject: Packaging a JFX app in a gradle build system In-Reply-To: References: <0F525D38-9B94-48B3-9C55-48F93419F80E@gmail.com> Message-ID: Which repository is the master? Bitbucket or github? I just saw a posting by someone mentioning that it is also on github. On Fri, Mar 27, 2015 at 7:27 AM, Robert Kr?ger wrote: > On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer wrote: > >> I am successfully using the javafx gradle plugin to produce a packaged >> app on Windows and Linux. (Thanks Danno!) >> I haven't tried much with Mac yet, but I believe it will make an >> application bundle. >> >> > That sounds great. I will give it a try on OSX then. > > >> Oracle should be making this part of your day job, Danno. Who do I need >> to bribe? :-) >> >> > Absolutely! Easy packaging (i.e. well integrated into a build process), > especially if it's cross-platform, is a big thing to make JavaFX more > attractive to developers. > -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From swpalmer at gmail.com Sat Mar 28 15:30:00 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 28 Mar 2015 11:30:00 -0400 Subject: Packaging a JFX app in a gradle build system In-Reply-To: References: <0F525D38-9B94-48B3-9C55-48F93419F80E@gmail.com> Message-ID: <00C4B332-9258-4D05-86B2-F9B4B6D41885@gmail.com> I believe the bitbucket repo is the main page. At least the bintray page points to it. Scott > On Mar 28, 2015, at 11:10 AM, Robert Kr?ger wrote: > > Which repository is the master? Bitbucket or github? I just saw a posting by someone mentioning that it is also on github. > >> On Fri, Mar 27, 2015 at 7:27 AM, Robert Kr?ger wrote: >>> On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer wrote: >>> I am successfully using the javafx gradle plugin to produce a packaged app on Windows and Linux. (Thanks Danno!) >>> I haven't tried much with Mac yet, but I believe it will make an application bundle. >> >> That sounds great. I will give it a try on OSX then. >> >>> Oracle should be making this part of your day job, Danno. Who do I need to bribe? :-) >> >> Absolutely! Easy packaging (i.e. well integrated into a build process), especially if it's cross-platform, is a big thing to make JavaFX more attractive to developers. > > > > -- > Robert Kr?ger > Managing Partner > Lesspain GmbH & Co. KG > > www.lesspain-software.com From krueger at lesspain.de Sat Mar 28 16:56:24 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Sat, 28 Mar 2015 17:56:24 +0100 Subject: Packaging a JFX app in a gradle build system In-Reply-To: <00C4B332-9258-4D05-86B2-F9B4B6D41885@gmail.com> References: <0F525D38-9B94-48B3-9C55-48F93419F80E@gmail.com> <00C4B332-9258-4D05-86B2-F9B4B6D41885@gmail.com> Message-ID: thanks. On Sat, Mar 28, 2015 at 4:30 PM, Scott Palmer wrote: > I believe the bitbucket repo is the main page. At least the bintray page > points to it. > > Scott > > On Mar 28, 2015, at 11:10 AM, Robert Kr?ger wrote: > > Which repository is the master? Bitbucket or github? I just saw a posting > by someone mentioning that it is also on github. > > On Fri, Mar 27, 2015 at 7:27 AM, Robert Kr?ger > wrote: > >> On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer >> wrote: >> >>> I am successfully using the javafx gradle plugin to produce a packaged >>> app on Windows and Linux. (Thanks Danno!) >>> I haven't tried much with Mac yet, but I believe it will make an >>> application bundle. >>> >>> >> That sounds great. I will give it a try on OSX then. >> >> >>> Oracle should be making this part of your day job, Danno. Who do I need >>> to bribe? :-) >>> >>> >> Absolutely! Easy packaging (i.e. well integrated into a build process), >> especially if it's cross-platform, is a big thing to make JavaFX more >> attractive to developers. >> > > > > -- > Robert Kr?ger > Managing Partner > Lesspain GmbH & Co. KG > > www.lesspain-software.com > > -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From tbee at tbee.org Sat Mar 28 19:45:04 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 28 Mar 2015 20:45:04 +0100 Subject: Unit testing recommendations for JavaFX In-Reply-To: <9779ff142bfd1ac932db8dc711764fd1.squirrel@webmail.adamish.com> References: <9779ff142bfd1ac932db8dc711764fd1.squirrel@webmail.adamish.com> Message-ID: <551704C0.2030208@tbee.org> JFXtras uses TestFX (3), very pleasant, highly recommended. On 28-3-2015 09:13, Adam Granger wrote: > Following migration to JavaFX I've been looking into a unit testing... > Possible solutions > > - "home brew" - just code up a few basic methods like "find a node with > given selector within given timeout", then build tests using those using > JUnit / Mockito. Also used @Rule approach from > http://stackoverflow.com/a/18988752/898289 for simple tests which didn't > require any asynchronous behaviour. I was previously using this approach > until discovered TestFX > > - Jemmy - seems well documented. Last release 4 years ago - no updates > since JavaFX 2.2? Is this because its so good, or does anyone know > whether it has been scrapped? Any plans to update for JavaFX 8? > https://jemmy.java.net/ > > - TestFX - just started dabbling with this - seems a lot better > maintained that Jemmy, however the new release 4 is still alpha and > documentation is a little sparse - https://github.com/TestFX/TestFX > > - Squish by FrogLogic - commercial product, but only seems suitable for > integration level testing. - > http://doc.froglogic.com/squish/5.1/tutorial-getting-started-java_fx.html > > I'm interested in any recommendations this group might have or experiences > of solutions I've mentioned... What solution do OpenJFX / other large FX > developments use for unit testing? > > Many thanks, > > Adam. > From swpalmer at gmail.com Sun Mar 29 16:05:56 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 29 Mar 2015 12:05:56 -0400 Subject: Here's a interest one: Layout has stopped happening in my app Message-ID: Running 8u40: I was running a long-term test to reproduce a leak that I reported earlier with ProgressBarSkin accumulating WeakReferences via some binding related to Invalidation listeners. My app has been running for 43 hours. It is currently running fine and the memory stats show the heap size has grown to the max 512MB but actual usage is only 175MB after I force a GC with jvisualvm. However logs show that about 20 hours ago this happened: Exception in thread "JavaFX Application Thread" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Unknown Source) at java.util.ArrayList.grow(Unknown Source) at java.util.ArrayList.ensureExplicitCapacity(Unknown Source) at java.util.ArrayList.ensureCapacityInternal(Unknown Source) at java.util.ArrayList.add(Unknown Source) at com.sun.javafx.scene.control.skin.VirtualFlow$ArrayLinkedList.addLast(Unknown Source) at com.sun.javafx.scene.control.skin.VirtualFlow.addToPile(Unknown Source) at com.sun.javafx.scene.control.skin.VirtualFlow.addAllToPile(Unknown Source) at com.sun.javafx.scene.control.skin.VirtualFlow.layoutChildren(Unknown Source) at javafx.scene.Parent.layout(Unknown Source) at javafx.scene.Parent.layout(Unknown Source) at javafx.scene.Parent.layout(Unknown Source) at javafx.scene.Parent.layout(Unknown Source) at javafx.scene.Parent.layout(Unknown Source) at javafx.scene.Parent.layout(Unknown Source) at javafx.scene.Parent.layout(Unknown Source) at javafx.scene.Parent.layout(Unknown Source) at javafx.scene.Parent.layout(Unknown Source) at javafx.scene.Parent.layout(Unknown Source) at javafx.scene.Scene.doLayoutPass(Unknown Source) at javafx.scene.Scene$ScenePulseListener.pulse(Unknown Source) at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Unknown Source) at com.sun.javafx.tk.Toolkit$$Lambda$115/380219021.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Unknown Source) at com.sun.javafx.tk.Toolkit.firePulse(Unknown Source) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(Unknown Source) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(Unknown Source) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(Unknown Source) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$49/1241099547.run(Unknown Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(Unknown Source) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) (That is the ONLY problem logged, none of my own app logic encountered a problem.) The result appears to be that JavaFX is stuck thinking a layout is in progress and refuses to schedule any new ones. Painting and controls are working fine, except anything requiring a layout pass isn't happening. I suspect that perhaps the ProgressBar leak caused this, and that all those WeakReferences got cleaned up in somewhere in the process, but I can't be sure. At this point jvisualvm is throwing ArrayIndexOutOfBoundsException when I try to open a heap dump, but I was able to save them and load them back after re-launching jvisualvm. It isn't clear if ProgressBarSkin is doing anything weird. After diff'ing heap dumps the bulk of the change in terms of instance count is in com.sun.javafx.css.PseuoClassState instances and HashMap related classes. In any case, I think some protection against an exception (or Error in this case) disabling all future layout is in order. I know technically "errors" aren't supposed to be so recoverable... but my app is still running perfectly normally with the exception of layout, and it has plenty of free heap now. Scott From jonathan.giles at oracle.com Sun Mar 29 20:28:24 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 30 Mar 2015 09:28:24 +1300 Subject: ProgressBar has significant leaks In-Reply-To: References: Message-ID: <55186068.5070104@oracle.com> If you can file a jira issue with a test case I would very happily look into this issue. Thanks, -- Jonathan On 28/03/2015 7:28 a.m., Scott Palmer wrote: > I searched the bug database and though ProgressBar leaks have been reported > before, they are supposed to be fixed in 8u40. I'm seeing tons of leaks in > 8u40. > > Comparing heap dumps with jvisualvm I see in three minutes that my app has > accumulated 11,000 WeakReference and BindingHelperObserver objects that > appear to be associated with the ProgressBarSkin. > > The chain to the GC root looks like this: > > WeakReference > BindingHelperObserver > InvalidationListener[] > ExpressionHelper$Generic > ProgressBarSkin$1 > ProgressBarSkin > ProgressBar > > My application needs to run for a long time. (Streaming realtime video - > i.e. a TV station broadcast for hours if not weeks at a time...) > > I suspect this may be a regression in 8u40. I will try to get that > confirmed. > > Scott From tom.schindl at bestsolution.at Mon Mar 30 10:58:38 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 30 Mar 2015 12:58:38 +0200 Subject: Doubts on KeyCode Message-ID: <55192C5E.7080308@bestsolution.at> hi, suppose you have the following code: > package application; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.TextField; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class Main extends Application { > @Override > public void start(Stage primaryStage) { > try { > BorderPane root = new BorderPane(); > Scene scene = new Scene(root, 400, 400); > > TextField f = new TextField(); > f.setOnKeyReleased( e -> { > System.err.println(e.getCode()); > }); > root.setCenter(f); > > primaryStage.setScene(scene); > primaryStage.show(); > } catch (Exception e) { > e.printStackTrace(); > } > } > > public static void main(String[] args) { > launch(args); > } > } For default ASCII-Chars like a, b, c, ... I get the correct KeyCode but e.g. for +, -, ... the information is totally bogus. Please note I get the correct keyCode when pressing the NumPad char but e.g. CLOSE_BRACKET when pressing "+" on my keyboard. If I'm not completely mistaken the KeyCode defintion for the current + is the one for the keypad "+" and the one for the ordinary + is missing? This means that the definition: PLUS(0x0209, "Plus") has to be PLUS(0x0209, "Plus", KeyCodeClass.KEYPAD) What I can not explain is why the keyboard "+" (ascii-code 43) maps to "]" (ascii-code 93) from a native-keyevent to KeyCode happens in Glass-Layer. Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From swpalmer at gmail.com Mon Mar 30 11:19:32 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 30 Mar 2015 07:19:32 -0400 Subject: Doubts on KeyCode In-Reply-To: <55192C5E.7080308@bestsolution.at> References: <55192C5E.7080308@bestsolution.at> Message-ID: If I recall correctly there is one keycode named PLUS and another named ADD. One of them refers to the numeric keypad. Scott > On Mar 30, 2015, at 6:58 AM, Tom Schindl wrote: > > hi, > > suppose you have the following code: > >> package application; >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.TextField; >> import javafx.scene.layout.BorderPane; >> import javafx.stage.Stage; >> >> public class Main extends Application { >> @Override >> public void start(Stage primaryStage) { >> try { >> BorderPane root = new BorderPane(); >> Scene scene = new Scene(root, 400, 400); >> >> TextField f = new TextField(); >> f.setOnKeyReleased( e -> { >> System.err.println(e.getCode()); >> }); >> root.setCenter(f); >> >> primaryStage.setScene(scene); >> primaryStage.show(); >> } catch (Exception e) { >> e.printStackTrace(); >> } >> } >> >> public static void main(String[] args) { >> launch(args); >> } >> } > > For default ASCII-Chars like a, b, c, ... I get the correct KeyCode but > e.g. for +, -, ... the information is totally bogus. Please note I get > the correct keyCode when pressing the NumPad char but e.g. CLOSE_BRACKET > when pressing "+" on my keyboard. > > If I'm not completely mistaken the KeyCode defintion for the current + > is the one for the keypad "+" and the one for the ordinary + is missing? > > This means that the definition: > > PLUS(0x0209, "Plus") > > has to be > > PLUS(0x0209, "Plus", KeyCodeClass.KEYPAD) > > What I can not explain is why the keyboard "+" (ascii-code 43) maps to > "]" (ascii-code 93) from a native-keyevent to KeyCode happens in > Glass-Layer. > > Tom > > -- > Thomas Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From hastebrot at gmail.com Mon Mar 30 11:56:04 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Mon, 30 Mar 2015 13:56:04 +0200 Subject: Doubts on KeyCode In-Reply-To: References: <55192C5E.7080308@bestsolution.at> Message-ID: Hi, >What I can not explain is why the keyboard "+" (ascii-code 43) maps to "]" (ascii-code 93) from a native-keyevent to KeyCode happens in Glass-Layer. Hmm, the "+" key on a german keyboard layout [1] is actually "]" on the us keyboard layout [2]. But when I type "+" on my german keyboard with german layout activated on Windows it outputs "+" as unicode string and "PLUS" for the KeyCode. With this code: textField.setOnKeyPressed((event) -> { System.out.println(event.getText()); System.out.println(event.getCode()); }); [1] http://upload.wikimedia.org/wikipedia/commons/thumb/3/36/KB_Germany.svg/800px-KB_Germany.svg.png [2] http://upload.wikimedia.org/wikipedia/commons/thumb/5/51/KB_United_States-NoAltGr.svg/800px-KB_United_States-NoAltGr.svg.png On Mon, Mar 30, 2015 at 1:19 PM, Scott Palmer wrote: > If I recall correctly there is one keycode named PLUS and another named > ADD. One of them refers to the numeric keypad. > > Scott > > > On Mar 30, 2015, at 6:58 AM, Tom Schindl > wrote: > > > > hi, > > > > suppose you have the following code: > > > >> package application; > >> > >> import javafx.application.Application; > >> import javafx.scene.Scene; > >> import javafx.scene.control.TextField; > >> import javafx.scene.layout.BorderPane; > >> import javafx.stage.Stage; > >> > >> public class Main extends Application { > >> @Override > >> public void start(Stage primaryStage) { > >> try { > >> BorderPane root = new BorderPane(); > >> Scene scene = new Scene(root, 400, 400); > >> > >> TextField f = new TextField(); > >> f.setOnKeyReleased( e -> { > >> System.err.println(e.getCode()); > >> }); > >> root.setCenter(f); > >> > >> primaryStage.setScene(scene); > >> primaryStage.show(); > >> } catch (Exception e) { > >> e.printStackTrace(); > >> } > >> } > >> > >> public static void main(String[] args) { > >> launch(args); > >> } > >> } > > > > For default ASCII-Chars like a, b, c, ... I get the correct KeyCode but > > e.g. for +, -, ... the information is totally bogus. Please note I get > > the correct keyCode when pressing the NumPad char but e.g. CLOSE_BRACKET > > when pressing "+" on my keyboard. > > > > If I'm not completely mistaken the KeyCode defintion for the current + > > is the one for the keypad "+" and the one for the ordinary + is missing? > > > > This means that the definition: > > > > PLUS(0x0209, "Plus") > > > > has to be > > > > PLUS(0x0209, "Plus", KeyCodeClass.KEYPAD) > > > > What I can not explain is why the keyboard "+" (ascii-code 43) maps to > > "]" (ascii-code 93) from a native-keyevent to KeyCode happens in > > Glass-Layer. > > > > Tom > > > > -- > > Thomas Schindl, CTO > > BestSolution.at EDV Systemhaus GmbH > > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > > http://www.bestsolution.at/ > > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > From tom.schindl at bestsolution.at Mon Mar 30 12:04:14 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 30 Mar 2015 14:04:14 +0200 Subject: Doubts on KeyCode In-Reply-To: References: <55192C5E.7080308@bestsolution.at> Message-ID: <55193BBE.20807@bestsolution.at> Hi, Yes there is an ADD and a PLUS but both of them claim that they are NOT NUMPAD keyCodes. ADD(0x6B, "Add"), PLUS(0x0209, "Plus"), >From the location I think ADD should be the a keypad type, when I type + on my keypad I get ADD. Tom On 30.03.15 13:19, Scott Palmer wrote: > If I recall correctly there is one keycode named PLUS and another named ADD. One of them refers to the numeric keypad. > > Scott > >> On Mar 30, 2015, at 6:58 AM, Tom Schindl wrote: >> >> hi, >> >> suppose you have the following code: >> >>> package application; >>> >>> import javafx.application.Application; >>> import javafx.scene.Scene; >>> import javafx.scene.control.TextField; >>> import javafx.scene.layout.BorderPane; >>> import javafx.stage.Stage; >>> >>> public class Main extends Application { >>> @Override >>> public void start(Stage primaryStage) { >>> try { >>> BorderPane root = new BorderPane(); >>> Scene scene = new Scene(root, 400, 400); >>> >>> TextField f = new TextField(); >>> f.setOnKeyReleased( e -> { >>> System.err.println(e.getCode()); >>> }); >>> root.setCenter(f); >>> >>> primaryStage.setScene(scene); >>> primaryStage.show(); >>> } catch (Exception e) { >>> e.printStackTrace(); >>> } >>> } >>> >>> public static void main(String[] args) { >>> launch(args); >>> } >>> } >> >> For default ASCII-Chars like a, b, c, ... I get the correct KeyCode but >> e.g. for +, -, ... the information is totally bogus. Please note I get >> the correct keyCode when pressing the NumPad char but e.g. CLOSE_BRACKET >> when pressing "+" on my keyboard. >> >> If I'm not completely mistaken the KeyCode defintion for the current + >> is the one for the keypad "+" and the one for the ordinary + is missing? >> >> This means that the definition: >> >> PLUS(0x0209, "Plus") >> >> has to be >> >> PLUS(0x0209, "Plus", KeyCodeClass.KEYPAD) >> >> What I can not explain is why the keyboard "+" (ascii-code 43) maps to >> "]" (ascii-code 93) from a native-keyevent to KeyCode happens in >> Glass-Layer. >> >> Tom >> >> -- >> Thomas Schindl, CTO >> BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck >> http://www.bestsolution.at/ >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From tom.schindl at bestsolution.at Mon Mar 30 12:06:48 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 30 Mar 2015 14:06:48 +0200 Subject: Doubts on KeyCode In-Reply-To: References: <55192C5E.7080308@bestsolution.at> Message-ID: <55193C58.7010303@bestsolution.at> Hi, I think I'll start to understand, when I type ] on a german keyboard I have to use a modifier key (on OS-X ALT) but the keycode without modifier is the one for the +. Tom On 30.03.15 13:56, Benjamin Gudehus wrote: > Hi, > >>What I can not explain is why the keyboard "+" (ascii-code 43) maps to > "]" (ascii-code 93) from a native-keyevent to KeyCode happens in > Glass-Layer. > > Hmm, the "+" key on a german keyboard layout [1] is actually "]" on the > us keyboard layout [2]. > > But when I type "+" on my german keyboard with german layout activated > on Windows it outputs "+" as unicode string and "PLUS" for the KeyCode. > With this code: > > textField.setOnKeyPressed((event) -> { > System.out.println(event.getText()); > System.out.println(event.getCode()); > }); > > [1] > http://upload.wikimedia.org/wikipedia/commons/thumb/3/36/KB_Germany.svg/800px-KB_Germany.svg.png > [2] > http://upload.wikimedia.org/wikipedia/commons/thumb/5/51/KB_United_States-NoAltGr.svg/800px-KB_United_States-NoAltGr.svg.png > > On Mon, Mar 30, 2015 at 1:19 PM, Scott Palmer > wrote: > > If I recall correctly there is one keycode named PLUS and another > named ADD. One of them refers to the numeric keypad. > > Scott > > > On Mar 30, 2015, at 6:58 AM, Tom Schindl > > > wrote: > > > > hi, > > > > suppose you have the following code: > > > >> package application; > >> > >> import javafx.application.Application; > >> import javafx.scene.Scene; > >> import javafx.scene.control.TextField; > >> import javafx.scene.layout.BorderPane; > >> import javafx.stage.Stage; > >> > >> public class Main extends Application { > >> @Override > >> public void start(Stage primaryStage) { > >> try { > >> BorderPane root = new BorderPane(); > >> Scene scene = new Scene(root, 400, 400); > >> > >> TextField f = new TextField(); > >> f.setOnKeyReleased( e -> { > >> System.err.println(e.getCode()); > >> }); > >> root.setCenter(f); > >> > >> primaryStage.setScene(scene); > >> primaryStage.show(); > >> } catch (Exception e) { > >> e.printStackTrace(); > >> } > >> } > >> > >> public static void main(String[] args) { > >> launch(args); > >> } > >> } > > > > For default ASCII-Chars like a, b, c, ... I get the correct > KeyCode but > > e.g. for +, -, ... the information is totally bogus. Please note I get > > the correct keyCode when pressing the NumPad char but e.g. > CLOSE_BRACKET > > when pressing "+" on my keyboard. > > > > If I'm not completely mistaken the KeyCode defintion for the current + > > is the one for the keypad "+" and the one for the ordinary + is > missing? > > > > This means that the definition: > > > > PLUS(0x0209, "Plus") > > > > has to be > > > > PLUS(0x0209, "Plus", KeyCodeClass.KEYPAD) > > > > What I can not explain is why the keyboard "+" (ascii-code 43) maps to > > "]" (ascii-code 93) from a native-keyevent to KeyCode happens in > > Glass-Layer. > > > > Tom > > > > -- > > Thomas Schindl, CTO > > BestSolution.at EDV Systemhaus GmbH > > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > > http://www.bestsolution.at/ > > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From hastebrot at gmail.com Mon Mar 30 12:28:17 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Mon, 30 Mar 2015 14:28:17 +0200 Subject: Unit testing recommendations for JavaFX In-Reply-To: <551704C0.2030208@tbee.org> References: <9779ff142bfd1ac932db8dc711764fd1.squirrel@webmail.adamish.com> <551704C0.2030208@tbee.org> Message-ID: There are also Automaton, which is similar to TestFX and supports Swing as well, and MavinFX, which is especially useful to assert Properties. TestFX allows simple and clean testing without much boiler-plate code. When we took JavaFX into consideration for a migration of our geographical information system to Swing to first thing we looked for was a testing framework. With a background with the FEST-Swing testing framework TestFX convinced us, because even testing new dialogs looked a lot easier than with FEST. I can't say much about Squish. It seems that it follows an approach with a recorder for user interactions which I guess won't allow creation of test-cases before the actual production code is written. --Benjamin On Sat, Mar 28, 2015 at 8:45 PM, Tom Eugelink wrote: > JFXtras uses TestFX (3), very pleasant, highly recommended. > > > > On 28-3-2015 09:13, Adam Granger wrote: > >> Following migration to JavaFX I've been looking into a unit testing... >> Possible solutions >> >> - "home brew" - just code up a few basic methods like "find a node with >> given selector within given timeout", then build tests using those using >> JUnit / Mockito. Also used @Rule approach from >> http://stackoverflow.com/a/18988752/898289 for simple tests which didn't >> require any asynchronous behaviour. I was previously using this approach >> until discovered TestFX >> >> - Jemmy - seems well documented. Last release 4 years ago - no updates >> since JavaFX 2.2? Is this because its so good, or does anyone know >> whether it has been scrapped? Any plans to update for JavaFX 8? >> https://jemmy.java.net/ >> >> - TestFX - just started dabbling with this - seems a lot better >> maintained that Jemmy, however the new release 4 is still alpha and >> documentation is a little sparse - https://github.com/TestFX/TestFX >> >> - Squish by FrogLogic - commercial product, but only seems suitable for >> integration level testing. - >> http://doc.froglogic.com/squish/5.1/tutorial-getting-started-java_fx.html >> >> I'm interested in any recommendations this group might have or experiences >> of solutions I've mentioned... What solution do OpenJFX / other large FX >> developments use for unit testing? >> >> Many thanks, >> >> Adam. >> >> > From ngalarneau at ABINITIO.COM Mon Mar 30 12:47:33 2015 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Mon, 30 Mar 2015 08:47:33 -0400 Subject: Unit testing recommendations for JavaFX In-Reply-To: References: <9779ff142bfd1ac932db8dc711764fd1.squirrel@webmail.adamish.com> <551704C0.2030208@tbee.org> Message-ID: TestFX is nice. Another option is QF-Test. Neil From: Benjamin Gudehus To: Tom Eugelink , Cc: "openjfx-dev at openjdk.java.net" Date: 03/30/2015 08:29 AM Subject: Re: Unit testing recommendations for JavaFX Sent by: "openjfx-dev" There are also Automaton, which is similar to TestFX and supports Swing as well, and MavinFX, which is especially useful to assert Properties. TestFX allows simple and clean testing without much boiler-plate code. When we took JavaFX into consideration for a migration of our geographical information system to Swing to first thing we looked for was a testing framework. With a background with the FEST-Swing testing framework TestFX convinced us, because even testing new dialogs looked a lot easier than with FEST. I can't say much about Squish. It seems that it follows an approach with a recorder for user interactions which I guess won't allow creation of test-cases before the actual production code is written. --Benjamin On Sat, Mar 28, 2015 at 8:45 PM, Tom Eugelink wrote: > JFXtras uses TestFX (3), very pleasant, highly recommended. > > > > On 28-3-2015 09:13, Adam Granger wrote: > >> Following migration to JavaFX I've been looking into a unit testing... >> Possible solutions >> >> - "home brew" - just code up a few basic methods like "find a node with >> given selector within given timeout", then build tests using those using >> JUnit / Mockito. Also used @Rule approach from >> http://stackoverflow.com/a/18988752/898289 for simple tests which didn't >> require any asynchronous behaviour. I was previously using this approach >> until discovered TestFX >> >> - Jemmy - seems well documented. Last release 4 years ago - no updates >> since JavaFX 2.2? Is this because its so good, or does anyone know >> whether it has been scrapped? Any plans to update for JavaFX 8? >> https://jemmy.java.net/ >> >> - TestFX - just started dabbling with this - seems a lot better >> maintained that Jemmy, however the new release 4 is still alpha and >> documentation is a little sparse - https://github.com/TestFX/TestFX >> >> - Squish by FrogLogic - commercial product, but only seems suitable for >> integration level testing. - >> http://doc.froglogic.com/squish/5.1/tutorial-getting-started-java_fx.html >> >> I'm interested in any recommendations this group might have or experiences >> of solutions I've mentioned... What solution do OpenJFX / other large FX >> developments use for unit testing? >> >> Many thanks, >> >> Adam. >> >> > NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From David.Hill at Oracle.com Mon Mar 30 18:47:08 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 30 Mar 2015 14:47:08 -0400 Subject: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2 In-Reply-To: References: <5512FF65.8030700@oracle.com> <551314CC.6030300@Oracle.com> Message-ID: <55199A2C.7090005@Oracle.com> On 3/26/15, 7:03 PM, Fabrizio Giudici wrote: > On Thu, 26 Mar 2015 19:40:41 +0100, Fabrizio Giudici wrote: > >> The mouse is ok, it was probably a connection fault. The keyboard navigation of buttons is still not working - still investigating. > > The keyboard is definitely not working with my app, even with a simple TextField. It does work with Ensemble8 and the same jre. My app works fine in Mac OS X. Sounds tricky... > > Is there any logging option I can activate to investigate whether keystrokes are just not received, or they get lost somewhere? > Are you getting anything on the console ? Because monocle uses udev, you need to run as root or change some permissions stuff around. Dave -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From danno.ferrin at oracle.com Mon Mar 30 19:04:21 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Mon, 30 Mar 2015 13:04:21 -0600 Subject: Packaging a JFX app in a gradle build system In-Reply-To: <00C4B332-9258-4D05-86B2-F9B4B6D41885@gmail.com> References: <0F525D38-9B94-48B3-9C55-48F93419F80E@gmail.com> <00C4B332-9258-4D05-86B2-F9B4B6D41885@gmail.com> Message-ID: Yes, bitbucket is the main repo, github is a mirror (currently out of date). (sorry for the late response, just got back from a long spring break). > On Mar 28, 2015, at 9:30 AM, Scott Palmer wrote: > > I believe the bitbucket repo is the main page. At least the bintray page points to it. > > Scott > > On Mar 28, 2015, at 11:10 AM, Robert Kr?ger > wrote: > >> Which repository is the master? Bitbucket or github? I just saw a posting by someone mentioning that it is also on github. >> >> On Fri, Mar 27, 2015 at 7:27 AM, Robert Kr?ger > wrote: >> On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer > wrote: >> I am successfully using the javafx gradle plugin to produce a packaged app on Windows and Linux. (Thanks Danno!) >> I haven't tried much with Mac yet, but I believe it will make an application bundle. >> >> >> That sounds great. I will give it a try on OSX then. >> >> Oracle should be making this part of your day job, Danno. Who do I need to bribe? :-) >> >> >> Absolutely! Easy packaging (i.e. well integrated into a build process), especially if it's cross-platform, is a big thing to make JavaFX more attractive to developers. >> >> >> >> -- >> Robert Kr?ger >> Managing Partner >> Lesspain GmbH & Co. KG >> >> www.lesspain-software.com From james.graham at oracle.com Mon Mar 30 19:04:50 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 30 Mar 2015 12:04:50 -0700 Subject: Canvas performance on Mac OS In-Reply-To: References: <5515C483.9030901@oracle.com> Message-ID: <55199E52.9090503@oracle.com> Hi Chris, drawLine() is a very simple primitive that can be optimized with a GPU shader. It either looks like a (potentially rotated) rectangle or a rounded rect - and we have optimized shaders for both cases. A large number of drawLine() calls turns into simply accumulating a large vertex list and uploading it to the GPU with an appropriate shader which is very fast. drawPolygon() is a very complex operation that involves things like: - dealing with line joins between segments that don't exist for drawLine() - dealing with only rendering common points of intersection once To handle all of that complexity we have to involve a rasterizer that takes the entire collection of lines, analyzes the stroke attributes and interactions and computes a coverage mask for each pixel in the region. We do that in software currently for all pipelines. For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path rasterization. For the SW pipeline, drawLine is a simplified case of drawPolygon and so the overhead of lots of calls to drawLine() dominates its performance. I would expect ES2 to blow the SW pipeline out of the water with drawLine() performance (as long as there are no additional rendering primitives interspersed in the set of lines). But, both should be on the same footing for the drawPolygon case. Does the ES2 pipeline compare similarly (hopefully better than) the SW pipeline for the polygon case? One thing I noticed is that we have no optimized case for drawLine() on the SW pipeline. It generates a path containing a single MOVETO and LINETO and feeds it to the generalized path rasterizer when it could instead compute the rounded/square rectangle and render it more directly. If we added that support then I'd expect the SW pipeline to perform the set of drawLine calls faster than drawPolygon as well... ...jim On 3/28/15 3:22 AM, Chris Newland wrote: > Hi Robert, > > I've not filed a Jira yet as I was hoping to find time to investigate > thoroughly but when I saw your question I thought I'd better add my > findings. > > I believe the issue is in the ES2Pipeline as if I run with > -Dprism.order=sw then strokePolygon outperforms the series of strokeLine > commands as expected: > > java -cp target/DemoFX.jar -Dprism.order=sw > com.chrisnewland.demofx.DemoFXApplication -c 500 -m line > Result: 44fps > > java -cp target/DemoFX.jar -Dprism.order=sw > com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly > Result: 60fps > > Will see if I can find the root cause as I've got plenty more examples > where ES2Pipeline performs horribly on my Mac which should have no problem > throwing around a few thousand polys. > > I realise there's a *lot* of indirection involved in making JavaFX support > such a wide range of underlying graphics systems but I do think there's a > bug here. > > Will file a Jira if I can contribute a bit more than "feels slow" ;) > > Cheers, > > Chris > > On Sat, March 28, 2015 10:06, Robert Kr??ger wrote: >> This is consistent with what I am observing. Is this something that >> Oracle >> is aware of? Looking at Jira, I don't see that anyone is working on this: >> >> https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%22In% >> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%20la >> bels%20in%20(performance) >> >> Given that one of the One of the main reasons to use JFX for me is to be >> able to develop with one code base for at least OSX and Windows and the >> official statement what JavaFX is for, i.e. >> >> "JavaFX is a set of graphics and media packages that enables developers >> to design, create, test, debug, and deploy rich client applications that >> operate consistently across diverse platforms" >> >> and the fact that this is clearly not the case currently (8u40) as soon >> as I do something else than simple forms, I run into performance/quality >> problems on the Mac, I am a bit unsure what to make of all that. Is Mac >> OSX >> a second-class citizen as far as dev resources are concerned? >> >> Tobi and Chris, have you filed Jira Issues on Mac graphics performance >> that can be tracked? >> >> I will file an issue with a simple test case and hope for the best. >> >> >> >> >> >> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland >> >> wrote: >> >> >>> Possibly related: >>> >>> >>> I can reproduce a massive (90%) performance drop on OSX between drawing >>> a wireframe polygon on a Canvas using a series of gc.strokeLine(double >>> x1, double y1, double x2, double y2) commands versus using a single >>> gc.strokePolygon(double[] xPoints, double[] yPoints, int count) >>> command. >>> >>> Creating the polygons manually with strokeLine() is significantly >>> faster using the ES2Pipeline on OSX. >>> >>> This is reproducible in a little GitHub JavaFX benchmarking project >>> I've >>> created: https://github.com/chriswhocodes/DemoFX >>> >>> >>> Build with ant >>> >>> >>> Run with: >>> >>> >>> # use strokeLine >>> ./run.sh -c 5000 -m line >>> result: 60 (sixty) fps >>> >>> >>> # use strokePolygon >>> ./run.sh -c 5000 -m poly >>> result: 6 (six) fps >>> >>> >>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM / >>> Radeon >>> 6970M 1024MB >>> >>> >>> Looking at the code paths in javafx.scene.canvas.GraphicsContext: >>> >>> >>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, NGCanvas.STROKE_LINE) >>> >>> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, true, >>> NGCanvas.STROKE_PATH) which involves significantly more work with >>> adding to and flushing a GrowableDataBuffer. >>> >>> I've not had time to dig any deeper than this but it's surely a bug >>> when building a poly manually is 10x faster than using the convenience >>> method. >>> >>> Cheers, >>> >>> >>> Chris >>> >>> >>> On Fri, March 27, 2015 21:26, Tobias Bley wrote: >>> >>>> In my opinion the whole graphics performance on MacOSX isn????????t >>>> good at all with JavaFX???????. >>>> >>>> >>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger >>>>> : >>>>> >>>>> >>>>> >>>>> The bad full screen performance is without the arcs. It is just one >>>>> call to fillRect, two to strokeOval and one to fillOval, that's >>>>> all. I will build a simple test case and file an issue. >>>>> >>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> Hi Robert, >>>>>> >>>>>> >>>>>> >>>>>> Please file a Jira issue with a simple test case. Arcs are >>>>>> handled as a generalized shape rather than via a predetermined >>>>>> shader, but it shouldn't be that slow. Something else may be >>>>>> going on. >>>>>> >>>>>> Another test might be to replace the arcs with rectangles or >>>>>> ellipses and see if the performance changes... >>>>>> >>>>>> ...jim >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have a super-simple animation implemented using >>>>>>> AnimationTimer >>>>>>> and Canvas where the canvas just performs a few draw operations, >>>>>>> i.e. fills the screen with a color and then draws and fills 2-3 >>>>>>> circles and I have already observed that each drawing operation >>>>>>> I add, results in >>>>>>> significant CPU load (e.g. when I draw < 10 arcs in addition to >>>>>>> the circles, the CPU load goes up to 30-40% on a Mac Book Pro >>>>>>> for a Canvas size of 600x600(!). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Now I tested the animation in full screen mode (only with a few >>>>>>> circles) and playback is unusable for a serious application >>>>>>> (very >>>>>>> choppy). Is 2D canvas performance known to be very bad on Mac or >>>>>>> am I doing something >>>>>>> wrong? Are there workarounds for this? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Robert Kr????ger >>>>> Managing Partner >>>>> Lesspain GmbH & Co. KG >>>>> >>>>> >>>>> >>>>> www.lesspain-software.com >>>> >>>> >>> >>> >>> >> >> >> -- >> Robert Kr??ger >> Managing Partner >> Lesspain GmbH & Co. KG >> >> >> www.lesspain-software.com >> > > From james.graham at oracle.com Mon Mar 30 19:26:00 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 30 Mar 2015 12:26:00 -0700 Subject: Canvas performance on Mac OS In-Reply-To: <55199E52.9090503@oracle.com> References: <5515C483.9030901@oracle.com> <55199E52.9090503@oracle.com> Message-ID: <5519A348.5090808@oracle.com> On 3/30/15 12:04 PM, Jim Graham wrote: > drawPolygon() is a very complex operation that involves things like: > > - dealing with only rendering common points of intersection once An example of the distinction here - try a test case where you execute the exact same diagonal line primitive 1,000 times on top of itself (identical coordinates for all of them). Then change the example to use a Polygon that goes from point A to point B and back, over itself 1,000 times. The result of all of those lines will have jagged edges even though the lines themselves are antialiased because the partially filled pixels along the edges slowly accumulate opacity until their carefully blended edges get lost in the accumulated error. The result of the polygon will be identical to just drawing an antialiased line from point A to point B because it is turned into a single coverage result by the software rasterizer. Another similar example - set an opacity of 0.1 on all of those rendering calls. The (multi-)drawLine example will look like an opaque line of 1.0 opacity, but the polygon will still look like it has an opacity of 0.1 because the coverages are accumulated across the entire polygon before any rendering occurs and so each pixel is only blended once... ...jim From kevin.rushforth at oracle.com Mon Mar 30 20:31:09 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Mar 2015 13:31:09 -0700 Subject: 9-dev and 8u-dev unlocked + reminder about pushing changesets Message-ID: <5519B28D.8050709@oracle.com> The 9-dev and 8u-dev repos are unlocked. As a reminder, please note the following. All changesets that were pushed to 8u-dev prior to 1am this morning are already in 9-dev. Starting now, bug fixes go into 9-dev first and then to 8u-dev -- or else pushed at the same time if they are safe, simple fixes. Enhancements / features go into 9-dev only unless there is an explicit exception approved to backport them to 8u60 (note that API changes for 9 still require approval). See the following Wiki pages: https://wiki.openjdk.java.net/display/OpenJFX/8u60 https://wiki.openjdk.java.net/display/OpenJFX/9 Let me know if there are any questions about this. -- Kevin From danno.ferrin at oracle.com Mon Mar 30 22:11:58 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Mon, 30 Mar 2015 16:11:58 -0600 Subject: Review Request: RT-39975 - AppCDS support for packager Message-ID: <771E6A76-4080-4349-AA9C-F4514EE00E02@oracle.com> Kevin, Chris, please review jira: https://javafx-jira.kenai.com/browse/RT-39975 webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/ From chris.bensen at oracle.com Mon Mar 30 22:52:04 2015 From: chris.bensen at oracle.com (Chris Bensen) Date: Mon, 30 Mar 2015 15:52:04 -0700 Subject: Review Request: RT-39975 - AppCDS support for packager In-Reply-To: <771E6A76-4080-4349-AA9C-F4514EE00E02@oracle.com> References: <771E6A76-4080-4349-AA9C-F4514EE00E02@oracle.com> Message-ID: <3A70A1E8-F892-480E-941D-024819FC14FB@oracle.com> +1 On Mar 30, 2015, at 3:11 PM, Danno Ferrin wrote: > Kevin, Chris, please review > > jira: https://javafx-jira.kenai.com/browse/RT-39975 > webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/ From mike at plan99.net Tue Mar 31 11:41:38 2015 From: mike at plan99.net (Mike Hearn) Date: Tue, 31 Mar 2015 13:41:38 +0200 Subject: Review Request: RT-39975 - AppCDS support for packager In-Reply-To: <3A70A1E8-F892-480E-941D-024819FC14FB@oracle.com> References: <771E6A76-4080-4349-AA9C-F4514EE00E02@oracle.com> <3A70A1E8-F892-480E-941D-024819FC14FB@oracle.com> Message-ID: The bug is restricted - intentional? I'm guessing this is class data sharing and would make startup of packaged apps faster? On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen wrote: > +1 > > On Mar 30, 2015, at 3:11 PM, Danno Ferrin wrote: > > > Kevin, Chris, please review > > > > jira: https://javafx-jira.kenai.com/browse/RT-39975 > > webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/ > > From chris.bensen at oracle.com Tue Mar 31 13:59:04 2015 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 31 Mar 2015 06:59:04 -0700 Subject: Review Request: RT-39975 - AppCDS support for packager In-Reply-To: References: <771E6A76-4080-4349-AA9C-F4514EE00E02@oracle.com> <3A70A1E8-F892-480E-941D-024819FC14FB@oracle.com> Message-ID: Correct! On Mar 31, 2015, at 4:41 AM, Mike Hearn wrote: > The bug is restricted - intentional? > > I'm guessing this is class data sharing and would make startup of packaged apps faster? > > On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen wrote: > +1 > > On Mar 30, 2015, at 3:11 PM, Danno Ferrin wrote: > > > Kevin, Chris, please review > > > > jira: https://javafx-jira.kenai.com/browse/RT-39975 > > webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/ > > From herve.girod at gmail.com Tue Mar 31 15:36:54 2015 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Tue, 31 Mar 2015 17:36:54 +0200 Subject: Setting hover by the API Message-ID: <8900DBF2-6E8B-49B3-AFC9-D5C0E1CA0205@gmail.com> Hello, We have a use case where we need to set a kind of bounding box around Nodes to be able to select them easily by touch. In our case we use an interactive transparent Pane containing the Nodes (which are set as transparent to mouse events). We also need to handle correctly the hover state for example. However, as there is no way to set the hover property on a Node by the API, we use the inherit value for the properties we want to set in the Node. We did not see any other way to pass the "pseudo-state" to the Nodes themselves. Is there any other way we did not see, or is there a simpler way than by using this trick on the CSS? Herv? Sent from my iPhone From tom.schindl at bestsolution.at Tue Mar 31 18:55:33 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 31 Mar 2015 20:55:33 +0200 Subject: What are the plans for Java9? Message-ID: <551AEDA5.8070006@bestsolution.at> Hi, Are there any official plans already for Java9? One of the major pain points I see is that the java-packager does not support to set a splash-screen and also ignores the -splash argument who works when launching with java ... . Another very obvious thing at least on all the windows machine I tried JavaFX is a black area while resizing stages this makes things look unprofessional. A very special request thing is WebGL support Webkit a customer ask me for but I guess this is a though thing todo because on windows we only have DirectX. Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From phidias51 at gmail.com Tue Mar 31 19:29:53 2015 From: phidias51 at gmail.com (Mark Fortner) Date: Tue, 31 Mar 2015 12:29:53 -0700 Subject: What are the plans for Java9? In-Reply-To: <551AEDA5.8070006@bestsolution.at> References: <551AEDA5.8070006@bestsolution.at> Message-ID: It would be nice if there was official support for mobile app packaging. Cheers, Mark On Tue, Mar 31, 2015 at 11:55 AM, Tom Schindl wrote: > Hi, > > Are there any official plans already for Java9? > > One of the major pain points I see is that the java-packager does not > support to set a splash-screen and also ignores the -splash argument who > works when launching with java ... . > > Another very obvious thing at least on all the windows machine I tried > JavaFX is a black area while resizing stages this makes things look > unprofessional. > > A very special request thing is WebGL support Webkit a customer ask me > for but I guess this is a though thing todo because on windows we only > have DirectX. > > > Tom > > -- > Thomas Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > From mike at plan99.net Tue Mar 31 20:10:55 2015 From: mike at plan99.net (Mike Hearn) Date: Tue, 31 Mar 2015 22:10:55 +0200 Subject: What are the plans for Java9? In-Reply-To: <551AEDA5.8070006@bestsolution.at> References: <551AEDA5.8070006@bestsolution.at> Message-ID: > > One of the major pain points I see is that the java-packager does not > support to set a splash-screen Does your app really need one? My laptop can throw a Stage onto the screen in about 500msec. Then you can just show your own splash whilst the app loads ... From cnewland at chrisnewland.com Tue Mar 31 20:31:52 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 31 Mar 2015 21:31:52 +0100 Subject: Canvas performance on Mac OS In-Reply-To: <55199E52.9090503@oracle.com> References: <5515C483.9030901@oracle.com> <55199E52.9090503@oracle.com> Message-ID: Hi Jim, Thanks, that makes things much clearer. I was surprised how much was going on under the hood of GraphicsContext and hoped it was just magic glue that gave the best of GPU acceleration where available and immediate-mode-like simple rasterizing where not. I've managed to find an anomaly with GraphicsContext.fillPolygon where the software pipeline achieves the full 60fps but ES2 can only manage 30-35fps. It uses lots of overlapping filled triangles so I expect suffers from the problem you've described. SSCCE: https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/chrisnewland/demofx/standalone/Sierpinski.java Was full frame rate canvas drawing an expected use case for JavaFX or would I be better off with Graphics2D? Thanks, Chris On Mon, March 30, 2015 20:04, Jim Graham wrote: > Hi Chris, > > > drawLine() is a very simple primitive that can be optimized with a GPU > shader. It either looks like a (potentially rotated) rectangle or a > rounded rect - and we have optimized shaders for both cases. A large > number of drawLine() calls turns into simply accumulating a large vertex > list and uploading it to the GPU with an appropriate shader which is very > fast. > > drawPolygon() is a very complex operation that involves things like: > > - dealing with line joins between segments that don't exist for > drawLine() - dealing with only rendering common points of intersection > once > > To handle all of that complexity we have to involve a rasterizer that > takes the entire collection of lines, analyzes the stroke attributes and > interactions and computes a coverage mask for each pixel in the region. We > do that in software currently for all pipelines. > > For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path > rasterization. > > For the SW pipeline, drawLine is a simplified case of drawPolygon and so > the overhead of lots of calls to drawLine() dominates its performance. > > I would expect ES2 to blow the SW pipeline out of the water with > drawLine() performance (as long as there are no additional rendering > primitives interspersed in the set of lines). > > But, both should be on the same footing for the drawPolygon case. Does > the ES2 pipeline compare similarly (hopefully better than) the SW pipeline > for the polygon case? > > One thing I noticed is that we have no optimized case for drawLine() on > the SW pipeline. It generates a path containing a single MOVETO and LINETO > and feeds it to the generalized path rasterizer when it could instead > compute the rounded/square rectangle and render it more directly. If we > added that support then I'd expect the SW pipeline to perform the set of > drawLine calls faster than drawPolygon as well... > > ...jim > > > On 3/28/15 3:22 AM, Chris Newland wrote: > >> Hi Robert, >> >> >> I've not filed a Jira yet as I was hoping to find time to investigate >> thoroughly but when I saw your question I thought I'd better add my >> findings. >> >> I believe the issue is in the ES2Pipeline as if I run with >> -Dprism.order=sw then strokePolygon outperforms the series of strokeLine >> commands as expected: >> >> java -cp target/DemoFX.jar -Dprism.order=sw >> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result: 44fps >> >> >> java -cp target/DemoFX.jar -Dprism.order=sw >> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result: 60fps >> >> >> Will see if I can find the root cause as I've got plenty more examples >> where ES2Pipeline performs horribly on my Mac which should have no >> problem throwing around a few thousand polys. >> >> I realise there's a *lot* of indirection involved in making JavaFX >> support such a wide range of underlying graphics systems but I do think >> there's a bug here. >> >> Will file a Jira if I can contribute a bit more than "feels slow" ;) >> >> >> Cheers, >> >> >> Chris >> >> >> On Sat, March 28, 2015 10:06, Robert Kr??ger wrote: >> >>> This is consistent with what I am observing. Is this something that >>> Oracle >>> is aware of? Looking at Jira, I don't see that anyone is working on >>> this: >>> >>> >>> https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%2 >>> 2In% >>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%2 >>> 0la >>> bels%20in%20(performance) >>> >>> Given that one of the One of the main reasons to use JFX for me is to >>> be able to develop with one code base for at least OSX and Windows and >>> the official statement what JavaFX is for, i.e. >>> >>> "JavaFX is a set of graphics and media packages that enables >>> developers to design, create, test, debug, and deploy rich client >>> applications that operate consistently across diverse platforms" >>> >>> and the fact that this is clearly not the case currently (8u40) as >>> soon as I do something else than simple forms, I run into >>> performance/quality problems on the Mac, I am a bit unsure what to >>> make of all that. Is Mac OSX >>> a second-class citizen as far as dev resources are concerned? >>> >>> Tobi and Chris, have you filed Jira Issues on Mac graphics >>> performance that can be tracked? >>> >>> I will file an issue with a simple test case and hope for the best. >>> >>> >>> >>> >>> >>> >>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland >>> >>> wrote: >>> >>> >>> >>>> Possibly related: >>>> >>>> >>>> >>>> I can reproduce a massive (90%) performance drop on OSX between >>>> drawing a wireframe polygon on a Canvas using a series of >>>> gc.strokeLine(double x1, double y1, double x2, double y2) commands >>>> versus using a single gc.strokePolygon(double[] xPoints, double[] >>>> yPoints, int count) command. >>>> >>>> Creating the polygons manually with strokeLine() is significantly >>>> faster using the ES2Pipeline on OSX. >>>> >>>> This is reproducible in a little GitHub JavaFX benchmarking project >>>> I've >>>> created: https://github.com/chriswhocodes/DemoFX >>>> >>>> >>>> >>>> Build with ant >>>> >>>> >>>> >>>> Run with: >>>> >>>> >>>> >>>> # use strokeLine >>>> ./run.sh -c 5000 -m line >>>> result: 60 (sixty) fps >>>> >>>> >>>> >>>> # use strokePolygon >>>> ./run.sh -c 5000 -m poly >>>> result: 6 (six) fps >>>> >>>> >>>> >>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM / >>>> Radeon >>>> 6970M 1024MB >>>> >>>> >>>> >>>> Looking at the code paths in javafx.scene.canvas.GraphicsContext: >>>> >>>> >>>> >>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, >>>> NGCanvas.STROKE_LINE) >>>> >>>> >>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, >>>> true, NGCanvas.STROKE_PATH) which involves significantly more work >>>> with adding to and flushing a GrowableDataBuffer. >>>> >>>> I've not had time to dig any deeper than this but it's surely a bug >>>> when building a poly manually is 10x faster than using the >>>> convenience method. >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Chris >>>> >>>> >>>> >>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote: >>>> >>>> >>>>> In my opinion the whole graphics performance on MacOSX >>>>> isn????????t good at all with JavaFX???????. >>>>> >>>>> >>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger >>>>>> : >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The bad full screen performance is without the arcs. It is just >>>>>> one call to fillRect, two to strokeOval and one to fillOval, >>>>>> that's all. I will build a simple test case and file an issue. >>>>>> >>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi Robert, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please file a Jira issue with a simple test case. Arcs are >>>>>>> handled as a generalized shape rather than via a predetermined >>>>>>> shader, but it shouldn't be that slow. Something else may >>>>>>> be going on. >>>>>>> >>>>>>> Another test might be to replace the arcs with rectangles or >>>>>>> ellipses and see if the performance changes... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I have a super-simple animation implemented using >>>>>>>> AnimationTimer >>>>>>>> and Canvas where the canvas just performs a few draw >>>>>>>> operations, i.e. fills the screen with a color and then >>>>>>>> draws and fills 2-3 circles and I have already observed that >>>>>>>> each drawing operation I add, results in >>>>>>>> significant CPU load (e.g. when I draw < 10 arcs in addition >>>>>>>> to the circles, the CPU load goes up to 30-40% on a Mac Book >>>>>>>> Pro >>>>>>>> for a Canvas size of 600x600(!). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Now I tested the animation in full screen mode (only with a >>>>>>>> few circles) and playback is unusable for a serious >>>>>>>> application (very >>>>>>>> choppy). Is 2D canvas performance known to be very bad on >>>>>>>> Mac or >>>>>>>> am I doing something wrong? Are there workarounds for this? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Robert Kr????ger >>>>>> Managing Partner >>>>>> Lesspain GmbH & Co. KG >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> www.lesspain-software.com >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Robert Kr??ger >>> Managing Partner >>> Lesspain GmbH & Co. KG >>> >>> >>> >>> www.lesspain-software.com >>> >> >> > From mike at plan99.net Tue Mar 31 20:42:12 2015 From: mike at plan99.net (Mike Hearn) Date: Tue, 31 Mar 2015 22:42:12 +0200 Subject: Review Request: RT-39975 - AppCDS support for packager In-Reply-To: References: <771E6A76-4080-4349-AA9C-F4514EE00E02@oracle.com> <3A70A1E8-F892-480E-941D-024819FC14FB@oracle.com> Message-ID: Do you have any stats on the perf improvement? My understanding of CDS is that it was primarily meant to reduce memory usage on systems where multiple Java apps are running on the same JRE simultaneously. I guess that won't apply to packaged apps so the only benefit can be startup time. On Tue, Mar 31, 2015 at 3:59 PM, Chris Bensen wrote: > Correct! > > > On Mar 31, 2015, at 4:41 AM, Mike Hearn wrote: > > The bug is restricted - intentional? > > I'm guessing this is class data sharing and would make startup of packaged > apps faster? > > On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen > wrote: > >> +1 >> >> On Mar 30, 2015, at 3:11 PM, Danno Ferrin >> wrote: >> >> > Kevin, Chris, please review >> > >> > jira: https://javafx-jira.kenai.com/browse/RT-39975 >> > webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/ >> >> > > From herve.girod at gmail.com Tue Mar 31 21:00:45 2015 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Tue, 31 Mar 2015 23:00:45 +0200 Subject: Canvas performance on Mac OS In-Reply-To: References: <5515C483.9030901@oracle.com> <55199E52.9090503@oracle.com> Message-ID: <9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com> Why don't you use Nodes rather than Canvas ? Sent from my iPhone > On Mar 31, 2015, at 22:31, Chris Newland wrote: > > Hi Jim, > > Thanks, that makes things much clearer. > > I was surprised how much was going on under the hood of GraphicsContext > and hoped it was just magic glue that gave the best of GPU acceleration > where available and immediate-mode-like simple rasterizing where not. > > I've managed to find an anomaly with GraphicsContext.fillPolygon where the > software pipeline achieves the full 60fps but ES2 can only manage > 30-35fps. It uses lots of overlapping filled triangles so I expect suffers > from the problem you've described. > > SSCCE: > https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/chrisnewland/demofx/standalone/Sierpinski.java > > Was full frame rate canvas drawing an expected use case for JavaFX or > would I be better off with Graphics2D? > > Thanks, > > Chris > >> On Mon, March 30, 2015 20:04, Jim Graham wrote: >> Hi Chris, >> >> >> drawLine() is a very simple primitive that can be optimized with a GPU >> shader. It either looks like a (potentially rotated) rectangle or a >> rounded rect - and we have optimized shaders for both cases. A large >> number of drawLine() calls turns into simply accumulating a large vertex >> list and uploading it to the GPU with an appropriate shader which is very >> fast. >> >> drawPolygon() is a very complex operation that involves things like: >> >> - dealing with line joins between segments that don't exist for >> drawLine() - dealing with only rendering common points of intersection >> once >> >> To handle all of that complexity we have to involve a rasterizer that >> takes the entire collection of lines, analyzes the stroke attributes and >> interactions and computes a coverage mask for each pixel in the region. We >> do that in software currently for all pipelines. >> >> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path >> rasterization. >> >> For the SW pipeline, drawLine is a simplified case of drawPolygon and so >> the overhead of lots of calls to drawLine() dominates its performance. >> >> I would expect ES2 to blow the SW pipeline out of the water with >> drawLine() performance (as long as there are no additional rendering >> primitives interspersed in the set of lines). >> >> But, both should be on the same footing for the drawPolygon case. Does >> the ES2 pipeline compare similarly (hopefully better than) the SW pipeline >> for the polygon case? >> >> One thing I noticed is that we have no optimized case for drawLine() on >> the SW pipeline. It generates a path containing a single MOVETO and LINETO >> and feeds it to the generalized path rasterizer when it could instead >> compute the rounded/square rectangle and render it more directly. If we >> added that support then I'd expect the SW pipeline to perform the set of >> drawLine calls faster than drawPolygon as well... >> >> ...jim >> >> >>> On 3/28/15 3:22 AM, Chris Newland wrote: >>> >>> Hi Robert, >>> >>> >>> I've not filed a Jira yet as I was hoping to find time to investigate >>> thoroughly but when I saw your question I thought I'd better add my >>> findings. >>> >>> I believe the issue is in the ES2Pipeline as if I run with >>> -Dprism.order=sw then strokePolygon outperforms the series of strokeLine >>> commands as expected: >>> >>> java -cp target/DemoFX.jar -Dprism.order=sw >>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result: 44fps >>> >>> >>> java -cp target/DemoFX.jar -Dprism.order=sw >>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result: 60fps >>> >>> >>> Will see if I can find the root cause as I've got plenty more examples >>> where ES2Pipeline performs horribly on my Mac which should have no >>> problem throwing around a few thousand polys. >>> >>> I realise there's a *lot* of indirection involved in making JavaFX >>> support such a wide range of underlying graphics systems but I do think >>> there's a bug here. >>> >>> Will file a Jira if I can contribute a bit more than "feels slow" ;) >>> >>> >>> Cheers, >>> >>> >>> Chris >>> >>> >>>> On Sat, March 28, 2015 10:06, Robert Kr?ger wrote: >>>> >>>> This is consistent with what I am observing. Is this something that >>>> Oracle >>>> is aware of? Looking at Jira, I don't see that anyone is working on >>>> this: >>>> >>>> >>>> https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%2 >>>> 2In% >>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%2 >>>> 0la >>>> bels%20in%20(performance) >>>> >>>> Given that one of the One of the main reasons to use JFX for me is to >>>> be able to develop with one code base for at least OSX and Windows and >>>> the official statement what JavaFX is for, i.e. >>>> >>>> "JavaFX is a set of graphics and media packages that enables >>>> developers to design, create, test, debug, and deploy rich client >>>> applications that operate consistently across diverse platforms" >>>> >>>> and the fact that this is clearly not the case currently (8u40) as >>>> soon as I do something else than simple forms, I run into >>>> performance/quality problems on the Mac, I am a bit unsure what to >>>> make of all that. Is Mac OSX >>>> a second-class citizen as far as dev resources are concerned? >>>> >>>> Tobi and Chris, have you filed Jira Issues on Mac graphics >>>> performance that can be tracked? >>>> >>>> I will file an issue with a simple test case and hope for the best. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland >>>> >>>> wrote: >>>> >>>> >>>> >>>>> Possibly related: >>>>> >>>>> >>>>> >>>>> I can reproduce a massive (90%) performance drop on OSX between >>>>> drawing a wireframe polygon on a Canvas using a series of >>>>> gc.strokeLine(double x1, double y1, double x2, double y2) commands >>>>> versus using a single gc.strokePolygon(double[] xPoints, double[] >>>>> yPoints, int count) command. >>>>> >>>>> Creating the polygons manually with strokeLine() is significantly >>>>> faster using the ES2Pipeline on OSX. >>>>> >>>>> This is reproducible in a little GitHub JavaFX benchmarking project >>>>> I've >>>>> created: https://github.com/chriswhocodes/DemoFX >>>>> >>>>> >>>>> >>>>> Build with ant >>>>> >>>>> >>>>> >>>>> Run with: >>>>> >>>>> >>>>> >>>>> # use strokeLine >>>>> ./run.sh -c 5000 -m line >>>>> result: 60 (sixty) fps >>>>> >>>>> >>>>> >>>>> # use strokePolygon >>>>> ./run.sh -c 5000 -m poly >>>>> result: 6 (six) fps >>>>> >>>>> >>>>> >>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM / >>>>> Radeon >>>>> 6970M 1024MB >>>>> >>>>> >>>>> >>>>> Looking at the code paths in javafx.scene.canvas.GraphicsContext: >>>>> >>>>> >>>>> >>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, >>>>> NGCanvas.STROKE_LINE) >>>>> >>>>> >>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, >>>>> true, NGCanvas.STROKE_PATH) which involves significantly more work >>>>> with adding to and flushing a GrowableDataBuffer. >>>>> >>>>> I've not had time to dig any deeper than this but it's surely a bug >>>>> when building a poly manually is 10x faster than using the >>>>> convenience method. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> Chris >>>>> >>>>> >>>>> >>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote: >>>>> >>>>> >>>>>> In my opinion the whole graphics performance on MacOSX >>>>>> isn???t good at all with JavaFX???. >>>>>> >>>>>> >>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr??ger >>>>>>> : >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The bad full screen performance is without the arcs. It is just >>>>>>> one call to fillRect, two to strokeOval and one to fillOval, >>>>>>> that's all. I will build a simple test case and file an issue. >>>>>>> >>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi Robert, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please file a Jira issue with a simple test case. Arcs are >>>>>>>> handled as a generalized shape rather than via a predetermined >>>>>>>> shader, but it shouldn't be that slow. Something else may >>>>>>>> be going on. >>>>>>>> >>>>>>>> Another test might be to replace the arcs with rectangles or >>>>>>>> ellipses and see if the performance changes... >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/27/15 1:52 PM, Robert Kr??ger wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have a super-simple animation implemented using >>>>>>>>> AnimationTimer >>>>>>>>> and Canvas where the canvas just performs a few draw >>>>>>>>> operations, i.e. fills the screen with a color and then >>>>>>>>> draws and fills 2-3 circles and I have already observed that >>>>>>>>> each drawing operation I add, results in >>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs in addition >>>>>>>>> to the circles, the CPU load goes up to 30-40% on a Mac Book >>>>>>>>> Pro >>>>>>>>> for a Canvas size of 600x600(!). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Now I tested the animation in full screen mode (only with a >>>>>>>>> few circles) and playback is unusable for a serious >>>>>>>>> application (very >>>>>>>>> choppy). Is 2D canvas performance known to be very bad on >>>>>>>>> Mac or >>>>>>>>> am I doing something wrong? Are there workarounds for this? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Robert >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Robert Kr??ger >>>>>>> Managing Partner >>>>>>> Lesspain GmbH & Co. KG >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> www.lesspain-software.com >>>> >>>> >>>> -- >>>> Robert Kr?ger >>>> Managing Partner >>>> Lesspain GmbH & Co. KG >>>> >>>> >>>> >>>> www.lesspain-software.com > > From chris.bensen at oracle.com Tue Mar 31 21:54:08 2015 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 31 Mar 2015 14:54:08 -0700 Subject: Review Request: RT-39975 - AppCDS support for packager In-Reply-To: References: <771E6A76-4080-4349-AA9C-F4514EE00E02@oracle.com> <3A70A1E8-F892-480E-941D-024819FC14FB@oracle.com> Message-ID: <8173D9AF-B05D-4AF0-919F-82845EF2E6F6@oracle.com> No, I don?t have any stats to share about the performance benefits, sorry. On Mar 31, 2015, at 1:42 PM, Mike Hearn wrote: > Do you have any stats on the perf improvement? My understanding of CDS is that it was primarily meant to reduce memory usage on systems where multiple Java apps are running on the same JRE simultaneously. I guess that won't apply to packaged apps so the only benefit can be startup time. > > On Tue, Mar 31, 2015 at 3:59 PM, Chris Bensen wrote: > Correct! > > > On Mar 31, 2015, at 4:41 AM, Mike Hearn wrote: > >> The bug is restricted - intentional? >> >> I'm guessing this is class data sharing and would make startup of packaged apps faster? >> >> On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen wrote: >> +1 >> >> On Mar 30, 2015, at 3:11 PM, Danno Ferrin wrote: >> >> > Kevin, Chris, please review >> > >> > jira: https://javafx-jira.kenai.com/browse/RT-39975 >> > webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/ >> >> > > From cnewland at chrisnewland.com Tue Mar 31 22:40:30 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 31 Mar 2015 23:40:30 +0100 Subject: Canvas performance on Mac OS In-Reply-To: <9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com> References: <5515C483.9030901@oracle.com> <55199E52.9090503@oracle.com> <9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com> Message-ID: <50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net> Hi Herv?, That's a valid question :) Probably because a) All my non-UI graphics experience is with immediate-mode / raster systems b) I'm interested in using JavaFX for particle effects / demoscene / gaming so assumed (perhaps wrongly?) that scenegraph was not the way to go for that due to the very large number of nodes. Numbers for my Sierpinski filled triangle example: System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M 1024 MB java -Dprism.order=es2 -cp target/classes/ com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 23 fps: 18 fps: 25 fps: 18 fps: 23 fps: 23 fps: 19 fps: 25 java -Dprism.order=sw -cp target/classes/ com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 54 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 There are never more than 2500 filled triangles on screen. JDK is 1.8.0_40 I would say there is a performance problem here? (or at least a need for documentation so as to set expectations for gc.fillPolygon). Best regards, Chris On Tue, March 31, 2015 22:00, Herv?? Girod wrote: > Why don't you use Nodes rather than Canvas ? > > > Sent from my iPhone > > >> On Mar 31, 2015, at 22:31, Chris Newland >> wrote: >> >> >> Hi Jim, >> >> >> Thanks, that makes things much clearer. >> >> >> I was surprised how much was going on under the hood of GraphicsContext >> and hoped it was just magic glue that gave the best of GPU >> acceleration where available and immediate-mode-like simple rasterizing >> where not. >> >> I've managed to find an anomaly with GraphicsContext.fillPolygon where >> the software pipeline achieves the full 60fps but ES2 can only manage >> 30-35fps. It uses lots of overlapping filled triangles so I expect >> suffers from the problem you've described. >> >> SSCCE: >> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/ch >> risnewland/demofx/standalone/Sierpinski.java >> >> Was full frame rate canvas drawing an expected use case for JavaFX or >> would I be better off with Graphics2D? >> >> Thanks, >> >> >> Chris >> >> >>> On Mon, March 30, 2015 20:04, Jim Graham wrote: >>> Hi Chris, >>> >>> >>> >>> drawLine() is a very simple primitive that can be optimized with a >>> GPU >>> shader. It either looks like a (potentially rotated) rectangle or a >>> rounded rect - and we have optimized shaders for both cases. A large >>> number of drawLine() calls turns into simply accumulating a large >>> vertex list and uploading it to the GPU with an appropriate shader >>> which is very fast. >>> >>> drawPolygon() is a very complex operation that involves things like: >>> >>> - dealing with line joins between segments that don't exist for >>> drawLine() - dealing with only rendering common points of intersection >>> once >>> >>> To handle all of that complexity we have to involve a rasterizer that >>> takes the entire collection of lines, analyzes the stroke attributes >>> and interactions and computes a coverage mask for each pixel in the >>> region. We do that in software currently for all pipelines. >>> >>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path >>> rasterization. >>> >>> For the SW pipeline, drawLine is a simplified case of drawPolygon and >>> so the overhead of lots of calls to drawLine() dominates its >>> performance. >>> >>> I would expect ES2 to blow the SW pipeline out of the water with >>> drawLine() performance (as long as there are no additional rendering >>> primitives interspersed in the set of lines). >>> >>> But, both should be on the same footing for the drawPolygon case. >>> Does >>> the ES2 pipeline compare similarly (hopefully better than) the SW >>> pipeline for the polygon case? >>> >>> One thing I noticed is that we have no optimized case for drawLine() >>> on the SW pipeline. It generates a path containing a single MOVETO >>> and LINETO and feeds it to the generalized path rasterizer when it >>> could instead compute the rounded/square rectangle and render it more >>> directly. If we added that support then I'd expect the SW pipeline to >>> perform the set of drawLine calls faster than drawPolygon as well... >>> >>> ...jim >>> >>> >>> >>>> On 3/28/15 3:22 AM, Chris Newland wrote: >>>> >>>> >>>> Hi Robert, >>>> >>>> >>>> >>>> I've not filed a Jira yet as I was hoping to find time to >>>> investigate thoroughly but when I saw your question I thought I'd >>>> better add my findings. >>>> >>>> I believe the issue is in the ES2Pipeline as if I run with >>>> -Dprism.order=sw then strokePolygon outperforms the series of >>>> strokeLine commands as expected: >>>> >>>> java -cp target/DemoFX.jar -Dprism.order=sw >>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result: >>>> 44fps >>>> >>>> >>>> >>>> java -cp target/DemoFX.jar -Dprism.order=sw >>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result: >>>> 60fps >>>> >>>> >>>> >>>> Will see if I can find the root cause as I've got plenty more >>>> examples where ES2Pipeline performs horribly on my Mac which should >>>> have no problem throwing around a few thousand polys. >>>> >>>> I realise there's a *lot* of indirection involved in making JavaFX >>>> support such a wide range of underlying graphics systems but I do >>>> think there's a bug here. >>>> >>>> Will file a Jira if I can contribute a bit more than "feels slow" >>>> ;) >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Chris >>>> >>>> >>>> >>>>> On Sat, March 28, 2015 10:06, Robert Kr??ger wrote: >>>>> >>>>> >>>>> This is consistent with what I am observing. Is this something >>>>> that Oracle >>>>> is aware of? Looking at Jira, I don't see that anyone is working >>>>> on this: >>>>> >>>>> >>>>> >>>>> https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C% >>>>> 20%2 >>>>> 2In% >>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20A >>>>> ND%2 >>>>> 0la >>>>> bels%20in%20(performance) >>>>> >>>>> Given that one of the One of the main reasons to use JFX for me >>>>> is to be able to develop with one code base for at least OSX and >>>>> Windows and >>>>> the official statement what JavaFX is for, i.e. >>>>> >>>>> "JavaFX is a set of graphics and media packages that enables >>>>> developers to design, create, test, debug, and deploy rich client >>>>> applications that operate consistently across diverse platforms" >>>>> >>>>> and the fact that this is clearly not the case currently (8u40) >>>>> as soon as I do something else than simple forms, I run into >>>>> performance/quality problems on the Mac, I am a bit unsure what >>>>> to make of all that. Is Mac OSX a second-class citizen as far as >>>>> dev resources are concerned? >>>>> >>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics >>>>> performance that can be tracked? >>>>> >>>>> I will file an issue with a simple test case and hope for the >>>>> best. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Possibly related: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I can reproduce a massive (90%) performance drop on OSX between >>>>>> drawing a wireframe polygon on a Canvas using a series of >>>>>> gc.strokeLine(double x1, double y1, double x2, double y2) >>>>>> commands versus using a single gc.strokePolygon(double[] >>>>>> xPoints, double[] yPoints, int count) command. >>>>>> >>>>>> Creating the polygons manually with strokeLine() is >>>>>> significantly faster using the ES2Pipeline on OSX. >>>>>> >>>>>> This is reproducible in a little GitHub JavaFX benchmarking >>>>>> project I've >>>>>> created: https://github.com/chriswhocodes/DemoFX >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Build with ant >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Run with: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> # use strokeLine >>>>>> ./run.sh -c 5000 -m line >>>>>> result: 60 (sixty) fps >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> # use strokePolygon >>>>>> ./run.sh -c 5000 -m poly >>>>>> result: 6 (six) fps >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM >>>>>> / >>>>>> Radeon >>>>>> 6970M 1024MB >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Looking at the code paths in >>>>>> javafx.scene.canvas.GraphicsContext: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, >>>>>> NGCanvas.STROKE_LINE) >>>>>> >>>>>> >>>>>> >>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, >>>>>> true, NGCanvas.STROKE_PATH) which involves significantly more >>>>>> work with adding to and flushing a GrowableDataBuffer. >>>>>> >>>>>> I've not had time to dig any deeper than this but it's surely a >>>>>> bug when building a poly manually is 10x faster than using the >>>>>> convenience method. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote: >>>>>> >>>>>> >>>>>> >>>>>>> In my opinion the whole graphics performance on MacOSX >>>>>>> isn????????t good at all with JavaFX???????. >>>>>>> >>>>>>> >>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger >>>>>>>> : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The bad full screen performance is without the arcs. It is >>>>>>>> just one call to fillRect, two to strokeOval and one to >>>>>>>> fillOval, that's all. I will build a simple test case and >>>>>>>> file an issue. >>>>>>>> >>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi Robert, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please file a Jira issue with a simple test case. Arcs >>>>>>>>> are handled as a generalized shape rather than via a >>>>>>>>> predetermined shader, but it shouldn't be that slow. >>>>>>>>> Something else may >>>>>>>>> be going on. >>>>>>>>> >>>>>>>>> Another test might be to replace the arcs with rectangles >>>>>>>>> or ellipses and see if the performance changes... >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I have a super-simple animation implemented using >>>>>>>>>> AnimationTimer >>>>>>>>>> and Canvas where the canvas just performs a few draw >>>>>>>>>> operations, i.e. fills the screen with a color and then >>>>>>>>>> draws and fills 2-3 circles and I have already >>>>>>>>>> observed that each drawing operation I add, results in >>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs in >>>>>>>>>> addition to the circles, the CPU load goes up to 30-40% >>>>>>>>>> on a Mac Book Pro >>>>>>>>>> for a Canvas size of 600x600(!). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now I tested the animation in full screen mode (only >>>>>>>>>> with a few circles) and playback is unusable for a >>>>>>>>>> serious application (very choppy). Is 2D canvas >>>>>>>>>> performance known to be very bad on Mac or >>>>>>>>>> am I doing something wrong? Are there workarounds for >>>>>>>>>> this? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Robert >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Robert Kr????ger >>>>>>>> Managing Partner >>>>>>>> Lesspain GmbH & Co. KG >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> www.lesspain-software.com >>>>> >>>>> >>>>> -- >>>>> Robert Kr??ger >>>>> Managing Partner >>>>> Lesspain GmbH & Co. KG >>>>> >>>>> >>>>> >>>>> >>>>> www.lesspain-software.com >> >> >