8u20 review request: RT-37475 shadow in Ensemble8 Puzzle Pieces demo gets erased

[Jim Graham]

webrev: http://cr.openjdk.java.net/~flar/RT-37475/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-37475

Lengthy explanation of an "aha" moment in the Jira, but the actual fix 
is fairly simple...


...jim

Re: All-Permissions not working properly with sun.plugin2.applet.FXAppletSecurityManager

[Scott Palmer]

Thank you.

Is there a way that people that are not project authors can get notifications 
of updates?  I can’t click to add myself to the watch list or vote without a 
login, and it seems to be near impossible to get a login.
The "Account Help” link on the login page is broken and everything I’ve found 
in the wiki indicates I need to be a project author to get an account.

Scott


On Jun 13, 2014, at 8:05 PM, Kevin Rushforth  wrote:

> Hi Scott,
> 
> I created two new non-confidential bugs and closed the original ones as 
> duplicates. Here are the new bugs:
> 
> 
> reflection in daemon thread: 
> JDK-8046825 (was JDK-8040699) : All-Permissions not working properly with 
> sun.plugin2.applet.FXAppletSecurityManager
> 
> security manager and applet-desc webstart mode: 
> JDK-8046826 (was JDK-8040231) : All permission fx javaws app could not set 
> Security Manager to null.
> 
> I have copied Dmitry in case he has any information about these bugs.
> 
> -- Kevin
> 
> 
> Kevin Rushforth wrote:
>> 
>> Dmitry can comment further, but it is possible that this issue could be 
>> backported to 8u40 if done soon enough. 
>> 
>> I will double-check whether the bugs can be made non-confidential (so you 
>> can at least track progress), but I suspect they cannot in their current 
>> form, in which case new bugs should be filed with the confidential 
>> information moved to confidential comments in the bug. I will help with 
>> this. 
>> 
>> -- Kevin 
>> 
>> 
>> Scott Palmer wrote: 
>>> Drat... I was hoping to see something much sooner, like 8u20 (obviously too 
>>> late now) or 8u40.  I'm unable to use Web Start deployment because of this. 
>>> 
>>> Is it necessary for these issues to be blocked from anonymous viewing? 
>>> 
>>> Thanks for the update. 
>>> 
>>> Scott 
>>> 
>>> 
>>> On Wed, Jun 11, 2014 at 11:57 AM, Kevin Rushforth 
>>> mailto:kevin.rushfo...@oracle.com>> wrote: 
>>> 
>>> These are now assigned to Dmitry Cherapanov who I have copied here 
>>> in case he isn't on the openjfx alias. They are both targeted to 
>>> JDK 9. 
>>> 
>>> -- Kevin 
>>> 
>>> 
>>> Scott Palmer wrote: 
>>> 
>>> I tried to send an email to Thomas asking about the status of 
>>> these issues 
>>> (they are not visible to me), but the email bounced (user 
>>> unknown).  Could 
>>> someone let me know the status? 
>>> 
>>> Thanks, 
>>> 
>>> Scott 
>>> 
>>> 
>>> On Thu, Apr 17, 2014 at 1:25 AM, Thomas Ng 
>>> mailto:thomas.v...@oracle.com>> wrote: 
>>> 
>>>  
>>>  Thanks for the report! 
>>> 
>>> Two bugs created for this: 
>>> 
>>> security manager and applet-desc webstart mode: 
>>> https://bugs.openjdk.java.net/browse/JDK-8040231 
>>> 
>>> reflection in daemon thread: 
>>> https://bugs.openjdk.java.net/browse/JDK-8040699 
>>> 
>>> -thomas 
>>> 
>>> 
>>>   *From: *Scott Palmer >> > 
>>>  *Subject: **All-Permissions not working properly with 
>>> sun.plugin2.applet.FXAppletSecurityManager* 
>>>  *Date: *April 14, 2014 at 1:07:36 PM PDT 
>>>  *To: *"openjfx-dev@openjdk.java.net 
>>> " 
>>> >> > 
>>> 
>>> 
>>> Can someone confirm that all-permissions is working for 
>>> JavaFX apps 
>>> that are launched via Web Start with Java 8.0 and use 
>>> daemon threads 
>>> in a Service? 
>>> 
>>> I have a JNLP file that has: 
>>>  
>>>   
>>>  
>>> 
>>> and the manifest of my app's jar has the following 
>>> instruction in my 
>>> Gradle script: 
>>> 
>>> jar { 
>>>manifest { 
>>>attributes('Permissions': 'all-permissions', 
>>>   'Codebase': '*') 
>>>} 
>>> } 
>>> 
>>> I'm using the javafx gradle plugin and signing the jars... 
>>> e.g. I see this for every dependency and the main jar: 
>>> ... 
>>> Signing (BLOB) C:\Users\scott\.m2\caches\path\to\some.jar 
>>> Signed as C:\Users\scott\dev\MyProject\build\libs\some.jar 
>>> ... 
>>> 
>>> I even tried System.setSecurityManager(null); in my 
>>> start() method 
>>> (and it lets me do it). 
>>> 
>>> However, daemon threads started by my Service are unable 
>>> to use 
>>> reflection. (It is working in the main FX application 
>>> thread.)  I see 
>>> the following stack trace in the Java console: 
>>> 
>>> 
>>> Caused by: java.security.AccessControlException: access denied 
>>> ("j

Re: Fwd: All-Permissions not working properly with sun.plugin2.applet.FXAppletSecurityManager

[Kevin Rushforth]

Hi Scott,

I created two new non-confidential bugs and closed the original ones as 
duplicates. Here are the new bugs:



reflection in daemon thread:
JDK-8046825  (was 
JDK-8040699) : All-Permissions not working properly with 
sun.plugin2.applet.FXAppletSecurityManager


security manager and applet-desc webstart mode:
JDK-8046826  (was 
JDK-8040231) : All permission fx javaws app could not set Security 
Manager to null.


I have copied Dmitry in case he has any information about these bugs.

-- Kevin


Kevin Rushforth wrote:
Dmitry can comment further, but it is possible that this issue could 
be backported to 8u40 if done soon enough.


I will double-check whether the bugs can be made non-confidential (so 
you can at least track progress), but I suspect they cannot in their 
current form, in which case new bugs should be filed with the 
confidential information moved to confidential comments in the bug. I 
will help with this.


-- Kevin


Scott Palmer wrote:
Drat... I was hoping to see something much sooner, like 8u20 
(obviously too late now) or 8u40.  I'm unable to use Web Start 
deployment because of this.


Is it necessary for these issues to be blocked from anonymous viewing?

Thanks for the update.

Scott


On Wed, Jun 11, 2014 at 11:57 AM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


These are now assigned to Dmitry Cherapanov who I have copied here
in case he isn't on the openjfx alias. They are both targeted to
JDK 9.

-- Kevin


Scott Palmer wrote:

I tried to send an email to Thomas asking about the status of
these issues
(they are not visible to me), but the email bounced (user
unknown).  Could
someone let me know the status?

Thanks,

Scott


On Thu, Apr 17, 2014 at 1:25 AM, Thomas Ng
mailto:thomas.v...@oracle.com>> wrote:


 Thanks for the report!


Two bugs created for this:

security manager and applet-desc webstart mode:
https://bugs.openjdk.java.net/browse/JDK-8040231

reflection in daemon thread:
https://bugs.openjdk.java.net/browse/JDK-8040699

-thomas


  *From: *Scott Palmer mailto:swpal...@gmail.com>>
 *Subject: **All-Permissions not working properly with
sun.plugin2.applet.FXAppletSecurityManager*
 *Date: *April 14, 2014 at 1:07:36 PM PDT
 *To: *"openjfx-dev@openjdk.java.net
"
mailto:openjfx-dev@openjdk.java.net>>


Can someone confirm that all-permissions is working for
JavaFX apps
that are launched via Web Start with Java 8.0 and use
daemon threads
in a Service?

I have a JNLP file that has:

 


and the manifest of my app's jar has the following
instruction in my
Gradle script:

jar {
   manifest {
   attributes('Permissions': 'all-permissions',
  'Codebase': '*')
   }
}

I'm using the javafx gradle plugin and signing the jars...
e.g. I see this for every dependency and the main jar:
...
Signing (BLOB) C:\Users\scott\.m2\caches\path\to\some.jar
Signed as C:\Users\scott\dev\MyProject\build\libs\some.jar
...

I even tried System.setSecurityManager(null); in my
start() method
(and it lets me do it).

However, daemon threads started by my Service are unable
to use
reflection. (It is working in the main FX application
thread.)  I see
the following stack trace in the Java console:


Caused by: java.security.AccessControlException: access 
denied
("java.lang.reflect.ReflectPermission" 
"suppressAccessChecks")

at
java.security.AccessControlContext.checkPermission(Unknown
Source)
at java.security.AccessController.checkPermission(Unknown
Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at

sun.plugin2.applet.FXAppletSecurityManager.checkPermission(Unknown

Source)
at
java.lang.reflect.AccessibleObject.setAccessible(Unknown
Source)


Caused by: java.security.AccessControlException: access 
denied

("java.lang.RuntimePermission" "accessDeclaredMembers")
at
java.security.AccessControlContext.checkPermission(Unknown
Source)
at java.security.AccessController.checkPermission(Unknown
Source)
at java.lan

hg: openjfx/8u-dev/rt: RT-37447: Update javapackager / javafxpackager man pages for 8u20

[hang . vo]

Changeset: f41461e0a98c
Author:kcr
Date:  2014-06-13 16:20 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f41461e0a98c

RT-37447: Update javapackager / javafxpackager man pages for 8u20
Summary: English versions of 8u20 man pages; translated versions to follow

! modules/fxpackager/src/main/man/man1/javafxpackager.1
! modules/fxpackager/src/main/man/man1/javapackager.1

Reminder: committing changesets

[Kevin Rushforth]

As we near the end of the 8u20 release here are a few simple reminders 
of the rules for pushing changesets.


1) Generally all changesets should have a JIRA bug ID associated with 
them. Exceptions are documented on our Wiki [1].


2) The format of commit messages (also on the Wiki) is:

RT-n: bug title from JIRA
Summary: a description of what or how you fixed the problem  [optional]
Reviewed-by: list, of, reviewers [openjdk ID is preferred]
Contributed-by: Some One   [if applicable]

3) Avoid unrelated changes in the same changeset

Thanks.

-- Kevin

[1] https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code

hg: openjfx/8u-dev/rt: RT-37549: Ability to produce a DMG from an APP seems broken

[hang . vo]

Changeset: 843180e964d3
Author:shemnon
Date:  2014-06-13 15:51 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/843180e964d3

RT-37549: Ability to produce a DMG from an APP seems broken
Summary: Add tests to PKG and MAS bundlers.
Add size checks to verify file output bundlers have a sensible result (PKGs 
didn't at the time)
Have interim PKG packages use the APP_FS_NAME, which doges a bunch of URL 
issues.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppStoreBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacPkgBundler.java
! 
modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/MacBaseInstallerBundler.properties
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDmgBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacPkgBundlerTest.java

IMPORTANT: Commit rules for next week's rampdown to M5

[Kevin Rushforth]

TO: ALL JAVAFX DEVELOPERS

Next week is our ramp-down week for M5, which is the last milestone 
before we fork the 8u20 stabilization repo. As a reminder, the Milestone 
Week stabilization rules [1] are in effect for any changesets pushed 
after 1am on Monday, June 16. This means no post-commit reviews, and you 
need an extra "+1" from one of the leads listed on the Wiki (the usual 
exception applies for javadoc changes and changes that don't touch the 
shipping bits).


Given that this is the last milestone before 8u20 goes into its 
end-of-the-release stabilization we are likely to be a bit more strict 
than previous milestones about giving approval. Pretty much if it isn't 
a regression or a serious bug, it will likely need to wait for 8u40.


-- Steve & Kevin

[1] https://wiki.openjdk.java.net/display/OpenJFX/8u20

hg: openjfx/8u-dev/rt: RT-37549: Ability to produce a DMG from an APP seems broken

[hang . vo]

Changeset: d1b812ea87df
Author:shemnon
Date:  2014-06-13 13:45 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d1b812ea87df

RT-37549: Ability to produce a DMG from an APP seems broken
Summary: When refactoring the feature got broken
Also, took the opportunity to add some unit tests and improve the validation 
with this feature.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacBaseInstallerBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacDmgBundler.java
! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/Main.java
! 
modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/MacBaseInstallerBundler.properties
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDmgBundlerTest.java

hg: openjfx/8u-dev/rt: RT-36335: [Accessibility] Hide prototype API

[hang . vo]

Changeset: 12197c6e1aa7
Author:Felipe Heidrich 
Date:  2014-06-13 12:21 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/12197c6e1aa7

RT-36335: [Accessibility] Hide prototype API

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledSkinBase.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PaginationSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollBarSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SliderSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextAreaSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextFieldSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextInputControlSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ToolBarSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java
! modules/controls/src/main/java/javafx/scene/control/Button.java
! modules/controls/src/main/java/javafx/scene/control/ButtonBase.java
! modules/controls/src/main/java/javafx/scene/control/CheckBox.java
! modules/controls/src/main/java/javafx/scene/control/ChoiceBox.java
! modules/controls/src/main/java/javafx/scene/control/ComboBox.java
! modules/controls/src/main/java/javafx/scene/control/ComboBoxBase.java
! modules/controls/src/main/java/javafx/scene/control/Control.java
! modules/controls/src/main/java/javafx/scene/control/DatePicker.java
! modules/controls/src/main/java/javafx/scene/control/Hyperlink.java
! modules/controls/src/main/java/javafx/scene/control/Label.java
! modules/controls/src/main/java/javafx/scene/control/Labeled.java
! modules/controls/src/main/java/javafx/scene/control/ListCell.java
! modules/controls/src/main/java/javafx/scene/control/ListView.java
! modules/controls/src/main/java/javafx/scene/control/MenuBar.java
! modules/controls/src/main/java/javafx/scene/control/MenuButton.java
! modules/controls/src/main/java/javafx/scene/control/Pagination.java
! modules/controls/src/main/java/javafx/scene/control/PasswordField.java
! modules/controls/src/main/java/javafx/scene/control/ProgressBar.java
! modules/controls/src/main/java/javafx/scene/control/ProgressIndicator.java
! modules/controls/src/main/java/javafx/scene/control/RadioButton.java
! modules/controls/src/main/java/javafx/scene/control/ScrollBar.java
! modules/controls/src/main/java/javafx/scene/control/ScrollPane.java
! modules/controls/src/main/java/javafx/scene/control/SkinBase.java
! modules/controls/src/main/java/javafx/scene/control/Slider.java
! modules/controls/src/main/java/javafx/scene/control/SplitMenuButton.java
! modules/controls/src/main/java/javafx/scene/control/TabPane.java
! modules/controls/src/main/java/javafx/scene/control/TableCell.java
! modules/controls/src/main/java/javafx/scene/control/TableRow.java
! modules/controls/src/main/java/javafx/scene/control/TableView.java
! modules/controls/src/main/java/javafx/scene/control/TextArea.java
! modules/controls/src/main/java/javafx/scene/control/TextField.java
! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java
! modules/controls/src/main/java/javafx/scene/control/TitledPane.java
! modules/controls/src/main/java/javafx/scene/control/ToggleButton.java
! modules/controls/src/main/java/javafx/scene/control/ToolBar.java
! modules/controls/src/main/java/javafx/scene/control/Tooltip.java
! modules/controls/src/main/java/javafx/scene/control/TreeCell.java
! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java
! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java
! modules/controls/src/main/java/javafx/scene/con

Re: Large Image Export

[Kevin Rushforth]

The funny thing is I was sure I had typed 8u40, but my fingers had other 
ideas. :)


-- Kevin


Stephen F Northover wrote:

... a rare instance of Kevin getting a release name wrong!

Steve

On 2014-06-13, 11:39 AM, Kevin Rushforth wrote:

> could be moved into 8u20

I meant 8u40.

-- Kevin


Kevin Rushforth wrote:
This is RT-22073  
which is currently targeted for 9, but could be moved into 8u20 if 
there was enough demand to fix it. The (rather ugly) app-level 
workaround is to break the operation up into 4Kx4K tiles, and render 
the tiles in a loop specifying the appropriate viewport and 
translation via ShapshotParams.


-- Kevin



Danno Ferrin wrote:
While working on a fun project I discovered that the Image Export 
limits
the size of the export textures, mostly depending on your graphics 
stack.

 Here's one example:

java.lang.RuntimeException: Requested texture dimensions (20581x245)
require dimensions (0x245) that exceed maximum texture size (16384)
at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:106) 


at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:102) 


at
com.sun.javafx.tk.quantum.QuantumToolkit$QuantumImage.getRT(QuantumToolkit.java:1210) 

at 
com.sun.javafx.tk.quantum.QuantumToolkit$18.run(QuantumToolkit.java:1345) 

at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 


at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 


at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 


at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) 



This is on a mid-2012 Mac Book Air, and the MacGLConext looks to limit
dimensions to 2^14.

Is there anything I can do other than making sure my nodes don't 
get bigger
than 16K on one side?  I've tried setting a transform on the 
snapshot and
zooming it below 16k, but it still gets the same exception with he 
same

dimensions.

--Danno

review for https://javafx-jira.kenai.com/browse/RT-37552

[David Hill]

Daniel,
   would you review the change in RT-37552
Dave

jira: https://javafx-jira.kenai.com/browse/RT-37552
patch is in the Jira.

--
David Hill 
Java Embedded Development

Insanity in individuals is something rare - but in groups, parties, nations and 
epochs, it is the rule.
-- Friedrich Nietzsche

hg: openjfx/8u-dev/rt: 6 new changesets

[hang . vo]

Changeset: d7447fb53063
Author:ddhill
Date:  2014-06-13 13:57 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d7447fb53063

RT-37544 [Android] new versions of FX launcher classes on Dalvik
Contributed-by: johanvos

! modules/graphics/src/dalvik/java/javafxports/android/DalvikLauncher.java
! modules/graphics/src/dalvik/java/javafxports/android/FXActivity.java

Changeset: bb93c8561e3a
Author:ddhill
Date:  2014-06-13 13:57 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bb93c8561e3a

RT-37545 [Android] On dalvik, don't use android library
Contrbuted-by: johanvos

! modules/graphics/src/main/native-prism-es2/eglfb/wrapped_egl.c

Changeset: f766fc30b94a
Author:ddhill
Date:  2014-06-13 13:57 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f766fc30b94a

RT-37546 [Android] Dalvik font descriptors in wrong directory
Contrbuted-by: johanvos

- modules/graphics/src/main/java/com/sun/javafx/font/android_system_fonts.xml
+ 
modules/graphics/src/main/resources/com/sun/javafx/font/android_system_fonts.xml

Changeset: 31c211274ad5
Author:ddhill
Date:  2014-06-13 13:57 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/31c211274ad5

RT-37532 [Android] dalvik.gradle contains an hardcoded path to rt.jar
Contrbuted-by: johanvos

! buildSrc/dalvik.gradle

Changeset: 2cf52ba25887
Author:ddhill
Date:  2014-06-13 13:57 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2cf52ba25887

RT-37543 [Android] align sdk directory structure dalvik with other platforms
Contrbuted-by: johanvos

! buildSrc/dalvik.gradle

Changeset: dd4e8fc28238
Author:ddhill
Date:  2014-06-13 13:57 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dd4e8fc28238

RT-36811 [Android] Stackoverflow on JavaFX Application Thread
Contributed-by: snfuchs

! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java

hg: openjfx/8u-dev/rt: RT-37548: TabPaneSkin keeps reference to Tab after closing the last one

[hang . vo]

Changeset: 80be95eb45f1
Author:David Grieve
Date:  2014-06-13 13:18 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/80be95eb45f1

RT-37548: TabPaneSkin keeps reference to Tab after closing the last one

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java

Re: Large Image Export

[Stephen F Northover]

.. a rare instance of Kevin getting a release name wrong!

Steve

On 2014-06-13, 11:39 AM, Kevin Rushforth wrote:

> could be moved into 8u20

I meant 8u40.

-- Kevin


Kevin Rushforth wrote:
This is RT-22073  
which is currently targeted for 9, but could be moved into 8u20 if 
there was enough demand to fix it. The (rather ugly) app-level 
workaround is to break the operation up into 4Kx4K tiles, and render 
the tiles in a loop specifying the appropriate viewport and 
translation via ShapshotParams.


-- Kevin



Danno Ferrin wrote:
While working on a fun project I discovered that the Image Export 
limits
the size of the export textures, mostly depending on your graphics 
stack.

 Here's one example:

java.lang.RuntimeException: Requested texture dimensions (20581x245)
require dimensions (0x245) that exceed maximum texture size (16384)
at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:106) 


at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:102) 


at
com.sun.javafx.tk.quantum.QuantumToolkit$QuantumImage.getRT(QuantumToolkit.java:1210) 

at 
com.sun.javafx.tk.quantum.QuantumToolkit$18.run(QuantumToolkit.java:1345) 

at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 


at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 


at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) 



This is on a mid-2012 Mac Book Air, and the MacGLConext looks to limit
dimensions to 2^14.

Is there anything I can do other than making sure my nodes don't get 
bigger
than 16K on one side?  I've tried setting a transform on the 
snapshot and

zooming it below 16k, but it still gets the same exception with he same
dimensions.

--Danno

Re: Large Image Export

[Kevin Rushforth]

Yes, the limitation is in snapshot, although there are other places 
where we hit the same limit. When rendering an image via an InageView we 
do the tiling correctly.


I haven't seen anything lower than 4K x 4X in practice, so that should 
be safe. We do query and keep the max texture size internally in Prism 
(per-resource-factory), but don't expose it via a public API.


-- Kevin


Danno Ferrin wrote:
So the limitation is in the snapshot code, not the target image code? 
 This is actually a feasible workaround, so 8u40 would be grand but 9 
is also just fine.


Also, is 4K the lowest the texture size max will be?  Or is there some 
API to query it?



On Fri, Jun 13, 2014 at 9:38 AM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


This is RT-22073 
which is currently targeted for 9, but could be moved into 8u20 if
there was enough demand to fix it. The (rather ugly) app-level
workaround is to break the operation up into 4Kx4K tiles, and
render the tiles in a loop specifying the appropriate viewport and
translation via ShapshotParams.

-- Kevin




Danno Ferrin wrote:

While working on a fun project I discovered that the Image Export limits
the size of the export textures, mostly depending on your graphics stack.
 Here's one example:

java.lang.RuntimeException: Requested texture dimensions (20581x245)
require dimensions (0x245) that exceed maximum texture size (16384)
at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
at

com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:106)
at

com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:102)
at

com.sun.javafx.tk.quantum.QuantumToolkit$QuantumImage.getRT(QuantumToolkit.java:1210)
at com.sun.javafx.tk.quantum.QuantumToolkit$18.run(QuantumToolkit.java:1345)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at

com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129)

This is on a mid-2012 Mac Book Air, and the MacGLConext looks to limit
dimensions to 2^14.

Is there anything I can do other than making sure my nodes don't get bigger
than 16K on one side?  I've tried setting a transform on the snapshot and
zooming it below 16k, but it still gets the same exception with he same
dimensions.

--Danno
  

hg: openjfx/8u-dev/rt: 2 new changesets

[hang . vo]

Changeset: 65903865cab7
Author:kcr
Date:  2014-06-13 08:41 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/65903865cab7

RT-37539: [Builders] Web builder classes not built unless COMPILE_WEBKIT=true
Reviewed-by: ddhill

! build.gradle

Changeset: a88b5721a3be
Author:ddhill
Date:  2014-06-13 11:20 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a88b5721a3be

RT-36375 finishing Monocle Robot screen capture (with changes this time)
Reviewed-by: dblaukopf

! modules/graphics/src/main/java/com/sun/glass/ui/monocle/AcceleratedScreen.java
! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleRobot.java
! modules/graphics/src/main/java/com/sun/glass/ui/monocle/NativeScreen.java
! 
modules/graphics/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java
! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/FBDevScreen.java
! 
modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxFrameBuffer.java
! modules/graphics/src/main/java/com/sun/glass/ui/monocle/x11/X11Screen.java

Re: Large Image Export

[Danno Ferrin]

So the limitation is in the snapshot code, not the target image code?  This
is actually a feasible workaround, so 8u40 would be grand but 9 is also
just fine.

Also, is 4K the lowest the texture size max will be?  Or is there some API
to query it?


On Fri, Jun 13, 2014 at 9:38 AM, Kevin Rushforth  wrote:

>  This is RT-22073  which
> is currently targeted for 9, but could be moved into 8u20 if there was
> enough demand to fix it. The (rather ugly) app-level workaround is to break
> the operation up into 4Kx4K tiles, and render the tiles in a loop
> specifying the appropriate viewport and translation via ShapshotParams.
>
> -- Kevin
>
>
>
>
> Danno Ferrin wrote:
>
> While working on a fun project I discovered that the Image Export limits
> the size of the export textures, mostly depending on your graphics stack.
>  Here's one example:
>
> java.lang.RuntimeException: Requested texture dimensions (20581x245)
> require dimensions (0x245) that exceed maximum texture size (16384)
> at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
> at
> com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:106)
> at
> com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:102)
> at
> com.sun.javafx.tk.quantum.QuantumToolkit$QuantumImage.getRT(QuantumToolkit.java:1210)
> at com.sun.javafx.tk.quantum.QuantumToolkit$18.run(QuantumToolkit.java:1345)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129)
>
> This is on a mid-2012 Mac Book Air, and the MacGLConext looks to limit
> dimensions to 2^14.
>
> Is there anything I can do other than making sure my nodes don't get bigger
> than 16K on one side?  I've tried setting a transform on the snapshot and
> zooming it below 16k, but it still gets the same exception with he same
> dimensions.
>
> --Danno
>
>
>

Re: Large Image Export

[Kevin Rushforth]

This is RT-22073  which 
is currently targeted for 9, but could be moved into 8u20 if there was 
enough demand to fix it. The (rather ugly) app-level workaround is to 
break the operation up into 4Kx4K tiles, and render the tiles in a loop 
specifying the appropriate viewport and translation via ShapshotParams.


-- Kevin



Danno Ferrin wrote:

While working on a fun project I discovered that the Image Export limits
the size of the export textures, mostly depending on your graphics stack.
 Here's one example:

java.lang.RuntimeException: Requested texture dimensions (20581x245)
require dimensions (0x245) that exceed maximum texture size (16384)
at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:106)
at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:102)
at
com.sun.javafx.tk.quantum.QuantumToolkit$QuantumImage.getRT(QuantumToolkit.java:1210)
at com.sun.javafx.tk.quantum.QuantumToolkit$18.run(QuantumToolkit.java:1345)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129)

This is on a mid-2012 Mac Book Air, and the MacGLConext looks to limit
dimensions to 2^14.

Is there anything I can do other than making sure my nodes don't get bigger
than 16K on one side?  I've tried setting a transform on the snapshot and
zooming it below 16k, but it still gets the same exception with he same
dimensions.

--Danno
  

Re: Large Image Export

[Kevin Rushforth]

> could be moved into 8u20

I meant 8u40.

-- Kevin


Kevin Rushforth wrote:
This is RT-22073  which 
is currently targeted for 9, but could be moved into 8u20 if there was 
enough demand to fix it. The (rather ugly) app-level workaround is to 
break the operation up into 4Kx4K tiles, and render the tiles in a 
loop specifying the appropriate viewport and translation via 
ShapshotParams.


-- Kevin



Danno Ferrin wrote:

While working on a fun project I discovered that the Image Export limits
the size of the export textures, mostly depending on your graphics 
stack.

 Here's one example:

java.lang.RuntimeException: Requested texture dimensions (20581x245)
require dimensions (0x245) that exceed maximum texture size (16384)
at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:106) 


at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:102) 


at
com.sun.javafx.tk.quantum.QuantumToolkit$QuantumImage.getRT(QuantumToolkit.java:1210) 

at 
com.sun.javafx.tk.quantum.QuantumToolkit$18.run(QuantumToolkit.java:1345) 

at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 


at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 


at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) 



This is on a mid-2012 Mac Book Air, and the MacGLConext looks to limit
dimensions to 2^14.

Is there anything I can do other than making sure my nodes don't get 
bigger
than 16K on one side?  I've tried setting a transform on the snapshot 
and

zooming it below 16k, but it still gets the same exception with he same
dimensions.

--Danno
  

hg: openjfx/8u-dev/rt: 2 new changesets

[hang . vo]

Changeset: d80d00bde528
Author:ddhill
Date:  2014-06-13 10:56 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d80d00bde528

RT-36375 finishing Monocle Robot screen capture.
Reviewed-by: dblaukopf


Changeset: 6a7d974b09bd
Author:snorthov
Date:  2014-06-13 10:57 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6a7d974b09bd

[REMOVE UNUSED IMPORT] Causes compile error on Android / iOS

! modules/fxml/src/main/java/javafx/fxml/JavaFXBuilderFactory.java

Re: Is JavaFX keyboard event handling too rigid?

[Stephen F Northover]

You should be able to use event filtering to get in the way of any event 
before it is delivered to the control.  If you provide some sample code 
for what you are trying to do, we can take a look at it and suggest a 
possible solution.


Steve

On 2014-06-13, 10:39 AM, Tomas Mikula wrote:

Hi Randahl,

I think the general advice is to avoid subclassing controls if
possible. You can create your custom control that embeds a text field
and filter events on your custom control so they never reach the
embedded text field.

Tomas

On Fri, Jun 13, 2014 at 10:11 AM, Randahl Fink Isaksen
 wrote:

I have noticed that quite many developers are having trouble avoiding 
triggering of focus navigation occurring when a user presses the UP and DOWN 
arrow keys. From a number of different forum posts I have seen how people are 
jumping through hoops to avoid this.

I myself have the challenge, that I need to use the UP and DOWN keys for 
changing the selected autocompletion in a text field, and it seems that no 
matter how greedily I try to consume or filter out these KeyEvents, JavaFX 
still insists on moving the focus from one field to the next.

This got me thinking: Why is JavaFX keyboard event handling so rigid? If you 
implement a control which listens for keyboard events on itself and does some 
cool stuff, that is fine. But once you implement a subclass that wishes to 
replace some of that behaviour you are in trouble, because once the 
EventHandlers are registered, there is no public API to replace them.

Is this a conscious design decision? Is it something that I should file a 
feature request on, or have I overlooked a part of the API which could be used 
here?

Randahl

Large Image Export

[Danno Ferrin]

While working on a fun project I discovered that the Image Export limits
the size of the export textures, mostly depending on your graphics stack.
 Here's one example:

java.lang.RuntimeException: Requested texture dimensions (20581x245)
require dimensions (0x245) that exceed maximum texture size (16384)
at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:106)
at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:102)
at
com.sun.javafx.tk.quantum.QuantumToolkit$QuantumImage.getRT(QuantumToolkit.java:1210)
at com.sun.javafx.tk.quantum.QuantumToolkit$18.run(QuantumToolkit.java:1345)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129)

This is on a mid-2012 Mac Book Air, and the MacGLConext looks to limit
dimensions to 2^14.

Is there anything I can do other than making sure my nodes don't get bigger
than 16K on one side?  I've tried setting a transform on the snapshot and
zooming it below 16k, but it still gets the same exception with he same
dimensions.

--Danno

Re: Is JavaFX keyboard event handling too rigid?

[Tomas Mikula]

Hi Randahl,

I think the general advice is to avoid subclassing controls if
possible. You can create your custom control that embeds a text field
and filter events on your custom control so they never reach the
embedded text field.

Tomas

On Fri, Jun 13, 2014 at 10:11 AM, Randahl Fink Isaksen
 wrote:
> I have noticed that quite many developers are having trouble avoiding 
> triggering of focus navigation occurring when a user presses the UP and DOWN 
> arrow keys. From a number of different forum posts I have seen how people are 
> jumping through hoops to avoid this.
>
> I myself have the challenge, that I need to use the UP and DOWN keys for 
> changing the selected autocompletion in a text field, and it seems that no 
> matter how greedily I try to consume or filter out these KeyEvents, JavaFX 
> still insists on moving the focus from one field to the next.
>
> This got me thinking: Why is JavaFX keyboard event handling so rigid? If you 
> implement a control which listens for keyboard events on itself and does some 
> cool stuff, that is fine. But once you implement a subclass that wishes to 
> replace some of that behaviour you are in trouble, because once the 
> EventHandlers are registered, there is no public API to replace them.
>
> Is this a conscious design decision? Is it something that I should file a 
> feature request on, or have I overlooked a part of the API which could be 
> used here?
>
> Randahl
>

hg: openjfx/8u-dev/rt: 2 new changesets

[hang . vo]

Changeset: 2f73643b0a99
Author:David Grieve
Date:  2014-06-13 09:33 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2f73643b0a99

RT-37540: [PopupControl] PopupControl.CSSBridge.setSkinClassNameMethod deleted

! modules/controls/src/main/java/javafx/scene/control/PopupControl.java

Changeset: 89b559a30294
Author:David Grieve
Date:  2014-06-13 09:33 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/89b559a30294

RT-37451: [PopupControl] PopupControl.CSSBridge.getStyleableParent method 
changed to final

! modules/controls/src/main/java/javafx/scene/control/PopupControl.java

hg: openjfx/8u-dev/rt: Fixed build path in Eclipse metadata for the AirportApp sample of SceneBuilder

[hang . vo]

Changeset: fab4ceaa5c67
Author:yjoan
Date:  2014-06-13 15:03 +0200
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/fab4ceaa5c67

Fixed build path in Eclipse metadata for the AirportApp sample of SceneBuilder

! apps/scenebuilder/samples/AirportApp/.classpath

Re: Exposing native surface or opengl handle

[Hervé Girod]

I really think that pure JavaFX will always be better if you can, but in some 
cases you "have" to use external libraries using OpenGL, because you don't have 
the Java replacement, or it would be a LOT of work to recreate it.

Hervé

Sent from my iPhone

> On Jun 13, 2014, at 14:08, Tobias Bley  wrote:
> 
> Hi Robert,
> 
> thank you for pushing this topic again :)
> 
> For our work we need a way to share the OpenGL context between JavaFX code 
> and native code so that we can render stuff from native code into the JavaFX 
> context.
> 
> Another question and need is to how to share a context in JavaFX? How is it 
> possible to render the same JavaFX node in OpenGL / graphics device twice? 
> Imagine to show a webcam image on two different positions within a JavaFX 
> app. With pure native OpenGL you could do this via "Context Sharing". But how 
> to do it in JavaFX?
> 
> Best regards,
> Tobi
> 
> 
> Am 13.06.14 08:57, schrieb Robert Krüger:
>> Hi,
>> 
>> it has been discussed a number of time in the passed but let me
>> quickly summarize:
>> 
>> A number of people have requested a feature that provides the ability
>> to have native code draw into a surface provided by a JavaFX
>> application as fast as technically possible, i.e. with no indirection
>> or copying because use cases for this were mostly cases where
>> performance was critical, e.g. HD/UHD video players, real-time
>> visualization etc. where losing even e few percent would make a
>> software written in JavaFX unable to compete with native products
>> (e.g. in the video area nobody will use a video player that is not
>> able to play the content smoothly that VLC player or Quicktime can on
>> the same machine). Some people already have libraries of native code
>> that they have built over the years and would like to reuse. I would
>> even go so far to say that our product will probably never be able to
>> move to JFX (apart from mixing it a bit with Swing, which we currently
>> see rather aa a migration strategy and not as the end result) without
>> this problem solved.
>> 
>> In the past the reactions/signals from the Oracle team in this respect
>> were mixed but some of it indicated that this topic was discussed in
>> the past and might be revisited after the release of JFX 8. Now that
>> the latter has happened I would like to ask what the plans for this
>> are.
>> 
>> Is there a Jira Issue where we can track the progress of it?
>> 
>> If not, does it make sense if I open one, so people (probably the same
>> ones that have participated in these discussions in the past like
>> Scott and the Ultramixer guys etc.) can collect their
>> requirements/thoughts?
>> 
>> Even if Oracle should decide not to do something about it, it would
>> still be nice to get pointers in the code base to where this would be
>> possible, even if it is non-portable. I know that for our product it
>> would be totally OK to have different ways of doing this for each
>> platform and to live with the limitation to not be able to manipulate
>> the result in the FX scene graph apart from that the position of the
>> surface moving with the hosting FX node and as far as I have
>> understood others, it is the same for them.
>> 
>> Maybe a Jira issue could also be a good place to bundle information
>> about approaches interested parties are willing to pursue.
>> 
>> Thoughts anyone?
>> 
>> Robert
> 

Re: Exposing native surface or opengl handle

[Tobias Bley]

Hi Robert,

thank you for pushing this topic again :)

For our work we need a way to share the OpenGL context between JavaFX 
code and native code so that we can render stuff from native code into 
the JavaFX context.


Another question and need is to how to share a context in JavaFX? How is 
it possible to render the same JavaFX node in OpenGL / graphics device 
twice? Imagine to show a webcam image on two different positions within 
a JavaFX app. With pure native OpenGL you could do this via "Context 
Sharing". But how to do it in JavaFX?


Best regards,
Tobi


Am 13.06.14 08:57, schrieb Robert Krüger:

Hi,

it has been discussed a number of time in the passed but let me
quickly summarize:

A number of people have requested a feature that provides the ability
to have native code draw into a surface provided by a JavaFX
application as fast as technically possible, i.e. with no indirection
or copying because use cases for this were mostly cases where
performance was critical, e.g. HD/UHD video players, real-time
visualization etc. where losing even e few percent would make a
software written in JavaFX unable to compete with native products
(e.g. in the video area nobody will use a video player that is not
able to play the content smoothly that VLC player or Quicktime can on
the same machine). Some people already have libraries of native code
that they have built over the years and would like to reuse. I would
even go so far to say that our product will probably never be able to
move to JFX (apart from mixing it a bit with Swing, which we currently
see rather aa a migration strategy and not as the end result) without
this problem solved.

In the past the reactions/signals from the Oracle team in this respect
were mixed but some of it indicated that this topic was discussed in
the past and might be revisited after the release of JFX 8. Now that
the latter has happened I would like to ask what the plans for this
are.

Is there a Jira Issue where we can track the progress of it?

If not, does it make sense if I open one, so people (probably the same
ones that have participated in these discussions in the past like
Scott and the Ultramixer guys etc.) can collect their
requirements/thoughts?

Even if Oracle should decide not to do something about it, it would
still be nice to get pointers in the code base to where this would be
possible, even if it is non-portable. I know that for our product it
would be totally OK to have different ways of doing this for each
platform and to live with the limitation to not be able to manipulate
the result in the FX scene graph apart from that the position of the
surface moving with the hosting FX node and as far as I have
understood others, it is the same for them.

Maybe a Jira issue could also be a good place to bundle information
about approaches interested parties are willing to pursue.

Thoughts anyone?

Robert

Re: Exposing native surface or opengl handle

[Scott Palmer]

This is critical, but I don't think we need to focus on a specific technology 
like Direct3D or OpenGL. As a first step all we need is a mechanism to get a 
native reference to the Window. Just like we can with JAWT.  I'm guessing that 
JavaFX doesn't use heavyweight child windows so we could add a new child window 
that we manage with our own code and it would appear on top of the JavaFX 
content.

Scott

> On Jun 13, 2014, at 3:08 AM, Felix Bembrick  wrote:
> 
> I absolutely agree that such a feature is critical for the success and
> longevity of JavaFX.  I am *really* hoping for some heavily beefed-up 3D
> support in a JFX 8.* release or JFX 9.
> 
> I need my graphics toolkit (currently JavaFX) to be able to handle
> everything from simple UIs with basic controls to complex 3D
> visualisations, just like the underlying graphics API is capable of (i.e.
> OpenGL or Direct3D).  I strongly suspect though that focusing on OpenGL
> exclusively is the only viable way to go from a cost perspective which
> would mean JavaFX supporting OpenGL on Windows.
> 
> 
>> On 13 June 2014 16:57, Robert Krüger  wrote:
>> 
>> Hi,
>> 
>> it has been discussed a number of time in the passed but let me
>> quickly summarize:
>> 
>> A number of people have requested a feature that provides the ability
>> to have native code draw into a surface provided by a JavaFX
>> application as fast as technically possible, i.e. with no indirection
>> or copying because use cases for this were mostly cases where
>> performance was critical, e.g. HD/UHD video players, real-time
>> visualization etc. where losing even e few percent would make a
>> software written in JavaFX unable to compete with native products
>> (e.g. in the video area nobody will use a video player that is not
>> able to play the content smoothly that VLC player or Quicktime can on
>> the same machine). Some people already have libraries of native code
>> that they have built over the years and would like to reuse. I would
>> even go so far to say that our product will probably never be able to
>> move to JFX (apart from mixing it a bit with Swing, which we currently
>> see rather aa a migration strategy and not as the end result) without
>> this problem solved.
>> 
>> In the past the reactions/signals from the Oracle team in this respect
>> were mixed but some of it indicated that this topic was discussed in
>> the past and might be revisited after the release of JFX 8. Now that
>> the latter has happened I would like to ask what the plans for this
>> are.
>> 
>> Is there a Jira Issue where we can track the progress of it?
>> 
>> If not, does it make sense if I open one, so people (probably the same
>> ones that have participated in these discussions in the past like
>> Scott and the Ultramixer guys etc.) can collect their
>> requirements/thoughts?
>> 
>> Even if Oracle should decide not to do something about it, it would
>> still be nice to get pointers in the code base to where this would be
>> possible, even if it is non-portable. I know that for our product it
>> would be totally OK to have different ways of doing this for each
>> platform and to live with the limitation to not be able to manipulate
>> the result in the FX scene graph apart from that the position of the
>> surface moving with the hosting FX node and as far as I have
>> understood others, it is the same for them.
>> 
>> Maybe a Jira issue could also be a good place to bundle information
>> about approaches interested parties are willing to pursue.
>> 
>> Thoughts anyone?
>> 
>> Robert
>> 

hg: openjfx/8u-dev/rt: RT-37507 [Android, FXML] JavaFXBuilderFactory contains a call to Constructor.getParameters

[hang . vo]

Changeset: ee80f24584b4
Author:Martin Sladecek 
Date:  2014-06-13 12:17 +0200
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ee80f24584b4

RT-37507 [Android, FXML] JavaFXBuilderFactory contains a call to 
Constructor.getParameters

! modules/fxml/src/main/java/javafx/fxml/JavaFXBuilderFactory.java

hg: openjfx/8u-dev/rt: 2 new changesets

[hang . vo]

Changeset: 28bccddb2475
Author:Martin Sladecek 
Date:  2014-06-13 12:00 +0200
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/28bccddb2475

RT-37523 BooleanProperty.booleanProperty(ObjectProperty) changes value 
of source property

! modules/base/src/main/java/com/sun/javafx/binding/BidirectionalBinding.java
! modules/base/src/main/java/javafx/beans/property/BooleanProperty.java
! modules/base/src/main/java/javafx/beans/property/DoubleProperty.java
! modules/base/src/main/java/javafx/beans/property/FloatProperty.java
! modules/base/src/main/java/javafx/beans/property/IntegerProperty.java
! modules/base/src/main/java/javafx/beans/property/LongProperty.java
! modules/base/src/test/java/javafx/beans/property/BooleanPropertyTest.java
! modules/base/src/test/java/javafx/beans/property/DoublePropertyTest.java
! modules/base/src/test/java/javafx/beans/property/FloatPropertyTest.java
! modules/base/src/test/java/javafx/beans/property/IntegerPropertyTest.java
! modules/base/src/test/java/javafx/beans/property/LongPropertyTest.java

Changeset: 0be1e326561e
Author:Martin Sladecek 
Date:  2014-06-13 12:05 +0200
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0be1e326561e

RT-37506 [Android, FXML] FXMLLoader uses new Method.getParameterCount() method

! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java

Re: Blurry strokes and zooming via scale transforms

[Robert Fisher]

Thanks for the links, I'll take a look.

Rob

-Ursprüngliche Nachricht-
Von: John Smith [mailto:john_sm...@symantec.com] 
Gesendet: Donnerstag, 12. Juni 2014 22:05
An: Robert Fisher; openjfx-dev@openjdk.java.net
Betreff: RE: Blurry strokes and zooming via scale transforms

A couple of related stackoverflow questions won't solve your problem, but will 
provide some background info:
  
http://stackoverflow.com/questions/16089304/javafx-imageview-without-any-smoothing
  
http://stackoverflow.com/questions/11886230/how-to-draw-a-crisp-opaque-hairline-in-javafx-2-2
  
http://stackoverflow.com/questions/11881834/what-are-a-lines-exact-dimensions-in-javafx-2

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Robert Fisher
Sent: Thursday, June 12, 2014 3:10 AM
To: openjfx-dev@openjdk.java.net
Subject: AW: Blurry strokes and zooming via scale transforms

Well suppose I have a Rectangle with a size of 100x100 and stroke-width of 1, 
and I apply a scale transform to zoom in to 150%.

Then I would like to see a size of 150x150 pixels and still see a sharp border 
stroke, let's say with a width of 2 pixels.

I'm not sure how I could apply a snapping transformation to just correct stroke 
widths and not disturb the size of the shapes themselves.

Cheers,
Rob

-Ursprüngliche Nachricht-
Von: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] Im Auftrag von 
Tom Eugelink
Gesendet: Donnerstag, 12. Juni 2014 11:42
An: openjfx-dev@openjdk.java.net
Betreff: Re: Blurry strokes and zooming via scale transforms


I recently had a similar situation, but then because certain properties were 
calculated-via-binding and the resulting value was not "snapped" to good values 
either.

This resulted in my suggestion to allow custom calculations in bindings, which 
would then snap the value.
https://javafx-jira.kenai.com/browse/RT-37255

And transformations on such values have the same effect of course. I was 
wondering, similar to the binding suggestion, would it be possible to apply a 
snapping transformation as the last transformation?

Tom


On 2014-6-12 10:56, Robert Fisher wrote:
> Hi all,
>   
> I'm trying to avoid the blurry strokes you can get in JavaFX in some cases, 
> e.g. for a non-integer stroke width, or a stroke width of 1 and 
> StrokeType.CENTERED.
>   
> So far my 'solution' to this problem has been to round layout values to 
> integers, or to round and add 0.5 in the StrokeType.CENTERED case.
>   
> However this approach is pretty useless if I apply a scale transform 
> afterwards, which is the simplest way I know to create a zooming mechanism.
>   
> So my question is: is there any way I can round things to integer values 
> *after* transforms have been applied? Or tell the renderer to not try to 
> approximate strokes drawn 'off-pixel' but instead to round & move them to the 
> nearest pixel so that lines look sharp and clean?
>   
> Any tips would be appreciated.
>   
> Cheers,
> Rob

Is JavaFX keyboard event handling too rigid?

[Randahl Fink Isaksen]

I have noticed that quite many developers are having trouble avoiding 
triggering of focus navigation occurring when a user presses the UP and DOWN 
arrow keys. From a number of different forum posts I have seen how people are 
jumping through hoops to avoid this.

I myself have the challenge, that I need to use the UP and DOWN keys for 
changing the selected autocompletion in a text field, and it seems that no 
matter how greedily I try to consume or filter out these KeyEvents, JavaFX 
still insists on moving the focus from one field to the next.

This got me thinking: Why is JavaFX keyboard event handling so rigid? If you 
implement a control which listens for keyboard events on itself and does some 
cool stuff, that is fine. But once you implement a subclass that wishes to 
replace some of that behaviour you are in trouble, because once the 
EventHandlers are registered, there is no public API to replace them.

Is this a conscious design decision? Is it something that I should file a 
feature request on, or have I overlooked a part of the API which could be used 
here?

Randahl

Re: Bundler question for Mac OS X...

[Tony Anecito]

Hi Danno,
 
I downloaded 8u20 and it looks like the sub-menu items are using the launcher 
file name.
 
Also, the info.plist created by the deploy task is wrong. It does not use the 
correct jar for JVMMainjarName so the app does not start untill I changed it to 
the correct name. Is this new? 
 
I see the other fixes are in there we talked about.
 
Regards,
-Tony 


On Friday, June 13, 2014 12:41 AM, Tony Anecito  wrote:
  


Hi Danno,

I tried 1.8.0_05 and same issue with sub-menu items.

Let me know location for 1.8.0_20 and I will try that also.

Thanks,
-Tony  


On Thursday, June 12, 2014 11:54 PM, Tony Anecito  wrote:
  


Hi Danno,
I am using 1.8.0.0 and it does not work. Only the main menu item changes with 
the name. I will download prod 8u5 and try this. Where can I download the pkg 
for 8U20?

Thanks,
-Tony  


On Wednesday, June 11, 2014 9:48 AM, Tony Anecito  wrote:
  


Thanks Danno I will try tonight with your suggestion. I will let you know the 
results.

This is the last thing holding up approval of my app for the store.

Best Regards,
-Tony  


On Wednesday, June 11, 2014 8:22 AM, Danno Ferrin  
wrote:
  


It does change the sub-menu items (Hide /Quit ), at least the 8u20 
toolchain does.  I would expect the 8u5 toolchain to change it too because it 
looks the same, but I haven’t worked on those builds recently.



On Jun 11, 2014, at 8:05 AM, Tony Anecito  wrote:

I will try your suggestion to see if the sub-menu items name changes with what 
you sugggested.
>
>Thanks,
>-Tony  
>
>
>
>On , Tony Anecito  wrote:
>  
>
>
> Hi,
>
>The name attribute affects the main menu item but not the sub-menu items. Not 
>sure if you understood what I meant by sub-menu items. It would be better if 
>the sub-menu items did not use the starting/launcher class name. I even found 
>examples googleing where java main.startupclassname was shown for sub-menu 
>items.
>
>Apple iTunes store will reject java apps becuase of this issue. They want the 
>app name to match everywhere on the app including the sub-menu item names.
>
>Thanks,
>-Tony 
>
>
>
>On Wednesday, June 11, 2014 7:50 AM, Danno Ferrin  
>wrote:
>  
>
>
>This will be upgraded in the 8u20 release.
>
>For pre8u20 in the ant script the menu bar name is the name attribute from the 
>application element.
>
>
>  
>  
>  
>
>
>(This will still work in 8u20, if it doesn’t it is a bug to me I will fix).
>
>The
 down side is that some of those value have double use
 when using multiple platforms.  For example the id attribute is also the UUID 
for MSI bundles.  The name is also the name of the launcher file too, and pre 
8u20 they are tied together (unless you do a drop in resource to manually fix 
the identifier).
>
>Starting with 8u20 you can specify bundle params, and I have done my best to 
>eliminate the overlapping values, or at least allow you to set specific values 
>that will fall back to overlapping values.
>
>
>  
>  value=“com.example.your.mac.App”/>
>  
>  
>
>
>Since the windows bundlers don’t understand
 those arguments they will ignore them.  And the bundle name can be different 
from the launcher name now as well.
>
>
>On Jun 11, 2014, at 4:16 AM, Anthony Petrov  wrote:
>
>> Hi Tony,
>> 
>> I don't know the exact syntax for the FX deploy script (is it the -title or 
>> -name option for the javafxpackager [1] ?), however [2] suggests that the 
>> CFBundleName key in Info.plist can be used to set the application name. I 
>> can confirm that Glass reads the value and assigns it to the application 
>> name. The Quit menu item then uses this name for its text label.
>> 
>> Does setting the CFBundleName
 work for you?
>> 
>> [1] http://docs.oracle.com/javafx/2/deployment/javafxpackager.htm
>> 
>> [2] https://javafx-jira.kenai.com/browse/RT-18563
>> 
>> --
>> best regards,
>> Anthony
>> 
>> On 6/11/2014 7:54 AM, Tony Anecito wrote:
>>> Hi All,
>>> 
>>> I noticed the menu bar for OS X is probably using my class name that has 
>>> the static main in it. How do I override that in the JavFX Deploy ant 
>>> script? The About, Hide and Quit sub-menu items are using a different name 
>>> than what I want. The main menu item is correct.
>>> 
>>> Thanks!
>>> Tony
>>> 
>
>
>
>
>

Re: Exposing native surface or opengl handle

[Felix Bembrick]

I absolutely agree that such a feature is critical for the success and
longevity of JavaFX.  I am *really* hoping for some heavily beefed-up 3D
support in a JFX 8.* release or JFX 9.

I need my graphics toolkit (currently JavaFX) to be able to handle
everything from simple UIs with basic controls to complex 3D
visualisations, just like the underlying graphics API is capable of (i.e.
OpenGL or Direct3D).  I strongly suspect though that focusing on OpenGL
exclusively is the only viable way to go from a cost perspective which
would mean JavaFX supporting OpenGL on Windows.


On 13 June 2014 16:57, Robert Krüger  wrote:

> Hi,
>
> it has been discussed a number of time in the passed but let me
> quickly summarize:
>
> A number of people have requested a feature that provides the ability
> to have native code draw into a surface provided by a JavaFX
> application as fast as technically possible, i.e. with no indirection
> or copying because use cases for this were mostly cases where
> performance was critical, e.g. HD/UHD video players, real-time
> visualization etc. where losing even e few percent would make a
> software written in JavaFX unable to compete with native products
> (e.g. in the video area nobody will use a video player that is not
> able to play the content smoothly that VLC player or Quicktime can on
> the same machine). Some people already have libraries of native code
> that they have built over the years and would like to reuse. I would
> even go so far to say that our product will probably never be able to
> move to JFX (apart from mixing it a bit with Swing, which we currently
> see rather aa a migration strategy and not as the end result) without
> this problem solved.
>
> In the past the reactions/signals from the Oracle team in this respect
> were mixed but some of it indicated that this topic was discussed in
> the past and might be revisited after the release of JFX 8. Now that
> the latter has happened I would like to ask what the plans for this
> are.
>
> Is there a Jira Issue where we can track the progress of it?
>
> If not, does it make sense if I open one, so people (probably the same
> ones that have participated in these discussions in the past like
> Scott and the Ultramixer guys etc.) can collect their
> requirements/thoughts?
>
> Even if Oracle should decide not to do something about it, it would
> still be nice to get pointers in the code base to where this would be
> possible, even if it is non-portable. I know that for our product it
> would be totally OK to have different ways of doing this for each
> platform and to live with the limitation to not be able to manipulate
> the result in the FX scene graph apart from that the position of the
> surface moving with the hosting FX node and as far as I have
> understood others, it is the same for them.
>
> Maybe a Jira issue could also be a good place to bundle information
> about approaches interested parties are willing to pursue.
>
> Thoughts anyone?
>
> Robert
>