hg: openjfx/8u-dev/rt: RT-32553 ScrollPane doesn't take the focus when pressing on the scroll bar
Changeset: e76f5f5b0047 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-05-27 10:14 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e76f5f5b0047 RT-32553 ScrollPane doesn't take the focus when pressing on the scroll bar Reviewed by: dgrieve ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java
hg: openjfx/8u-dev/rt: RT-37184 when pressing button Length, the small gradient will disappear at some points
Changeset: 0867438d36b7 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-05-27 10:17 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0867438d36b7 RT-37184 when pressing button Length, the small gradient will disappear at some points Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java
hg: openjfx/8u-dev/rt: [JAVADOC] RT-37281 SortedList has wrong javadoc documentation
Changeset: be04d004a78c Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-05-27 12:39 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/be04d004a78c [JAVADOC] RT-37281 SortedList has wrong javadoc documentation ! modules/base/src/main/java/javafx/collections/transformation/SortedList.java
hg: openjfx/8u-dev/rt: RT-37033: [SwingNode] JEditorPane in SwingNode inside TabPane does not get focus properly when clicked
Changeset: e081a8869ee8 Author:Anthony Petrov anthony.pet...@oracle.com Date: 2014-05-27 15:03 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e081a8869ee8 RT-37033: [SwingNode] JEditorPane in SwingNode inside TabPane does not get focus properly when clicked Summary: Consume mouse events if they're processed by SwingNode itself Reviewed-by: ant, jgiles, snorthov ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java
hg: openjfx/8u-dev/rt: Linux Input Tests: updating ignored test with a more relevant JIRA number
Changeset: c470fa477657 Author:Elina Kleyman elina.kley...@oracle.com Date: 2014-05-27 15:45 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c470fa477657 Linux Input Tests: updating ignored test with a more relevant JIRA number ! tests/system/src/test/java/com/sun/glass/ui/monocle/input/SingleTouchTest.java
hg: openjfx/8u-dev/rt: RT-35994: Mac: Holding a key down throws exception
Changeset: 40ee7df8768e Author:Anthony Petrov anthony.pet...@oracle.com Date: 2014-05-27 19:06 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/40ee7df8768e RT-35994: Mac: Holding a key down throws exception Summary: Prevent NPE ! modules/swing/src/main/java/javafx/embed/swing/InputMethodSupport.java
hg: openjfx/8u-dev/rt: 3 new changesets
Changeset: 0c4416888e5c Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-05-27 04:28 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0c4416888e5c RT-36639: [RTL] PasswordField rendering issue when it's highlighted. - Pango ! modules/graphics/src/main/java/com/sun/javafx/font/freetype/OSPango.java ! modules/graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java ! modules/graphics/src/main/native-font/pango.c Changeset: 83e8b46ae2bf Author:ddhill Date: 2014-05-27 11:43 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/83e8b46ae2bf RT-37278: dalvik build should add main classes on javah classpath Contributed-by: johanvos ! buildSrc/dalvik.gradle Changeset: 05367a06c685 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-05-27 08:46 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/05367a06c685 RT-36639: [RTL] PasswordField rendering issue when it's highlighted. - MAC ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/OS.java ! modules/graphics/src/main/native-font/coretext.c
Gradle Scripts
I know the wiki says only Gradle 1.8 is guaranteed to work so I have to ask:
Why not use the Gradle Wrapper to force use of 1.8?
http://www.gradle.org/docs/current/userguide/gradle_wrapper.html
Well, I tried tweaking the build scripts to use it myself, running on
OS X and found that the scripts appear to be badly broken anyway and
they can't even be parsed with later Gradle versions so you can't even
run the wrapper task:
The error is:
Could not find method 'defineProperty() for arguments
[MACOSX_MIN_VERSION, 10.7] on root project .
Sure enough the defineProperty method is being called from a different
.gradle file than the one in which it is defined, so it is out of
scope. I corrected this locally by changing it to a closure and
assigning it to project.ext.defineProperty. Then I added:
task wrapper(type: Wrapper) {
gradleVersion = 1.8'
}
and was able to get the gradlew script created by running:
gradle wrapper
So then I tried to build with Gradle 1.8 by running:
./gradlew
Then I hit :verifyJava complaining that the build number (13) was too
low ( 115)... but I'm building the 8u5 code with the 8u5 release...
that seems like a combination that should work.
I think everyone (myself included) would be more inclined to help with
patches if it wasn't such a pain to build. I appreciate that prior to
the use of Gradle this was likely much worse. Gradle is a great build
system and should be able to make this an even simpler process.
On Windows for what I assume are historical reasons, Cygwin is
expected. I'm only trying to build the Java side of things.. not the
native DLLs and I don't see Cygwin doing anything of value in the
build scripts for that case. It's mangling paths that don't need to
be mangle for example.
I think the build scripts could be cleaned up to provide a much
smoother build experience for those outside of Oracle.
No doubt you guys simply don't have the cycles to burn on fixing build
scripts that are currently working for you.. but I suspect it will pay
off in the long run. The current version of Gradle, 1.12, is the last
1.x Gradle release before the 2.x versions appear. It may make sense
to achieve compatibility with it. Gradle 2.x is expected to break
things, but once things are working with 1.12, then you can work on
getting rid of the warnings and you will be in a much better position.
Cheers,
Scott
Re: Gradle Scripts
My build woes continued a bit...
I tweaked build.gradle such that the buildnum.min was 5.
Then the build failed trying to build :fxpackager:compileLauncher
Coud not call NativeCompileTask.compile() on task ':fxpackager:compileLauncher'
I belive this is native code? The wiki says that native code doesnt'
normally build unless you use -PBUILD_NATIVES=true
I imagine this is true for the FX runtime DLLs and was just overlooked
for the launcher.
The root cause seems to be that I am missing the OS X 10.7 SDK:
clang: warning: no such sysroot directory:
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk'
But I do have later versions for 10.8 and 10.9.
Tweaking buildSrc/mac.gradle so MACOSX_MIN_VERSION is 10.8 allowed me
to finally complete a successful build! - I think I haven't tested
anything yet.. but at least gradle stopped complaining.
Cheers,
Scott
On Tue, May 27, 2014 at 11:56 AM, Scott Palmer swpal...@gmail.com wrote:
I know the wiki says only Gradle 1.8 is guaranteed to work so I have to ask:
Why not use the Gradle Wrapper to force use of 1.8?
http://www.gradle.org/docs/current/userguide/gradle_wrapper.html
Well, I tried tweaking the build scripts to use it myself, running on
OS X and found that the scripts appear to be badly broken anyway and
they can't even be parsed with later Gradle versions so you can't even
run the wrapper task:
The error is:
Could not find method 'defineProperty() for arguments
[MACOSX_MIN_VERSION, 10.7] on root project .
Sure enough the defineProperty method is being called from a different
.gradle file than the one in which it is defined, so it is out of
scope. I corrected this locally by changing it to a closure and
assigning it to project.ext.defineProperty. Then I added:
task wrapper(type: Wrapper) {
gradleVersion = 1.8'
}
and was able to get the gradlew script created by running:
gradle wrapper
So then I tried to build with Gradle 1.8 by running:
./gradlew
Then I hit :verifyJava complaining that the build number (13) was too
low ( 115)... but I'm building the 8u5 code with the 8u5 release...
that seems like a combination that should work.
I think everyone (myself included) would be more inclined to help with
patches if it wasn't such a pain to build. I appreciate that prior to
the use of Gradle this was likely much worse. Gradle is a great build
system and should be able to make this an even simpler process.
On Windows for what I assume are historical reasons, Cygwin is
expected. I'm only trying to build the Java side of things.. not the
native DLLs and I don't see Cygwin doing anything of value in the
build scripts for that case. It's mangling paths that don't need to
be mangle for example.
I think the build scripts could be cleaned up to provide a much
smoother build experience for those outside of Oracle.
No doubt you guys simply don't have the cycles to burn on fixing build
scripts that are currently working for you.. but I suspect it will pay
off in the long run. The current version of Gradle, 1.12, is the last
1.x Gradle release before the 2.x versions appear. It may make sense
to achieve compatibility with it. Gradle 2.x is expected to break
things, but once things are working with 1.12, then you can work on
getting rid of the warnings and you will be in a much better position.
Cheers,
Scott
Re: Gradle Scripts
On 5/27/14, May 27, 12:22 PM, Scott Palmer wrote: The root cause seems to be that I am missing the OS X 10.7 SDK: clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk' But I do have later versions for 10.8 and 10.9. Tweaking buildSrc/mac.gradle so MACOSX_MIN_VERSION is 10.8 allowed me to finally complete a successful build! - I think I haven't tested anything yet.. but at least gradle stopped complaining. When I ran into this, I symlinked MacOSX10.7.sdk to MacOSX10.8.sdk Was told I could set the property MACOSX_MIN_VERSION on the command line, but that got old quick :-) Dave -- David Hill david.h...@oracle.com Java Embedded Development Experience is that marvelous thing that enables you to recognize a mistake when you make it again. -- Franklin P. Jones
Re: Gradle Scripts
See https://javafx-jira.kenai.com/browse/RT-34388 On May 27, 2014, at 9:29 AM, David Hill david.h...@oracle.com wrote: On 5/27/14, May 27, 12:22 PM, Scott Palmer wrote: The root cause seems to be that I am missing the OS X 10.7 SDK: clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk' But I do have later versions for 10.8 and 10.9. Tweaking buildSrc/mac.gradle so MACOSX_MIN_VERSION is 10.8 allowed me to finally complete a successful build! - I think I haven't tested anything yet.. but at least gradle stopped complaining. When I ran into this, I symlinked MacOSX10.7.sdk to MacOSX10.8.sdk Was told I could set the property MACOSX_MIN_VERSION on the command line, but that got old quick :-) Dave -- David Hill david.h...@oracle.com Java Embedded Development Experience is that marvelous thing that enables you to recognize a mistake when you make it again. -- Franklin P. Jones
Re: Gradle Scripts
I just checked and JavaFX 8u-dev builds fine with JDK 8u5. I suspect you
have an out-of-date repo.
-- Kevin
Kevin Rushforth wrote:
Hi Scott,
I don't think we can use gradle wrapper since it would require
checking a gradle jar file into our repo (there is IP / licensing
concern with that).
Regarding your other issues:
1) The Mac issue is a known problem that I still plan to address for
8u20: https://javafx-jira.kenai.com/browse/RT-34388
2) In the short term we are unlikely to change our production build to
a newer version of gradle, but I know of no reason it won't work with
gradle 1.12 (gradle 1.11 is known not to work). Does it build for you
with 1.12? I will try it myself.
3) The version check should work fine with JDK 8u5. Are you cloning
openjfx from the right place? openjfx/8u-dev/rt ? I'm fairly sure this
has been tested, but I will double-check.
4) Yes, we expect cygwin -- mainly for native but also for some of our
legacy any scripts (mostly in closed). We could consider accepting
patches that checked whether a windows build was cygwin and allowed it
to build at least the java code without requiring Cygwin. Did you want
to file a JIRA for this?
5) Native compilation for everything except media and wekbit, is on by
default, and there is currently no easy way to disable it. This is
something Richard had wanted to change back when the gradle build
scripts were developed, but was not finished. At the least, a flag to
turn off native compilation would be good. Do you want to file a JIRA
for this?
-- Kevin
Scott Palmer wrote:
I know the wiki says only Gradle 1.8 is guaranteed to work so I
have to ask:
Why not use the Gradle Wrapper to force use of 1.8?
http://www.gradle.org/docs/current/userguide/gradle_wrapper.html
Well, I tried tweaking the build scripts to use it myself, running on
OS X and found that the scripts appear to be badly broken anyway and
they can't even be parsed with later Gradle versions so you can't even
run the wrapper task:
The error is:
Could not find method 'defineProperty() for arguments
[MACOSX_MIN_VERSION, 10.7] on root project .
Sure enough the defineProperty method is being called from a different
.gradle file than the one in which it is defined, so it is out of
scope. I corrected this locally by changing it to a closure and
assigning it to project.ext.defineProperty. Then I added:
task wrapper(type: Wrapper) {
gradleVersion = 1.8'
}
and was able to get the gradlew script created by running:
gradle wrapper
So then I tried to build with Gradle 1.8 by running:
./gradlew
Then I hit :verifyJava complaining that the build number (13) was too
low ( 115)... but I'm building the 8u5 code with the 8u5 release...
that seems like a combination that should work.
I think everyone (myself included) would be more inclined to help with
patches if it wasn't such a pain to build. I appreciate that prior to
the use of Gradle this was likely much worse. Gradle is a great build
system and should be able to make this an even simpler process.
On Windows for what I assume are historical reasons, Cygwin is
expected. I'm only trying to build the Java side of things.. not the
native DLLs and I don't see Cygwin doing anything of value in the
build scripts for that case. It's mangling paths that don't need to
be mangle for example.
I think the build scripts could be cleaned up to provide a much
smoother build experience for those outside of Oracle.
No doubt you guys simply don't have the cycles to burn on fixing build
scripts that are currently working for you.. but I suspect it will pay
off in the long run. The current version of Gradle, 1.12, is the last
1.x Gradle release before the 2.x versions appear. It may make sense
to achieve compatibility with it. Gradle 2.x is expected to break
things, but once things are working with 1.12, then you can work on
getting rid of the warnings and you will be in a much better position.
Cheers,
Scott
Re: Gradle Scripts
BUILD_NATIVES was never implemented so I deleted mention of it from the
wiki. I have also updated the Mac section to include
MACOSX_MIN_VERSION. I could have swore this information was there but
apparently not.
Steve
On 2014-05-27, 12:22 PM, Scott Palmer wrote:
My build woes continued a bit...
I tweaked build.gradle such that the buildnum.min was 5.
Then the build failed trying to build :fxpackager:compileLauncher
Coud not call NativeCompileTask.compile() on task ':fxpackager:compileLauncher'
I belive this is native code? The wiki says that native code doesnt'
normally build unless you use -PBUILD_NATIVES=true
I imagine this is true for the FX runtime DLLs and was just overlooked
for the launcher.
The root cause seems to be that I am missing the OS X 10.7 SDK:
clang: warning: no such sysroot directory:
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk'
But I do have later versions for 10.8 and 10.9.
Tweaking buildSrc/mac.gradle so MACOSX_MIN_VERSION is 10.8 allowed me
to finally complete a successful build! - I think I haven't tested
anything yet.. but at least gradle stopped complaining.
Cheers,
Scott
On Tue, May 27, 2014 at 11:56 AM, Scott Palmer swpal...@gmail.com wrote:
I know the wiki says only Gradle 1.8 is guaranteed to work so I have to ask:
Why not use the Gradle Wrapper to force use of 1.8?
http://www.gradle.org/docs/current/userguide/gradle_wrapper.html
Well, I tried tweaking the build scripts to use it myself, running on
OS X and found that the scripts appear to be badly broken anyway and
they can't even be parsed with later Gradle versions so you can't even
run the wrapper task:
The error is:
Could not find method 'defineProperty() for arguments
[MACOSX_MIN_VERSION, 10.7] on root project .
Sure enough the defineProperty method is being called from a different
.gradle file than the one in which it is defined, so it is out of
scope. I corrected this locally by changing it to a closure and
assigning it to project.ext.defineProperty. Then I added:
task wrapper(type: Wrapper) {
gradleVersion = 1.8'
}
and was able to get the gradlew script created by running:
gradle wrapper
So then I tried to build with Gradle 1.8 by running:
./gradlew
Then I hit :verifyJava complaining that the build number (13) was too
low ( 115)... but I'm building the 8u5 code with the 8u5 release...
that seems like a combination that should work.
I think everyone (myself included) would be more inclined to help with
patches if it wasn't such a pain to build. I appreciate that prior to
the use of Gradle this was likely much worse. Gradle is a great build
system and should be able to make this an even simpler process.
On Windows for what I assume are historical reasons, Cygwin is
expected. I'm only trying to build the Java side of things.. not the
native DLLs and I don't see Cygwin doing anything of value in the
build scripts for that case. It's mangling paths that don't need to
be mangle for example.
I think the build scripts could be cleaned up to provide a much
smoother build experience for those outside of Oracle.
No doubt you guys simply don't have the cycles to burn on fixing build
scripts that are currently working for you.. but I suspect it will pay
off in the long run. The current version of Gradle, 1.12, is the last
1.x Gradle release before the 2.x versions appear. It may make sense
to achieve compatibility with it. Gradle 2.x is expected to break
things, but once things are working with 1.12, then you can work on
getting rid of the warnings and you will be in a much better position.
Cheers,
Scott
Re: Gradle Scripts
I am using a clone of http://hg.openjdk.java.net/openjfx/8u-dev/rt/
*** I have updated to the 8u5-b13 tag as that is what I was patching.
Perhaps this is the step that puts things out of date? ***
If that's the case I can just hack the min build check as I already have.
Gradle 1.12 fails to build it. I don't understand how the
defineProperty() method can possibly work, as it is out of scope from
windows.gradle and mac.gradle scripts. I encountered this on both
Windows and Mac.
Interesting point about checking in gradle-wrapper.jar. I do believe
it is under the Apache License V2.0... I understand how you must be
careful. You could probably do something clever to add a small script
that would download it from gradle.org for setting up the initial
workspace, rather than checking it in.
I created https://javafx-jira.kenai.com/browse/RT-37290 to cover the
Cygwin issue.
The wiki needs to be updated as it claims: Invoking gradle without
any additional parameters will skip the building of all native code.
See:
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest
According to the wiki there already is a flag for controlling the
build of the native parts: -PBUILD_NATIVES=true
I've field: https://javafx-jira.kenai.com/browse/RT-37291
[Steve's message just came in as I was about to press send, thanks!
You can update the issue as necessary.]
Cheers,
Scott
On Tue, May 27, 2014 at 1:05 PM, Kevin Rushforth
kevin.rushfo...@oracle.com wrote:
I just checked and JavaFX 8u-dev builds fine with JDK 8u5. I suspect you
have an out-of-date repo.
-- Kevin
Kevin Rushforth wrote:
Hi Scott,
I don't think we can use gradle wrapper since it would require checking a
gradle jar file into our repo (there is IP / licensing concern with that).
Regarding your other issues:
1) The Mac issue is a known problem that I still plan to address for 8u20:
https://javafx-jira.kenai.com/browse/RT-34388
2) In the short term we are unlikely to change our production build to a
newer version of gradle, but I know of no reason it won't work with gradle
1.12 (gradle 1.11 is known not to work). Does it build for you with 1.12? I
will try it myself.
3) The version check should work fine with JDK 8u5. Are you cloning
openjfx from the right place? openjfx/8u-dev/rt ? I'm fairly sure this has
been tested, but I will double-check.
4) Yes, we expect cygwin -- mainly for native but also for some of our
legacy any scripts (mostly in closed). We could consider accepting patches
that checked whether a windows build was cygwin and allowed it to build at
least the java code without requiring Cygwin. Did you want to file a JIRA
for this?
5) Native compilation for everything except media and wekbit, is on by
default, and there is currently no easy way to disable it. This is something
Richard had wanted to change back when the gradle build scripts were
developed, but was not finished. At the least, a flag to turn off native
compilation would be good. Do you want to file a JIRA for this?
-- Kevin
Scott Palmer wrote:
I know the wiki says only Gradle 1.8 is guaranteed to work so I have to
ask:
Why not use the Gradle Wrapper to force use of 1.8?
http://www.gradle.org/docs/current/userguide/gradle_wrapper.html
Well, I tried tweaking the build scripts to use it myself, running on
OS X and found that the scripts appear to be badly broken anyway and
they can't even be parsed with later Gradle versions so you can't even
run the wrapper task:
The error is:
Could not find method 'defineProperty() for arguments
[MACOSX_MIN_VERSION, 10.7] on root project .
Sure enough the defineProperty method is being called from a different
.gradle file than the one in which it is defined, so it is out of
scope. I corrected this locally by changing it to a closure and
assigning it to project.ext.defineProperty. Then I added:
task wrapper(type: Wrapper) {
gradleVersion = 1.8'
}
and was able to get the gradlew script created by running:
gradle wrapper
So then I tried to build with Gradle 1.8 by running:
./gradlew
Then I hit :verifyJava complaining that the build number (13) was too
low ( 115)... but I'm building the 8u5 code with the 8u5 release...
that seems like a combination that should work.
I think everyone (myself included) would be more inclined to help with
patches if it wasn't such a pain to build. I appreciate that prior to
the use of Gradle this was likely much worse. Gradle is a great build
system and should be able to make this an even simpler process.
On Windows for what I assume are historical reasons, Cygwin is
expected. I'm only trying to build the Java side of things.. not the
native DLLs and I don't see Cygwin doing anything of value in the
build scripts for that case. It's mangling paths that don't need to
be mangle for example.
I think the build scripts could be cleaned up to provide a much
smoother build experience for
Re: Gradle Scripts
*** I have updated to the 8u5-b13 tag as that is what I was patching.
Perhaps this is the step that puts things out of date? ***
Yes, that would be it, since it would not contain the fix for:
RT-36163: Cannot build JavaFX using JDK 8u20 or JDK 9
(same bug would affect building with 8u5)
Disabling the min build check will be a fine workaround.
Gradle 1.12 fails to build it. I don't understand how the
defineProperty() method can possibly work, as it is out of scope from
windows.gradle and mac.gradle scripts. I encountered this on both
Windows and Mac.
It does look like there are issues in building with 1.12 -- a closed
build falls over and dies even earlier (before buildSrc is compiled). If
you would like to file a JIRA we can look into it for 8u40. It would be
great to fix the scripts so it works with 1.8 and 1.12.
-- Kevin
Scott Palmer wrote:
I am using a clone of http://hg.openjdk.java.net/openjfx/8u-dev/rt/
*** I have updated to the 8u5-b13 tag as that is what I was patching.
Perhaps this is the step that puts things out of date? ***
If that's the case I can just hack the min build check as I already have.
Gradle 1.12 fails to build it. I don't understand how the
defineProperty() method can possibly work, as it is out of scope from
windows.gradle and mac.gradle scripts. I encountered this on both
Windows and Mac.
Interesting point about checking in gradle-wrapper.jar. I do believe
it is under the Apache License V2.0... I understand how you must be
careful. You could probably do something clever to add a small script
that would download it from gradle.org for setting up the initial
workspace, rather than checking it in.
I created https://javafx-jira.kenai.com/browse/RT-37290 to cover the
Cygwin issue.
The wiki needs to be updated as it claims: Invoking gradle without
any additional parameters will skip the building of all native code.
See:
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest
According to the wiki there already is a flag for controlling the
build of the native parts: -PBUILD_NATIVES=true
I've field: https://javafx-jira.kenai.com/browse/RT-37291
[Steve's message just came in as I was about to press send, thanks!
You can update the issue as necessary.]
Cheers,
Scott
On Tue, May 27, 2014 at 1:05 PM, Kevin Rushforth
kevin.rushfo...@oracle.com wrote:
I just checked and JavaFX 8u-dev builds fine with JDK 8u5. I suspect you
have an out-of-date repo.
-- Kevin
Kevin Rushforth wrote:
Hi Scott,
I don't think we can use gradle wrapper since it would require checking a
gradle jar file into our repo (there is IP / licensing concern with that).
Regarding your other issues:
1) The Mac issue is a known problem that I still plan to address for 8u20:
https://javafx-jira.kenai.com/browse/RT-34388
2) In the short term we are unlikely to change our production build to a
newer version of gradle, but I know of no reason it won't work with gradle
1.12 (gradle 1.11 is known not to work). Does it build for you with 1.12? I
will try it myself.
3) The version check should work fine with JDK 8u5. Are you cloning
openjfx from the right place? openjfx/8u-dev/rt ? I'm fairly sure this has
been tested, but I will double-check.
4) Yes, we expect cygwin -- mainly for native but also for some of our
legacy any scripts (mostly in closed). We could consider accepting patches
that checked whether a windows build was cygwin and allowed it to build at
least the java code without requiring Cygwin. Did you want to file a JIRA
for this?
5) Native compilation for everything except media and wekbit, is on by
default, and there is currently no easy way to disable it. This is something
Richard had wanted to change back when the gradle build scripts were
developed, but was not finished. At the least, a flag to turn off native
compilation would be good. Do you want to file a JIRA for this?
-- Kevin
Scott Palmer wrote:
I know the wiki says only Gradle 1.8 is guaranteed to work so I have to
ask:
Why not use the Gradle Wrapper to force use of 1.8?
http://www.gradle.org/docs/current/userguide/gradle_wrapper.html
Well, I tried tweaking the build scripts to use it myself, running on
OS X and found that the scripts appear to be badly broken anyway and
they can't even be parsed with later Gradle versions so you can't even
run the wrapper task:
The error is:
Could not find method 'defineProperty() for arguments
[MACOSX_MIN_VERSION, 10.7] on root project .
Sure enough the defineProperty method is being called from a different
.gradle file than the one in which it is defined, so it is out of
scope. I corrected this locally by changing it to a closure and
assigning it to project.ext.defineProperty. Then I added:
task wrapper(type: Wrapper) {
gradleVersion = 1.8'
}
and was able to get the gradlew script created by running:
gradle wrapper
So then I tried to build with Gradle 1.8 by running:
./gradlew
Then I hit :verifyJava
hg: openjfx/8u-dev/rt: RT-33665: [SwingNode, Linux] : combobox can not get item change events
Changeset: 3a38a1ed0e23 Author:Anthony Petrov anthony.pet...@oracle.com Date: 2014-05-27 21:46 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3a38a1ed0e23 RT-33665: [SwingNode, Linux] : combobox can not get item change events Summary: Don't delegate grab focus requests to FX on Linux ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java
hg: openjfx/8u-dev/rt: RT-37277 fix addNative in dalvik, update jar filter
Changeset: 2dcb43d25d9a Author:ddhill Date: 2014-05-27 17:01 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2dcb43d25d9a RT-37277 fix addNative in dalvik, update jar filter Reviewed-by: johanvos ! buildSrc/dalvik.gradle
Re: Bad performance with Canvas and extensive clipping
You may have been testing J2D in a pre-retina-aware VM vs. JavaFX which
was retina aware a little earlier than J2D (due to JavaFX being on a
slightly more liberal feature policy for new releases). I think J2D
went retina-aware in 8.0, are you using 8.0 for those tests?
The screenshot may be because the snapshot and robot mechanisms may not
be retina-aware yet.
I don't think there are significant differences in the font technologies
between J2D and FX...
...jim
On 5/24/14 6:54 AM, Tom Schindl wrote:
Hi,
another big difference when using the a BufferedImage is to that the
font rendering is catastrophic, hope to offend nobody. I'm not very good
a AWT maybe I made a dumb mistake?
See http://downloads.efxclipse.org/font_j2d_fx.png - the j2d font looks
completely blurred in contrast to the sharp JavaFX Canvas version in the
foreground.
Similar blurring happens when makeing screenshots of a canvas - I've
written a small sample application showing problems I am seeing which
gets me to an image as in this link
http://downloads.efxclipse.org/screen_compare.png.
Could I somehow use the javafx font-rendering push it to a bitmap and
draw it on the buffered image?
Anyways those are all only workarounds for javafx canvas inefficiencies
that e.g. awt does not have.
package application;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.awt.image.BufferedImage;
import javafx.application.Application;
import javafx.embed.swing.SwingFXUtils;
import javafx.geometry.VPos;
import javafx.scene.Node;
import javafx.scene.Scene;
import javafx.scene.SnapshotParameters;
import javafx.scene.canvas.Canvas;
import javafx.scene.control.Label;
import javafx.scene.image.ImageView;
import javafx.scene.image.WritableImage;
import javafx.scene.layout.HBox;
import javafx.scene.layout.VBox;
import javafx.scene.paint.Color;
import javafx.scene.text.Font;
import javafx.stage.Stage;
public class Main extends Application {
private WritableImage img;
@Override
public void start(Stage primaryStage) {
try {
HBox root = new HBox();
Scene scene = new Scene(root,400,400);
scene.getStylesheets().add(getClass().getResource(application.css).toExternalForm());
root.getChildren().add(createCanvas());
root.getChildren().add(createBufferedCanvas());
root.getChildren().add(new VBox(new ImageView(img), new
Label(Snapshot)));
primaryStage.setScene(scene);
primaryStage.show();
} catch(Exception e) {
e.printStackTrace();
}
}
private Node createBufferedCanvas() {
VBox b = new VBox();
b.setStyle(-fx-border-style: solid; -fx-border-width: 2px;);
Canvas c = new Canvas(150, 150);
BufferedImage img = new BufferedImage(150, 150,
BufferedImage.TYPE_INT_ARGB);
Graphics2D graphics = img.createGraphics();
graphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
graphics.setColor(java.awt.Color.BLACK);
graphics.setFont(new java.awt.Font(Font.getDefault().getName(),
java.awt.Font.PLAIN, 20));
graphics.drawString(Hello World!, 0, 20);
img.flush();
c.getGraphicsContext2D().drawImage(SwingFXUtils.toFXImage(img,
null),10,10);
b.getChildren().add(c);
b.getChildren().add(new Label(Buffered-Canvas));
return b;
}
private Node createCanvas() {
VBox b = new VBox();
b.setStyle(-fx-border-style: solid; -fx-border-width: 2px;);
Canvas c = new Canvas(150, 150);
c.getGraphicsContext2D().setFont(Font.font(Font.getDefault().getName(),20));
c.getGraphicsContext2D().setTextBaseline(VPos.TOP);
c.getGraphicsContext2D().fillText(Hello World, 10, 10);
SnapshotParameters parameters = new SnapshotParameters();
parameters.setFill(Color.TRANSPARENT);
img = c.snapshot(parameters,null);
b.getChildren().add(c);
b.getChildren().add(new Label(FX-Canvas));
return b;
}
public static void main(String[] args) {
launch(args);
}
}
Tom
On 24.05.14 02:46, Tom Schindl wrote:
Hi,
As an experiment I've now written a SWT-GC implementation using a
BufferedImage Graphics2D and transfering the pixels over to JavaFX and
the performance is as it is with native SWT.
I
Re: Bad performance with Canvas and extensive clipping
Canvas is, essentially, a draw pixels mechanism. We have to bundle
the requests into a command stream due to threading issues, but when the
requests get to the render thread then they get turned into pixels so
the command stream is a temporary intermediary. Some of the hw J2D
pipelines also have a temporary command stream due to platform threading
issues as well. It all depends on which pipeline you use and on which
platform in the case of J2D. FX simply normalized the threading on all
pipelines/platforms so that we have a separate UI and render thread in
all cases, but that concept is not foreign to J2D either.
I'm fairly certain that the lack of simple rectangular clipping is
probably the biggest cause of your performance problems. We do AA on
everything in FX, though, whereas rendering to a BufferedImage by
default will be non-AA unless you requested AA using the graphics hints.
But on the up-side, we hw accelerate just about every operation in FX
so it should be on par with performance there, modulo the lack of
rectangular clipping...
...jim
On 5/23/14 5:46 PM, Tom Schindl wrote:
Hi,
As an experiment I've now written a SWT-GC implementation using a
BufferedImage Graphics2D and transfering the pixels over to JavaFX and
the performance is as it is with native SWT.
I always thought Canvas works similar to Image and one only draws pixels
- looks like that is not the case, having a dep in my application
java.awt is not what I'm aiming at but without acceptable performance in
conjunction with clipping it looks like i have to go this route :-(
Tom
On 23.05.14 23:57, Tom Schindl wrote:
In the current usecase it is a rect all time but that's just in this special
use case.
I guess that rect clipping is the most common one so having an optimization for
rects and a slow path for none rects might help.
Tom
Von meinem iPhone gesendet
Am 23.05.2014 um 23:35 schrieb Jim Graham james.gra...@oracle.com:
Are you clipping to an arbitrary path in all cases or just a rectangle?
Unfortunately we only offer the arbitrary clip-to-current-path method that
isn't optimized for basic rectangular clipping and it implements soft clipping.
There is an outstanding tweak that we added faster clipping support for WebNode and we
need to start using it for Node.setClipNode(non-rectangle) and Canvas, but we haven't
implemented that yet. (https://javafx-jira.kenai.com/browse/RT-30107) It basically is a
direct render this texture through that other texture as a clip operation
instead of the current code that runs it through some Blend effect filters. It would
definitely improve your run times, but I'm not sure how much.
Even more savings could be had for rectangular clips if we provided some way to
communicate them to the GC...
...jim
On 5/23/14 11:47 AM, Tom Schindl wrote:
Hi,
Maybe as some of you might know I've been working since sometime on SWT
on JavaFX and to implement direct drawing operations we use JavaFX-Canvas.
I've today tried to run a heavy direct drawing grid implementation and
it performed very bad because it makes heavy use of clipping.
For a grid I've counted ~1500 clipping operations the library works
something like this:
boolean activeClip;
Canvas canvas = new Canvas();
public void setClipping(PathIterator pathIterator) {
GraphicsContext gc = canvas.getGraphicsContext2D();
if(activeClip) {
gc.restore();
activeClip= false;
}
if( pathIterator == null ) {
return;
}
activeClip = true;
float coords[] = new float[6];
gc.save();
gc.beginPath();
float x = 0;
float y = 0;
gc.moveTo(0, 0);
while( ! pathIterator.isDone() ) {
switch (pathIterator.currentSegment(coords)) {
case PathIterator.SEG_CLOSE:
gc.lineTo(x, y);
break;
case PathIterator.SEG_CUBICTO:
gc.bezierCurveTo(coords[0], coords[1], coords[2], coords[3],
coords[4], coords[5]);
break;
case PathIterator.SEG_LINETO:
gc.lineTo(coords[0], coords[1]);
break;
case PathIterator.SEG_MOVETO:
gc.moveTo(coords[0], coords[1]);
x = coords[0];
y = coords[1];
break;
case PathIterator.SEG_QUADTO:
gc.quadraticCurveTo(coords[0], coords[1], coords[2], coords[3]);
break;
default:
break;
}
pathIterator.next();
}
gc.clip();
gc.closePath();
}
Am I doing something ultimately wrong, totally wrong? Has anyone an idea
how I would work around the problem?
Tom
Re: Bad performance with Canvas and extensive clipping
I'm on java8u5!
Tom
On 27.05.14 23:38, Jim Graham wrote:
You may have been testing J2D in a pre-retina-aware VM vs. JavaFX which
was retina aware a little earlier than J2D (due to JavaFX being on a
slightly more liberal feature policy for new releases). I think J2D
went retina-aware in 8.0, are you using 8.0 for those tests?
The screenshot may be because the snapshot and robot mechanisms may not
be retina-aware yet.
I don't think there are significant differences in the font technologies
between J2D and FX...
...jim
On 5/24/14 6:54 AM, Tom Schindl wrote:
Hi,
another big difference when using the a BufferedImage is to that the
font rendering is catastrophic, hope to offend nobody. I'm not very good
a AWT maybe I made a dumb mistake?
See http://downloads.efxclipse.org/font_j2d_fx.png - the j2d font looks
completely blurred in contrast to the sharp JavaFX Canvas version in the
foreground.
Similar blurring happens when makeing screenshots of a canvas - I've
written a small sample application showing problems I am seeing which
gets me to an image as in this link
http://downloads.efxclipse.org/screen_compare.png.
Could I somehow use the javafx font-rendering push it to a bitmap and
draw it on the buffered image?
Anyways those are all only workarounds for javafx canvas inefficiencies
that e.g. awt does not have.
package application;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.awt.image.BufferedImage;
import javafx.application.Application;
import javafx.embed.swing.SwingFXUtils;
import javafx.geometry.VPos;
import javafx.scene.Node;
import javafx.scene.Scene;
import javafx.scene.SnapshotParameters;
import javafx.scene.canvas.Canvas;
import javafx.scene.control.Label;
import javafx.scene.image.ImageView;
import javafx.scene.image.WritableImage;
import javafx.scene.layout.HBox;
import javafx.scene.layout.VBox;
import javafx.scene.paint.Color;
import javafx.scene.text.Font;
import javafx.stage.Stage;
public class Main extends Application {
private WritableImage img;
@Override
public void start(Stage primaryStage) {
try {
HBox root = new HBox();
Scene scene = new Scene(root,400,400);
scene.getStylesheets().add(getClass().getResource(application.css).toExternalForm());
root.getChildren().add(createCanvas());
root.getChildren().add(createBufferedCanvas());
root.getChildren().add(new VBox(new ImageView(img), new
Label(Snapshot)));
primaryStage.setScene(scene);
primaryStage.show();
} catch(Exception e) {
e.printStackTrace();
}
}
private Node createBufferedCanvas() {
VBox b = new VBox();
b.setStyle(-fx-border-style: solid; -fx-border-width: 2px;);
Canvas c = new Canvas(150, 150);
BufferedImage img = new BufferedImage(150, 150,
BufferedImage.TYPE_INT_ARGB);
Graphics2D graphics = img.createGraphics();
graphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
graphics.setColor(java.awt.Color.BLACK);
graphics.setFont(new
java.awt.Font(Font.getDefault().getName(), java.awt.Font.PLAIN, 20));
graphics.drawString(Hello World!, 0, 20);
img.flush();
c.getGraphicsContext2D().drawImage(SwingFXUtils.toFXImage(img,
null),10,10);
b.getChildren().add(c);
b.getChildren().add(new Label(Buffered-Canvas));
return b;
}
private Node createCanvas() {
VBox b = new VBox();
b.setStyle(-fx-border-style: solid; -fx-border-width: 2px;);
Canvas c = new Canvas(150, 150);
c.getGraphicsContext2D().setFont(Font.font(Font.getDefault().getName(),20));
c.getGraphicsContext2D().setTextBaseline(VPos.TOP);
c.getGraphicsContext2D().fillText(Hello World, 10, 10);
SnapshotParameters parameters = new SnapshotParameters();
parameters.setFill(Color.TRANSPARENT);
img = c.snapshot(parameters,null);
b.getChildren().add(c);
b.getChildren().add(new Label(FX-Canvas));
return b;
}
public static void main(String[] args) {
launch(args);
}
}
Tom
On 24.05.14 02:46, Tom Schindl wrote:
Hi,
As an experiment I've now written a SWT-GC implementation using a
BufferedImage Graphics2D and transfering the pixels over to JavaFX and
the performance is as it is with native SWT.
I always thought Canvas works similar to Image and one only draws pixels
- looks like that is not the case, having a dep in my application
java.awt is not what I'm aiming at but without acceptable performance in
conjunction with clipping it looks like i have to go this route :-(
Tom
On 23.05.14 23:57, Tom Schindl
Re: Bad performance with Canvas and extensive clipping
Is there anything I could do to help getting rectangular clipping into
JavaFX - I tried to find my way through the sources but I'm not sure I
have enough knowledge to provide a patch in this area.
BTW it looks like I'm not alone with the clipping performance problem
see
http://tomsondev.bestsolution.at/2014/05/24/swtonfx-javafx-canvas-with-many-clipping-calls-unacceptable-slow/#comments
Tom
On 27.05.14 23:47, Jim Graham wrote:
Canvas is, essentially, a draw pixels mechanism. We have to bundle
the requests into a command stream due to threading issues, but when the
requests get to the render thread then they get turned into pixels so
the command stream is a temporary intermediary. Some of the hw J2D
pipelines also have a temporary command stream due to platform threading
issues as well. It all depends on which pipeline you use and on which
platform in the case of J2D. FX simply normalized the threading on all
pipelines/platforms so that we have a separate UI and render thread in
all cases, but that concept is not foreign to J2D either.
I'm fairly certain that the lack of simple rectangular clipping is
probably the biggest cause of your performance problems. We do AA on
everything in FX, though, whereas rendering to a BufferedImage by
default will be non-AA unless you requested AA using the graphics hints.
But on the up-side, we hw accelerate just about every operation in FX
so it should be on par with performance there, modulo the lack of
rectangular clipping...
...jim
On 5/23/14 5:46 PM, Tom Schindl wrote:
Hi,
As an experiment I've now written a SWT-GC implementation using a
BufferedImage Graphics2D and transfering the pixels over to JavaFX and
the performance is as it is with native SWT.
I always thought Canvas works similar to Image and one only draws pixels
- looks like that is not the case, having a dep in my application
java.awt is not what I'm aiming at but without acceptable performance in
conjunction with clipping it looks like i have to go this route :-(
Tom
On 23.05.14 23:57, Tom Schindl wrote:
In the current usecase it is a rect all time but that's just in this
special use case.
I guess that rect clipping is the most common one so having an
optimization for rects and a slow path for none rects might help.
Tom
Von meinem iPhone gesendet
Am 23.05.2014 um 23:35 schrieb Jim Graham james.gra...@oracle.com:
Are you clipping to an arbitrary path in all cases or just a
rectangle? Unfortunately we only offer the arbitrary
clip-to-current-path method that isn't optimized for basic
rectangular clipping and it implements soft clipping.
There is an outstanding tweak that we added faster clipping support
for WebNode and we need to start using it for
Node.setClipNode(non-rectangle) and Canvas, but we haven't
implemented that yet.
(https://javafx-jira.kenai.com/browse/RT-30107) It basically is a
direct render this texture through that other texture as a clip
operation instead of the current code that runs it through some
Blend effect filters. It would definitely improve your run times,
but I'm not sure how much.
Even more savings could be had for rectangular clips if we provided
some way to communicate them to the GC...
...jim
On 5/23/14 11:47 AM, Tom Schindl wrote:
Hi,
Maybe as some of you might know I've been working since sometime on
SWT
on JavaFX and to implement direct drawing operations we use
JavaFX-Canvas.
I've today tried to run a heavy direct drawing grid implementation and
it performed very bad because it makes heavy use of clipping.
For a grid I've counted ~1500 clipping operations the library works
something like this:
boolean activeClip;
Canvas canvas = new Canvas();
public void setClipping(PathIterator pathIterator) {
GraphicsContext gc = canvas.getGraphicsContext2D();
if(activeClip) {
gc.restore();
activeClip= false;
}
if( pathIterator == null ) {
return;
}
activeClip = true;
float coords[] = new float[6];
gc.save();
gc.beginPath();
float x = 0;
float y = 0;
gc.moveTo(0, 0);
while( ! pathIterator.isDone() ) {
switch (pathIterator.currentSegment(coords)) {
case PathIterator.SEG_CLOSE:
gc.lineTo(x, y);
break;
case PathIterator.SEG_CUBICTO:
gc.bezierCurveTo(coords[0], coords[1], coords[2],
coords[3],
coords[4], coords[5]);
break;
case PathIterator.SEG_LINETO:
gc.lineTo(coords[0], coords[1]);
break;
case PathIterator.SEG_MOVETO:
gc.moveTo(coords[0], coords[1]);
x = coords[0];
y = coords[1];
break;
case PathIterator.SEG_QUADTO:
gc.quadraticCurveTo(coords[0], coords[1],
coords[2], coords[3]);
Re: Bad performance with Canvas and extensive clipping
Hi Tom, There are 2 upgrades to consider. One involves new API, but is probably best in the long run. Without API, we'd have to detect if the path were rectangular in the processing of the CLIP command in NGCanvas.java. If the 4 coordinates are an axis aligned rectangle on integer coordinates then we could special case that with g.setClipRect(). There are other considerations, such as: - If there is already a soft non-rect clip, then it should probably not bother with the special case since it won't simplify anything. - If we have special cased the rectangle, then we must track that across save/restore properly. - If we have a special case cliprect and then we get a non-special case rect as the argument of a CLIP command, then we need to resolve it into a singular case (most likely default back to soft clipping). - The processing that tries to detect are they clearing the entire buffer needs to be aware of any clip in effect - those tests are done at the javafx.scene.canvas.GraphicsContext level. We could put that fix in with no new API so it could go in as soon as we are satisfied with its stability. If we want to add new API, so that you don't have to construct a path every time you want to do clipRect() and we don't have to decipher your path to figure out that it is a rectangle, then we would have to wait for the next opportunity to add API (FX can add API in between major JDK releases, but there is a process to go through and I don't think we can do it for 8u20 any more). The process for that would be: javafx.scene.canvas.GraphicsContext would need a new method that would take the rectangular clipping parameters and put them into the buffer. The existing fillRect() method would provide a good template. A new command code constant would have to be added to represent This is a clip rectangle request. NGCanvas would then need to digest the new buffer commands and I believe that the existing Prism call g.setClipRect() would work to enable the scissor clip (fast rectangular clipping). The question is what is the proper API? If we have it take doubles, would that imply to developers that there would be soft clipping of the edges similar to if you used a rectangular path and clip()? Right now Node.setClipNode(Rectangle) will do the fast scissor clip (g.setClipRect()) if the coordinates fall on integer axis-aligned coordinates, but it will do soft-edged clipping if there is rotation/skewing, or the coordinates are not integers. That would probably be the best API to mimic since HTML5 doesn't have a similar cliprect method... ...jim On 5/27/14 2:57 PM, Tom Schindl wrote: Is there anything I could do to help getting rectangular clipping into JavaFX - I tried to find my way through the sources but I'm not sure I have enough knowledge to provide a patch in this area. BTW it looks like I'm not alone with the clipping performance problem see http://tomsondev.bestsolution.at/2014/05/24/swtonfx-javafx-canvas-with-many-clipping-calls-unacceptable-slow/#comments Tom On 27.05.14 23:47, Jim Graham wrote: Canvas is, essentially, a draw pixels mechanism. We have to bundle the requests into a command stream due to threading issues, but when the requests get to the render thread then they get turned into pixels so the command stream is a temporary intermediary. Some of the hw J2D pipelines also have a temporary command stream due to platform threading issues as well. It all depends on which pipeline you use and on which platform in the case of J2D. FX simply normalized the threading on all pipelines/platforms so that we have a separate UI and render thread in all cases, but that concept is not foreign to J2D either. I'm fairly certain that the lack of simple rectangular clipping is probably the biggest cause of your performance problems. We do AA on everything in FX, though, whereas rendering to a BufferedImage by default will be non-AA unless you requested AA using the graphics hints. But on the up-side, we hw accelerate just about every operation in FX so it should be on par with performance there, modulo the lack of rectangular clipping... ...jim On 5/23/14 5:46 PM, Tom Schindl wrote: Hi, As an experiment I've now written a SWT-GC implementation using a BufferedImage Graphics2D and transfering the pixels over to JavaFX and the performance is as it is with native SWT. I always thought Canvas works similar to Image and one only draws pixels - looks like that is not the case, having a dep in my application java.awt is not what I'm aiming at but without acceptable performance in conjunction with clipping it looks like i have to go this route :-( Tom On 23.05.14 23:57, Tom Schindl wrote: In the current usecase it is a rect all time but that's just in this special use case. I guess that rect clipping is the most common one so having an optimization for rects and a slow path for none rects might help. Tom Von
Re: Bad performance with Canvas and extensive clipping
My apologies. If Swing was managing the back buffer for you then they
would make it retina-aware for you on 8.0. If you are creating your own
BufferedImage then it will not be retina-scaled unless you do that
yourself. Right now we are working to get the Swing embedded in FX
mechanisms to be retina-aware and it isn't a trivial task.
I'll have to look and see how Swing manages it to know if you can tap
into the same mechanisms, but it involves creating an image twice as big
as you need and then rendering into it with a default graphics scale of
2.0 and then making sure you render it at the right size to the
destination. (Which is shoveling pixels into a WritableImage I presume?
You'd have to make sure to set the right fitWidth/Height to keep them
at the right destination scale.) Swing is already doing that for you
with the hidden back buffer, but it is hard to redirect that to FX. The
Swing-to-FX mechanism will soon be able to do that for you, but your
project may not be happy pretending it is a Swing component to achieve
that goal.
Or, we could get Canvas to do faster rectangular clipping...
...jim
On 5/27/14 2:54 PM, Tom Schindl wrote:
I'm on java8u5!
Tom
On 27.05.14 23:38, Jim Graham wrote:
You may have been testing J2D in a pre-retina-aware VM vs. JavaFX which
was retina aware a little earlier than J2D (due to JavaFX being on a
slightly more liberal feature policy for new releases). I think J2D
went retina-aware in 8.0, are you using 8.0 for those tests?
The screenshot may be because the snapshot and robot mechanisms may not
be retina-aware yet.
I don't think there are significant differences in the font technologies
between J2D and FX...
...jim
On 5/24/14 6:54 AM, Tom Schindl wrote:
Hi,
another big difference when using the a BufferedImage is to that the
font rendering is catastrophic, hope to offend nobody. I'm not very good
a AWT maybe I made a dumb mistake?
See http://downloads.efxclipse.org/font_j2d_fx.png - the j2d font looks
completely blurred in contrast to the sharp JavaFX Canvas version in the
foreground.
Similar blurring happens when makeing screenshots of a canvas - I've
written a small sample application showing problems I am seeing which
gets me to an image as in this link
http://downloads.efxclipse.org/screen_compare.png.
Could I somehow use the javafx font-rendering push it to a bitmap and
draw it on the buffered image?
Anyways those are all only workarounds for javafx canvas inefficiencies
that e.g. awt does not have.
package application;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.awt.image.BufferedImage;
import javafx.application.Application;
import javafx.embed.swing.SwingFXUtils;
import javafx.geometry.VPos;
import javafx.scene.Node;
import javafx.scene.Scene;
import javafx.scene.SnapshotParameters;
import javafx.scene.canvas.Canvas;
import javafx.scene.control.Label;
import javafx.scene.image.ImageView;
import javafx.scene.image.WritableImage;
import javafx.scene.layout.HBox;
import javafx.scene.layout.VBox;
import javafx.scene.paint.Color;
import javafx.scene.text.Font;
import javafx.stage.Stage;
public class Main extends Application {
private WritableImage img;
@Override
public void start(Stage primaryStage) {
try {
HBox root = new HBox();
Scene scene = new Scene(root,400,400);
scene.getStylesheets().add(getClass().getResource(application.css).toExternalForm());
root.getChildren().add(createCanvas());
root.getChildren().add(createBufferedCanvas());
root.getChildren().add(new VBox(new ImageView(img), new
Label(Snapshot)));
primaryStage.setScene(scene);
primaryStage.show();
} catch(Exception e) {
e.printStackTrace();
}
}
private Node createBufferedCanvas() {
VBox b = new VBox();
b.setStyle(-fx-border-style: solid; -fx-border-width: 2px;);
Canvas c = new Canvas(150, 150);
BufferedImage img = new BufferedImage(150, 150,
BufferedImage.TYPE_INT_ARGB);
Graphics2D graphics = img.createGraphics();
graphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
graphics.setColor(java.awt.Color.BLACK);
graphics.setFont(new
java.awt.Font(Font.getDefault().getName(), java.awt.Font.PLAIN, 20));
graphics.drawString(Hello World!, 0, 20);
img.flush();
c.getGraphicsContext2D().drawImage(SwingFXUtils.toFXImage(img,
null),10,10);
b.getChildren().add(c);
b.getChildren().add(new Label(Buffered-Canvas));
return b;
}
private Node createCanvas() {
VBox b = new VBox();
b.setStyle(-fx-border-style: solid; -fx-border-width: 2px;);
Canvas c = new Canvas(150, 150);
