Re: JEP 286: Local-Variable Type Inference: Usage

[Artem Ananiev]

On 2018/03/29 9:36, Kevin Rushforth wrote:

As a prerequisite, we would need to update the minimum boot JDK to JDK
10, which I was going to propose doing anyway -- it seems the right time
now that JDK 10 is out.

I have no objections to then allowing the use of 'var' in new code.

Do any others have any concerns?


My personal experience with "var"s - they are used a lot in Scala, for 
example - is they make code very unreadable, especially when working 
with collections and streams. The only case when a "var" is suitable is 
new object creation:


var object = new SomeType()

In all other cases they are more painful than valuable.

I can say it differently. It's very easy to use "var"s wrong. No matter 
what style guides are available, people will often use them in a way 
that makes code less readable.


Just my $0.02

Thanks,

Artem


-- Kevin


Nir Lisker wrote:

Hello,

A style guide for usage of 'var' has been published at
http://openjdk.java.net/projects/amber/LVTIstyle.html. Can we start using
this feature in contributions to OpenJFX?

- Nir

Re: CFV: New OpenJFX Committer: Victor Drozdov

[Artem Ananiev]

Vote: yes

Artem

On 12/13/16, 4:21 PM, Chris Bensen wrote:

I hereby nominate Victor Drozdov [1] to OpenJFX Committer.

Victor is a member of Java Deployment team at Oracle working on the Java 
Packager tool, who has contributed 11 changesets [5] to OpenJFX, at least 8 of 
which are significant.

Votes are due by January 4, 2017.

Only current OpenJFX Committers [2] are eligible to vote on this nomination. 
Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3]. Nomination to a project 
Committer is described in [4].

Thanks,

[1] 
http://openjdk.java.net/census#vdrozdov

[2] 
http://openjdk.java.net/census#openjfx

[3] 
http://openjdk.java.net/bylaws#lazy-consensus

[4] 
http://openjdk.java.net/projects#project-committer

[5] List of changesets:

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/81268b9c41f6
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/4272317a42ad
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/3ca13b05a699
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/6dfb3daf92cf
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/2b649093eb50
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/2538169ab7bb
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a6fafaa51082
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ac334db87ed6
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/12e6cb1e78af
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/32cc74546935
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/6b55a303625d

Re: Necessity of com.sun.javafx.embed.AbstractEvents

[Artem Ananiev]

Hi, Alexander,

I believe I introduced that extra abstraction layer for FX/Swing events 
long time ago. At that time, we thought we might eventually want to 
embed different components than just JavaFX, but it doesn't make any 
sense these days. JFXPanel and FXCanvas contain a lot of FX specific 
code, they can't be used to embed anything than FX. I agree that 
AbstractEvents is redundant and can be replaced by FX events.


BTW, SwingNode (which is opposite to JFXPanel, it's to embed Swing into 
FX) doesn't use AbstractEvents, but operates directly with FX events.


Thanks,

Artem

On 9/16/16, 2:03 AM, Alexander Nyssen wrote:

Hi Alexander Z., Kevin,

while working on JDK-8143596 (FXCanvas does not forward touch
gestures to embedded scene) I came across some „smell“ that I would
like to discuss. That is, the information about events that is
exchanged between JFXPanel/FXCanvas and the
EmbeddedScene/EmbeddedStage is currently encoded via constants of
com.sun.javafx.embed.AbstractEvents. That is, FXCanvas and JFXPanel
map SWT and AWT event information to constants in AbstractEvents,
which are finally mapped to a JavaFX representations within
EmbeddedScene.

Without knowing the motivation behind this indirection, and without
having tried it in detail yet, for me it seems as if AbstractEvents
was superfluous and JavaFX representations could directly be used to
transfer this information instead. In case of
EmbeddedSceneInterface#inputMethodEvent() for instance,
AbstractEvents was already bypassed, as here EventType is used as a
parameter (instead of an AbstractEvents constant). Also, the modifier
constants defined within AbstractEvents are only used in case of key
events, while for mouse (and now gesture events) boolean parameters
are used to transport this information (which could also be done in
case of key events).

What do you think? In case you share my assessment I would propose to
file a separate issue for this, and I could offer to investigate it
after JDK-8143596 has been resolved (I would not want to mingle it).

Best Regards,



Alexander

Re: Subject: New OpenJFX Project Lead: Kevin Rushforth

[Artem Ananiev]

Vote: yes

Artem

On 6/23/16 8:01 PM, Alexandr Scherbatiy wrote:


I hereby nominate Kevin Rushforth to OpenJFX Project Lead [1][2].

Kevin has been working in OpenJFX Project for several years and is
currently acting as the de facto Project Lead.

Group Leads of the Project’s Sponsoring Groups, the Swing Group: Please
vote on whether to ratify this change, as required by the Bylaws [2].
Votes are due by July 1, 2016. Votes must be cast in the open by
replying to this message.

For Three-Vote Consensus instructions, see [3].

Thanks,
Alexandr.

[1]: http://openjdk.java.net/census#openjfx
[2]: http://openjdk.java.net/bylaws#project-lead
[3]: http://openjdk.java.net/bylaws#three-vote-consensus

Re: CFV: New OpenJFX Committer: Murali Billa

[Artem Ananiev]

Vote: yes

Artem

On 4/1/16 12:04 AM, Kevin Rushforth wrote:

I hereby nominate Murali Billa [1] to OpenJFX Committer.

Murali is a member of JavaFX team at Oracle working on WebKit, who has
contributed 10 changesets [5] to OpenJFX, at least 8 of which are
significant.

Votes are due by April 14, 2016.

Only current OpenJFX Committers [2] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [3]. Nomination to a project
Committer is described in [4].

Thanks,

-- Kevin

[1] http://openjdk.java.net/census#mbilla

[2] http://openjdk.java.net/census#openjfx

[3] http://openjdk.java.net/bylaws#lazy-consensus

[4] http://openjdk.java.net/projects#project-committer

[5] List of changesets:
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a251a1d65932
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ecea43f5734c
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/42b461505f27
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/82ecaebd44cf
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8643ca988cef
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/765fd07f22fc
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ae75f92d5e53
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/25db4b2e47a1
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/51c2129d282c
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/cb8a24f5db2a

Re: CFV: New OpenJFX Committer: Alexander Matveev

[Artem Ananiev]

Vote: yes

Artem

On 08/28/15 4:55 AM, Kevin Rushforth wrote:

I hereby nominate Alexander Matveev [1] to OpenJFX Committer.

Alexander was an initial member of JavaFX team at Oracle when the
OpenJFX project was created, and was on the initial list of approved
committers [2]. His status as OpenJFX committer was not recorded at that
time on the Census. This CVF is intended to correct this oversight.

Alexander's changes prior to JavaFX becoming open-source were
significant (which is why he was on the initial list of committers). In
particular, Alexander, along with the rest of the media team,
contributed much of the code that went into the open-source changeset
that Kirill Kirichenko pushed for OpenJFX in the JDK 8 release:

hg log -r aee256fde55

Counting his contribution to that changeset, Alexander now also has the
requisite number of changes in the open-source repo to become a committer.

hg log -M -u matvee

Votes are due by September 10, 2015.

Only current OpenJFX Committers [3] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [4]. Nomination to a project
Committer is described in [5].

Thanks,

-- Kevin

[1] http://openjdk.java.net/census#almatvee

[2]
http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html

[3] http://openjdk.java.net/census#openjfx

[4] http://openjdk.java.net/bylaws#lazy-consensus

[5] http://openjdk.java.net/projects#project-committer

Re: Only 1 GUI thread dialogs (was Re: 2 JavaFX applets in the same JVM)

[Artem Ananiev]

On 7/9/2014 1:51 AM, ngalarn...@abinitio.com wrote:

Hi Steve,

My understanding of Swing was that when in a modal dialog, which blocked
the EDT, a second EDT was fired up for the duration of the dialog to keep
the events flowing.


Swing doesn't do that. When a modal dialog is shown, it starts a nested 
event loop on the same event dispatching thread. JavaFX dialogs are 
implemented the same way.



When you say, below, that only 1 GUI thread is supported (and that thread
is the native GUI thread), how are (will?) modal dialogs handled?


See above. They are implemented with nested event loops.

Thanks,

Artem


Thanks,

Neil

P.S. I've been trying to read Jonathan's article on dialogs on
fxexperience.com, but haven't been able to because I get redirected to
hosting.xmission.com



From:   Stephen F Northover steve.x.northo...@oracle.com
To: Kevin Rushforth kevin.rushfo...@oracle.com,
ngalarn...@abinitio.com,
Cc: openjfx-dev@openjdk.java.net
Date:   07/08/2014 03:41 PM
Subject:Re: 2 JavaFX applets in the same JVM



This would imply that there was more than on distinguished GUI thread
per process.  JavaFX runs in the native GUI thread by design and more
than one GUI thread is not supported in JavaFX and on some platforms
(ie. Mac).

Steve

On 2014-07-08, 3:31 PM, Kevin Rushforth wrote:



Is running 2 JavaFX applets in the same JVM supported?


No, this is not supported. RT-29969 (and the non-public RT-32321) is
about running multiple applets from the same web page, each in their
own JVM. By design, JavaFX runs each applet in its own VM. It is very
unlikely that we would ever add the ability to run more than JavaFX
applet in the same VM.

-- Kevin


ngalarn...@abinitio.com wrote:

Hello,

What is the status of running 2 JavaFX applets in the same JVM
(separate_jvm = false)?
When we try to load 2 applets into the same JVM we get a runtime
error (I think it was class loader related).

When I searched in jira I found RT-29969 (the 2 applet test it refers
to may or may not be in the same JVM) which points to RT-32321 which
seems to be private (it gives me an error when I try to access it).

Is running 2 JavaFX applets in the same JVM supported?

If not, is that a bug or a feature?


Thanks,

Neil



NOTICE from Ab Initio: This email (including any attachments) may
contain information that is subject to confidentiality obligations or
is legally privileged, and sender does not waive confidentiality or
privilege. If received in error, please notify the sender, delete
this email, and make no further use, disclosure, or distribution.






NOTICE from Ab Initio: This email (including any attachments) may contain
information that is subject to confidentiality obligations or is legally
privileged, and sender does not waive confidentiality or privilege. If
received in error, please notify the sender, delete this email, and make
no further use, disclosure, or distribution.

Re: SnapCode is the first and only pure JavaFX IDE

[Artem Ananiev]

On 6/12/2014 5:36 AM, Jeff Martin wrote:

Today we finished a two week port of the remaining Swing components of SnapCode 
to JavaFX, including the code editer, file manager, welcome panel, runtime 
browser/player and much more.

That means JavaFX now has a real IDE written in JavaFX! Check out the video 
overview:

Blog: 
http://reportmill.wordpress.com/2014/06/11/snapcode-is-the-first-and-only-pure-javafx-ide/
Video: https://www.youtube.com/watch?v=VZH3Ifd-IIs

The good-new/bad-news is I won't be submitting any more JFXPanel bugs. :-)


Think about submitting SwingNode bugs instead :)

Thanks,

Artem


jeff

Re: CFV: New OpenJFX Committer: Eric Le Ponner

[Artem Ananiev]

Vote: yes

Artem

On 5/14/2014 9:33 PM, Stephen F Northover wrote:

I hereby nominate Eric Le Ponner to be an OpenJFX Committer.

Eric Le Ponner is a significant contributor of the JavaFX Scene Builder
2.0 product, and is the architect of the SB Kit API as well as the
designated owner of the Content Panel.  Eric has been working on SB for
more than 3 years, and during last year has been responsible for
approximately 1620 commits to the internal SB 2.0 repository that we are
converting to Open Source.

Eric is part of the team that has collectively done the Scene Builder
2.0 product, which is a complete re-implementation of the code base,
over a period of roughly 12 months. The new code base is more than
70,000 lines of code, spread over approximately 4000 commits.
Scene Builder 2.0 is in the process of being converted to the OpenJFX
repository, and will be maintained out of that repository after the
conversion.


Votes are due by May 29, 2014.

Only current OpenJFX Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [2]. Nomination to a project
Committer is described in [3].

[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Re: CFV: New OpenJFX Committer: Sandra Lions-Piron

[Artem Ananiev]

Vote: yes

Artem

On 5/14/2014 9:48 PM, Stephen F Northover wrote:

I hereby nominate Sandra Lions-Piron to be an OpenJFX Committer.

Sandra Lions-Piron is a significant contributor of the JavaFX Scene
Builder 2.0 product, and is the designated owner of the Hierarchy Panel
as well as all menu commands. Sandra has been working on SB since its
inception 4 years ago, and during last year has been responsible for
approximately 750 commits to the SB 2.0 repository that we are
converting to Open Source.

Sandra is part of the team that has collectively done the Scene Builder
2.0 product, which is a complete re-implementation of the code base,
over a period of roughly 12 months. The new code base is more than
70,000 lines of code, spread over approximately 4000 commits.
Scene Builder 2.0 is in the process of being converted to the OpenJFX
repository, and will be maintained out of that repository after the
conversion.


Votes are due by May 29, 2014.

Only current OpenJFX Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [2]. Nomination to a project
Committer is described in [3].

[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Re: CFV: New OpenJFX Committer: Yves Joan

[Artem Ananiev]

Vote: yes

Artem

On 5/14/2014 9:48 PM, Stephen F Northover wrote:

I hereby nominate Yves Joan to be an OpenJFX Committer.

Yves Joan is a significant contributor of the JavaFX Scene Builder 2.0
product, and is the designated owner of the Library Panel, Document
Panel and product packaging. Yves has been working on SB since its
inception 4 years ago, and during last year has been responsible for
approximately 960 commits to the SB 2.0 repository that we are
converting to Open Source.

Yves is part of the team that has collectively done the Scene Builder
2.0 product, which is a complete re-implementation of the code base,
over a period of roughly 12 months. The new code base is more than
70,000 lines of code, spread over approximately 4000 commits.
Scene Builder 2.0 is in the process of being converted to the OpenJFX
repository, and will be maintained out of that repository after the
conversion.


Votes are due by May 29, 2014.

Only current OpenJFX Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [2]. Nomination to a project
Committer is described in [3].

[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Re: CFV: New OpenJFX Committer: Mo Chicharro

[Artem Ananiev]

Vote: yes

Artem

On 5/14/2014 9:48 PM, Stephen F Northover wrote:

I hereby nominate Mo Chicharro to be an OpenJFX Committer.

Mo Chicharro is a significant contributor of the JavaFX Scene Builder
2.0 product, and, as the visual and interaction designer, he is the
designated owner of all FXML and CSS content. Mo has been working on SB
since its inception 4 years ago, and during last year has been
responsible for approximately 160 commits to the SB 2.0 repository that
we are converting to Open Source.

Mo is part of the team that has collectively done the Scene Builder 2.0
product, which is a complete re-implementation of the code base, over a
period of roughly 12 months. The new code base is more than 70,000 lines
of code, spread over approximately 4000 commits.
Scene Builder 2.0 is in the process of being converted to the OpenJFX
repository, and will be maintained out of that repository after the
conversion.

Votes are due by May 29, 2014.

Only current OpenJFX Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [2]. Nomination to a project
Committer is described in [3].

[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Re: Build Errors on Windows 8.1 / VS2012 Pro / JDK 1.8.0-b132 [was: Build Errors on Windows 8.1 / VS2010 Pro / JDK 1.8.0-b132]

[Artem Ananiev]

On 3/8/2014 1:04 AM, Kevin Rushforth wrote:

Hi Kay,

It looks like you are using VS2012 not 2010. We build JavaFX with VS
2010, and have some issues with 2012. However, we will need to resolve
them at some point.

Maybe someone else on the list has had luck building with VS 2012?


I was able to build FX with VS 2012 some time ago. The changes were 
mostly cosmetic (caused by different Visual Studio and Platform SDK 
directory layouts), except static C++ runtime linkage. And, of course, 
FX should be aligned with JDK, which is shipped with VS 2010 runtime 
(will it be changed in JDK9?), otherwise FX will have to ship with its 
own runtime libraries.


Thanks,

Artem


-- Kevin


Kay McCormick wrote:

Here is what I see as the relevant portions of the build log. This is
beyond my ability to fix easily at this point. I would attach the entire
compile log but I compiled with --debug and its 4mb. Let me know if I
should provide more information, file a bug, or direct my problem to
another forum.

Kay

12:35:16.275 [INFO] [org.gradle.process.internal.DefaultExecHandle]
Successfully started process 'command 'C:/Program Files (x86)/Microsoft
Visual Studio 12.0/VC/BIN/amd64/link.exe''
12:35:16.329 [QUIET] [system.out] libcpmt.lib(xthrow.obj) : error
LNK2038:
mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't
match value 'MD_DynamicRelease' in directwrite.obj
12:35:16.332 [QUIET] [system.out] libcpmt.lib(syserror.obj) : error
LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease'
doesn't match value 'MD_DynamicRelease' in directwrite.obj
12:35:16.336 [QUIET] [system.out]Creating library
C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.lib

and object
C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.exp

12:35:16.362 [QUIET] [system.out]
C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.dll

: fatal error LNK1319: 2 mismatches detected
12:35:16.368 [DEBUG] [org.gradle.process.internal.DefaultExecHandle]
Changing state to: FAILED
12:35:16.368 [INFO] [org.gradle.process.internal.DefaultExecHandle]
Process
'command 'C:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/BIN/amd64/link.exe'' finished with exit value 1319 (state:
FAILED)
12:35:16.368 [DEBUG]
[org.gradle.logging.internal.DefaultLoggingConfigurer]
Finished configuring with level: DEBUG, configurers:
[org.gradle.logging.internal.OutputEventRenderer@1593948d,
org.gradle.logging.internal.logback.LogbackLoggingConfigurer@1b604f19,
org.gradle.logging.internal.JavaUtilLoggingConfigurer@7823a2f9]
12:35:16.369 [DEBUG]
[org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter]
Finished executing task ':graphics:linkWinFont'
12:35:16.369 [LIFECYCLE] [org.gradle.TaskExecutionLogger]
:graphics:linkWinFont FAILED
12:35:16.369 [INFO]
[org.gradle.execution.taskgraph.AbstractTaskPlanExecutor]
:graphics:linkWinFont (Thread[main,5,main]) completed. Took 0.104 secs.
12:35:16.369 [DEBUG]
[org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker
[Thread[main,5,main]] finished, busy: 3 mins 14.44 secs, idle: 0.017 secs
12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger]
12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED
12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger]
12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 3
mins
29.213 secs

Result: New OpenJFX Committer: Victor Shubov

[Artem Ananiev]

Voting for Victor Shubov [1] was closed on Nov 07, 2013, but the results 
were never announced. Here they are:


Yes: 4
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus [2], this is 
sufficient to approve the nomination.


[1] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-October/011103.html


[2] http://openjdk.java.net/projects/#project-committer

Thanks,

Artem

Re: javafx.embed.singleThread=true not working

[Artem Ananiev]

Hi, Hendrik,

please, try adding the following line to the very beginning of the 
main() method:


PlatformImpl.startup(() - {});

PlatformImpl is an internal class from com.sun.javafx.application, so it 
is not an official way to do the job, it's just a workaround.


Another option is to wrap all the code after JFXPanel.init() into 
additional invokeLater(). By the time when JFXPanel constructor is 
finished, FX has already set up single threaded event dispatching 
mechanism, so all the subsequent Swing events (including invokeLater() 
calls) are executed on the right thread.


Thanks,

Artem

On 2/3/2014 3:16 PM, Hendrik Ebbers wrote:

Hi,
I’m currently trying the experimental support of the javafx.embed.singleThread 
flag to mix the EDT and JFX Application Thread. Therefore I created a demo 
application. But when I start the app the following exception is thrown:
Exception in thread AWT-EventQueue-0 java.lang.IllegalStateException: Not on 
FX application thread; currentThread = AWT-EventQueue-0

I think I’m doing something wrong but currently I have no idea why this is not 
working. Any ideas?

I’m using the folioing JavaFX version:

java version 1.8.0-ea
Java(TM) SE Runtime Environment (build 1.8.0-ea-b123)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b65, mixed mode)

Here is the code of the demo application:

public class JFXPanelDemo1 {

 private static JButton swingButton;
 private static Button jfxButton;

 public static void main(String[] args) {


 SwingUtilities.invokeLater(() - {
 JFrame swingFrame = new JFrame(Integrate JavaFX in Swing);
 swingFrame.getContentPane().setLayout(new BorderLayout());
 swingButton = new JButton(I'm a Swing button);
 swingFrame.getContentPane().add(BorderLayout.NORTH, swingButton);

 swingButton.addActionListener((e) - {
 jfxButton.setDisable(!jfxButton.isDisable());
 });

 JFXPanel jfxPanel = new JFXPanel();
 swingFrame.getContentPane().add(BorderLayout.CENTER, jfxPanel);

 jfxButton = new Button(I'm a JavaFX button);
 StackPane jfxPane = new StackPane(jfxButton);
 Scene jfxScene = new Scene(jfxPane);
 jfxPanel.setScene(jfxScene);

 jfxButton.setOnAction((e) - {
 swingButton.setEnabled(!swingButton.isEnabled());
 });

 swingFrame.setVisible(true);
 }
 );

 }
}

Re: Fwd: CFV: New OpenJFX Committer: Vadim Pakhnushev

[Artem Ananiev]

Vote: yes

Artem

On 12/12/2013 1:17 AM, David Hill wrote:


I hereby nominate Vadim Pakhnushev to OpenJFX Committer.

Vadim is a member of JavaFX Embedded team at Oracle. Vadim's changes are
in Glass Windows/D3d:

   hg log -M -u vadim

An incomplete list of Vadim's commits and reviews is also available by
the following link:

http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=vadim

Votes are due by Dec 25, 2013.

Only current OpenJFX Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [2]. Nomination to a project
Committer is described in [3].

[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Thanks,

Dave

Re: Scene Builder performance regression between 1.1 and 2.0

[Artem Ananiev]

On 11/7/2013 10:11 AM, Felix Bembrick wrote:

Scene Builder 2.0 has very serious performance issues (on my machines at
least).

When running 1.1  2.0 side-by-side, 1.1 is very responsive and behaves
very well.  On the contrary, 2.0 is extremely sluggish with a few seconds
between clicking on a control and the selection handles appearing and
trying to resize the properties pane is so slow that it is not usable.


It may be caused by exceptions or logging output to stdout/err...

Thanks,

Artem


I see this version of Scene Builder was built with JDK8 b112.

Is anyone else experiencing this?  Have I just hit on some subtle
performance issue with JavaFX 8 and the GPU drivers on this machine (which
is Windows 7 64-bit BTW).?

Felix

Re: Review Request: RT-34077 [Graphics, Swing] JFXPanel with WebView in JDK

[Artem Ananiev]

Hi, Petr,

since the return value now depends on presence/absence of FX scene 
embedded into JFXPanel, shouldn't we also change setEmbeddedScene() in 
JFXPanel.HostContainer?


Thanks,

Artem

On 11/7/2013 4:48 PM, Petr Pchelko wrote:

Hello, OpenJFX community.

Please review the fix for the issue: 
https://javafx-jira.kenai.com/browse/RT-34077
The webrev is available at: http://cr.openjdk.java.net/~pchelko/fx/34077/webrev/

Thank you.
With best regards. Petr.

Re: Review Request: RT-34077 [Graphics, Swing] JFXPanel with WebView in JDK

[Artem Ananiev]

On 11/7/2013 7:38 PM, Stephen F Northover wrote:

Artem old friend!!

We are moving all sorts of comments like this over to the JIRA rather
than sending them to the list.


My bad. I've duplicated this question in RT-34077 comments.

Thanks,

Artem


Steve

On 2013-11-07 10:24 AM, Artem Ananiev wrote:

Hi, Petr,

since the return value now depends on presence/absence of FX scene
embedded into JFXPanel, shouldn't we also change setEmbeddedScene() in
JFXPanel.HostContainer?

Thanks,

Artem

Re: did anyone encountered this?

[Artem Ananiev]

Yes, I've seen this many times. I didn't spend much time trying to 
understand what is the problem, though. The workaround is simple: just 
delete 3DViewer build folder.


Thanks,

Artem

On 11/6/2013 5:35 PM, Assaf Yavnai wrote:

:apps:experiments:3DViewer:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':apps:experiments:3DViewer:compileJava'.
  java.lang.ClassFormatError: Invalid Constant Pool entry Type 18

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.

BUILD FAILED

Total time: 39.292 secs
assaf@assaf-Latitude-E6410:~/ws/udev-refactoring/rt$ java -versionjava
version 1.8.0-ea
Java(TM) SE Runtime Environment (build 1.8.0-ea-b113)
Java HotSpot(TM) Server VM (build 25.0-b55, mixed mode)

Thanks,
Assaf

Re: JFXPanel with WebView in JDK8

[Artem Ananiev]

Hi, Lidierth,

what JDK8 version do you run your app? This exception is expected, when 
an old JDK8 build is used.


Thanks,

Artem

On 11/5/2013 11:37 PM, Lidierth Malcolm wrote:


NOTE: THIS EXCEPTION OCCURS WITH JDK8, BUT NOT WITH JDK7

public class NewFXMain1 {

 public static void main(String[] args) throws InterruptedException,
InvocationTargetException {

 EventQueue.invokeAndWait(new Runnable() {

 // Create the Swing components on the EDT
 @Override
 public void run() {
 JFrame f = new JFrame();
 f.getContentPane().setPreferredSize(new Dimension(500,
500));
 f.pack();
 f.setVisible(true);
 final JFXPanel jfx = new JFXPanel();
 f.getContentPane().add(jfx);

 // FX Thread
 Platform.runLater(new Runnable() {
 @Override
 public void run() {
 WebView browser = new WebView();
 WebEngine webEngine = browser.getEngine();
 // This is a reference to a web page on the
Waterloo web site
webEngine.load(http://waterloo.sourceforge.net/devwebpage/MathJax/mathjax.html;);

 Scene s = new Scene(browser);
 jfx.setScene(s);
 }
 });

 }
 });
 }
}


This gives (Note: using JDK8 and Running from NetBeans 7.4):

Executing
C:\Users\malcolm\Documents\waterloo\Sources\Java\kcl-waterloo-jfx\dist\run1852659813\kcl-waterloo-jfx.jar
using platform C:\Program Files\Java\jdk1.8.0/bin/java
Exception in thread AWT-EventQueue-0 java.lang.NullPointerException
 at
javafx.embed.swing.JFXPanel.getInputMethodRequests(JFXPanel.java:744)
 at
sun.awt.im.InputMethodAdapter.haveActiveClient(InputMethodAdapter.java:61)
 at sun.awt.windows.WInputMethod.activate(WInputMethod.java:285)
 at sun.awt.im.InputContext.activateInputMethod(InputContext.java:396)
 at sun.awt.im.InputContext.focusGained(InputContext.java:338)
 at sun.awt.im.InputContext.dispatchEvent(InputContext.java:245)
 at
sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:196)
 at java.awt.Component.dispatchEventImpl(Component.java:4817)
 at java.awt.Container.dispatchEventImpl(Container.java:2293)
 at java.awt.Component.dispatchEvent(Component.java:4707)
 at
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1954)

 at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:986)

 at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:610)

 at java.awt.Component.dispatchEventImpl(Component.java:4756)
 at java.awt.Container.dispatchEventImpl(Container.java:2293)
 at java.awt.Component.dispatchEvent(Component.java:4707)
 at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:746)
 at java.awt.EventQueue.access$400(EventQueue.java:97)
 at java.awt.EventQueue$3.run(EventQueue.java:697)
 at java.awt.EventQueue$3.run(EventQueue.java:691)
 at java.security.AccessController.doPrivileged(Native Method)
 at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)

 at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86)

 at java.awt.EventQueue$4.run(EventQueue.java:719)
 at java.awt.EventQueue$4.run(EventQueue.java:717)
 at java.security.AccessController.doPrivileged(Native Method)
 at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)

 at java.awt.EventQueue.dispatchEvent(EventQueue.java:716)
 at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:220)

 at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:135)

 at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:123)

 at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:119)
 at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:111)
 at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)

Re: Serializing JFXPanel with java.beans.XMLEncoder

[Artem Ananiev]

Hi, Lidierth,

could you provide the exception stack trace, please? It would help to 
understand whether you're over-optimistic or not :)


Thanks,

Artem

On 11/5/2013 9:14 PM, Lidierth Malcolm wrote:

When I add a JFXPanel to a Swing hierarchy that is then written to XML
using java.beans.XMLEncoder, all is well as long as the JFXPanel is empty.
When it has content, I see a NullPointerException.

Before I dig into the origins, am I being over-optimistic? : should I
expect java.beans.XMLEncoder to cope here?

ML

Request for review: RT-28347 - DnD between two JFXPanels

[Artem Ananiev]

Hi,

could you take a look at the following fix, please:

http://cr.openjdk.java.net/~art/javafx/RT-28347/

Some information about the changes is available in bug comments:

https://javafx-jira.kenai.com/browse/RT-28347

Thanks,

Artem

CFV: New OpenJFX Committer: Oleg Barbashov

[Artem Ananiev]

I hereby nominate Oleg Barbashov (OpenJDK user name: ogb) to OpenJFX 
Committer.


Oleg is a member of JavaFX SQE team at Oracle. He is currently an Author 
in OpenJFX and is an active contributor to this project, about 30 
changesets in the tests repository:


http://hg.openjdk.java.net/openjfx/8/master

Votes are due by Nov 07, 2013.

Only current OpenJFX Committers [1] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.


For Lazy Consensus voting instructions, see [2]. Nomination to a project 
Committer is described in [3].


[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Thanks,

Artem

Re: CFV: New OpenJFX Committer: Oleg Barbashov

[Artem Ananiev]

On 10/24/2013 5:07 PM, Kevin Rushforth wrote:

Vote: YES

Btw, the correct repo is:

http://hg.openjdk.java.net/openjfx/8/master/tests


Thanks for correction. This is indeed the repo I meant.

Artem


-- Kevin


Artem Ananiev wrote:


I hereby nominate Oleg Barbashov (OpenJDK user name: ogb) to OpenJFX
Committer.

Oleg is a member of JavaFX SQE team at Oracle. He is currently an
Author in OpenJFX and is an active contributor to this project, about
30 changesets in the tests repository:

http://hg.openjdk.java.net/openjfx/8/master

Votes are due by Nov 07, 2013.

Only current OpenJFX Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [2]. Nomination to a
project Committer is described in [3].

[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Thanks,

Artem

Result: New OpenJFX Committer: Joseph Andresen

[Artem Ananiev]

Voting for Joseph Andresen to OpenJFX Committer [1] is now closed.

Yes: 8
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus [2], this is 
sufficient to approve the nomination.


[1] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-September/010431.html


[2] http://openjdk.java.net/projects/#project-committer

Thanks,

Artem

Result: New OpenJFX Committer: Yao Wang

[Artem Ananiev]

Voting for Joseph Andresen to OpenJFX Committer [1] is now closed.

Yes: 5
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus [2], this is 
sufficient to approve the nomination.


[1] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-September/010436.html


[2] http://openjdk.java.net/projects/#project-committer

Thanks,

Artem

Re: Keyboard events

[Artem Ananiev]

On 10/10/2013 3:11 AM, Pedro Duque Vieira wrote:

Done.

https://javafx-jira.kenai.com/browse/RT-33458


Thank you!

Artem


Thanks, best regards,


On Wed, Oct 9, 2013 at 12:11 PM, Artem Ananiev artem.anan...@oracle.com
mailto:artem.anan...@oracle.com wrote:


On 10/9/2013 4:19 AM, Pedro Duque Vieira wrote:

Do you want me to file a Jira issue for this?


Yes, please.

I haven't found such a feature request in JavaFX JIRA. The only
issue which is slightly related is

https://javafx-jira.kenai.com/__browse/RT-32302
https://javafx-jira.kenai.com/browse/RT-32302

but it's not exactly about querying for keyboard state.

Thanks,

Artem

Regards,


On Mon, Oct 7, 2013 at 6:03 PM, Artem Ananiev
artem.anan...@oracle.com mailto:artem.anan...@oracle.com
mailto:artem.ananiev@oracle.__com
mailto:artem.anan...@oracle.com wrote:


 On 10/7/2013 6:53 PM, Richard Bair wrote:

 That being said, this seems like a very common use
case, and I
 wonder if there is something more we could do (in the
longer
 term, short term do as Artem suggests)


 One of the options is to provide API to query for keyboard
state at
 any arbitrary moment, whether particular key is pressed or
not. Even
 if we only support locking keys (Caps, Num, Scroll, Kana) and
 control keys (Shift, Control, Command, Alt), it will be of
great
 value. Game developers will be happy to have such API for
all the
 keys, including navigation and letter ones.

 Thanks,

 Artem


 On Oct 7, 2013, at 3:56 AM, Artem Ananiev
 artem.anan...@oracle.com
mailto:artem.anan...@oracle.com
mailto:artem.ananiev@oracle.__com
mailto:artem.anan...@oracle.com

 wrote:


 On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote:
 Hi,

 I have the following use case:
 When the user presses shift and the mouse is
hover the
 chart component the
 cursor must change to an open hand cursor
signaling to
 the user that the
 chart is ready for a panning action.
 The problem is that for this to be possible I
want the
 chart to be able to
 listen to keyboard events even when it doesn't
have focus.

 I think this is not possible and I wonder why.
Swing was
 the same, you
 could only listen to keyboard events if the
control had
 focus. Is this a
 technical limitation? If there is no technical
 limitation I think it would
 be better to remove this restriction, I think it is
 limiting and the above
 scenario is a good use case to show that.


 This is not a technical limitation, it's just the
way how
 it's supposed to work. All the key events are
dispatched to
 the component in focus, this is what input focus is.

 Scenario you described should be easier to
implement in FX
 than in Swing. In AWT/Swing, input events are
dispatched to
 a single component, while FX is much more flexible.
All the
 events are delivered to a Scene first, then
dispatched to
 the focused component (or component under mouse,
for mouse
 events), then bubbled up back to the Scene. What
you need is
 to register a custom event filter for the scene and
listen
 to all the key events.

 See Scene.addEventFilter() and
Scene.addEventHandler() for
 details.

 Thanks,

 Artem

 Thanks, best regards,




--
Pedro Duque Vieira




--
Pedro Duque Vieira

Re: Keyboard events

[Artem Ananiev]

On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote:

Hi,

I have the following use case:
When the user presses shift and the mouse is hover the chart component the
cursor must change to an open hand cursor signaling to the user that the
chart is ready for a panning action.
The problem is that for this to be possible I want the chart to be able to
listen to keyboard events even when it doesn't have focus.

I think this is not possible and I wonder why. Swing was the same, you
could only listen to keyboard events if the control had focus. Is this a
technical limitation? If there is no technical limitation I think it would
be better to remove this restriction, I think it is limiting and the above
scenario is a good use case to show that.


This is not a technical limitation, it's just the way how it's supposed 
to work. All the key events are dispatched to the component in focus, 
this is what input focus is.


Scenario you described should be easier to implement in FX than in 
Swing. In AWT/Swing, input events are dispatched to a single component, 
while FX is much more flexible. All the events are delivered to a Scene 
first, then dispatched to the focused component (or component under 
mouse, for mouse events), then bubbled up back to the Scene. What you 
need is to register a custom event filter for the scene and listen to 
all the key events.


See Scene.addEventFilter() and Scene.addEventHandler() for details.

Thanks,

Artem


Thanks, best regards,

Re: Keyboard events

[Artem Ananiev]

On 10/7/2013 6:57 PM, Pedro Duque Vieira wrote:

Hi Artem, Richard,

Thanks for your feedback! There's one more thing which further
complicates things and that I've forgot to mention. The chart is
embedded in a swing app, so doing as Artem suggests will not work: the
scene will have to be focused in order for it to receive keyboard
events, right?


For standalone FX apps (no Swing), it's required and enough to have FX 
scene focused. With Swing involved, things get more complicated. FX 
scene is considered to have focus, if the corresponding JFXPanel is 
focused (as a Swing component). Only in that case you'll be able to 
track key events using the event filters/handlers, otherwise you'll have 
to use Toolkit.addAWTEventListener() or something like this.


Thanks,

Artem


Thanks, best regards,


On Mon, Oct 7, 2013 at 3:53 PM, Richard Bair richard.b...@oracle.com
mailto:richard.b...@oracle.com wrote:

That being said, this seems like a very common use case, and I
wonder if there is something more we could do (in the longer term,
short term do as Artem suggests)

  On Oct 7, 2013, at 3:56 AM, Artem Ananiev
artem.anan...@oracle.com mailto:artem.anan...@oracle.com wrote:
 
 
  On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote:
  Hi,
 
  I have the following use case:
  When the user presses shift and the mouse is hover the chart
component the
  cursor must change to an open hand cursor signaling to the user
that the
  chart is ready for a panning action.
  The problem is that for this to be possible I want the chart to
be able to
  listen to keyboard events even when it doesn't have focus.
 
  I think this is not possible and I wonder why. Swing was the
same, you
  could only listen to keyboard events if the control had focus.
Is this a
  technical limitation? If there is no technical limitation I
think it would
  be better to remove this restriction, I think it is limiting and
the above
  scenario is a good use case to show that.
 
  This is not a technical limitation, it's just the way how it's
supposed to work. All the key events are dispatched to the component
in focus, this is what input focus is.
 
  Scenario you described should be easier to implement in FX than
in Swing. In AWT/Swing, input events are dispatched to a single
component, while FX is much more flexible. All the events are
delivered to a Scene first, then dispatched to the focused component
(or component under mouse, for mouse events), then bubbled up back
to the Scene. What you need is to register a custom event filter for
the scene and listen to all the key events.
 
  See Scene.addEventFilter() and Scene.addEventHandler() for details.
 
  Thanks,
 
  Artem
 
  Thanks, best regards,
 




--
Pedro Duque Vieira

Re: Keyboard events

[Artem Ananiev]

On 10/7/2013 6:53 PM, Richard Bair wrote:

That being said, this seems like a very common use case, and I wonder if there 
is something more we could do (in the longer term, short term do as Artem 
suggests)


One of the options is to provide API to query for keyboard state at any 
arbitrary moment, whether particular key is pressed or not. Even if we 
only support locking keys (Caps, Num, Scroll, Kana) and control keys 
(Shift, Control, Command, Alt), it will be of great value. Game 
developers will be happy to have such API for all the keys, including 
navigation and letter ones.


Thanks,

Artem


On Oct 7, 2013, at 3:56 AM, Artem Ananiev artem.anan...@oracle.com wrote:



On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote:
Hi,

I have the following use case:
When the user presses shift and the mouse is hover the chart component the
cursor must change to an open hand cursor signaling to the user that the
chart is ready for a panning action.
The problem is that for this to be possible I want the chart to be able to
listen to keyboard events even when it doesn't have focus.

I think this is not possible and I wonder why. Swing was the same, you
could only listen to keyboard events if the control had focus. Is this a
technical limitation? If there is no technical limitation I think it would
be better to remove this restriction, I think it is limiting and the above
scenario is a good use case to show that.


This is not a technical limitation, it's just the way how it's supposed to 
work. All the key events are dispatched to the component in focus, this is what 
input focus is.

Scenario you described should be easier to implement in FX than in Swing. In 
AWT/Swing, input events are dispatched to a single component, while FX is much 
more flexible. All the events are delivered to a Scene first, then dispatched 
to the focused component (or component under mouse, for mouse events), then 
bubbled up back to the Scene. What you need is to register a custom event 
filter for the scene and listen to all the key events.

See Scene.addEventFilter() and Scene.addEventHandler() for details.

Thanks,

Artem


Thanks, best regards,

Re: com.sun.prism.tkal.Window

[Artem Ananiev]

On 10/1/2013 8:27 PM, steve.x.northo...@oracle.com wrote:

Hi FX developers,

The class com.sun.prism.tkal.Window seems to have no references. Speak
now if you know anybody who uses it, otherwise it will get deleted.


This package was introduced as abstraction between Newt and Glass, so 
it's obsolete now. +1 to remove.


Thanks,

Artem


Steve

CFV: New OpenJFX Committer: Joseph Andresen

[Artem Ananiev]

I hereby nominate Joe Andresen to OpenJFX Committer.

Joe is a member of JavaFX Graphics team at Oracle. His first changeset 
in Prism is dated by 2009, and total number of commits is close to one 
hundred. Full list of Joe's changesets in the open workspace is 
available from command line:


hg log -u Joseph Andresen

Only current OpenJFX Committers [1] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.


For Lazy Consensus voting instructions, see [2]. Nomination to a project 
Committer is described in [3].


[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Thanks,

Artem

CFV: New OpenJDK Committer: Lisa Selle

[Artem Ananiev]

I hereby nominate Lisa Selle to OpenJFX Committer.

Lisa is a member of JavaFX Embedded team. Her changes are all over the 
JavaFX code, from cursors and input events to makefiles and virtual 
keyboard. The list of Lisa's commits in the workspace:


  hg log -u Lisa Selle
  hg log -u Lisa.Selle

Incomplete list is also available by the following link:

http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=selle

Votes are due to Oct 09, 2013.

Only current OpenJFX Committers [1] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.


For Lazy Consensus voting instructions, see [2]. Nomination to a project 
Committer is described in [3].


[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Thanks,

Artem

CFV: New OpenJFX Committer: Yao Wang

[Artem Ananiev]

I hereby nominate Yao Wang to OpenJFX Committer.

Yao is a member of JavaFX Graphics team at Oracle. Most of recent Yao's 
changes are in 3D support code, but not only there:


  hg log -u Yao Wang

Incomplete list of Yao's commits and reviews is also available by the 
following link:


http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=wang

Votes are due by Oct 09, 2013.

Only current OpenJFX Committers [1] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.


For Lazy Consensus voting instructions, see [2]. Nomination to a project 
Committer is described in [3].


[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Thanks,

Artem

Re: Why is almost everything in the API final

[Artem Ananiev]

As Jonathan said, Richard is the best person to answer this question, 
but let me provide my own thoughts below as well.


On 9/2/2013 3:55 AM, Pedro Duque Vieira wrote:

Hi,

Why is almost everything in the API final? OK, I understand there is a
security problem and not making things final could potential open security
holes.


It's not only about security. When API is final, it is easy to maintain 
and it is essential for backwards compatibility. Library developers know 
exactly, how classes and methods are used and how they can be evolved in 
the future. As a AWT/Swing maintainer I've seen many cases, when 
non-final classes were extended in a crazy way and used for absolutely 
different purposes than they were initially designed for.


Note that changing class/method/field from final to non-final is a 
backwards compatible change, but the reverse is not.



What I'm puzzled about is that the rest of the JDK doesn't use this pattern
and so I wonder if it is still effective this way?


I'm sure if JDK developers didn't have to preserve backwards 
compatibility, they would be glad to make everything final :)



I'm asking this because the penalties are significant, since you can not
easily extend the API because you can't subclass most framework classes.


Could you provide any examples, please?


Thanks, best regards,


Thanks,

Artem

Result: New OpenJFX Committer: Chien Yang

[Artem Ananiev]

Voting for Chien Yang to OpenJFX Committer [1] is now closed.

Yes: 6
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus [2], this is 
sufficient to approve the nomination.


[1] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-August/009720.html


[2] http://openjdk.java.net/projects/#project-committer

Thanks,

Artem

Result: New OpenJFX Committer: Mick Fleming

[Artem Ananiev]

Voting for Mick Fleming to OpenJFX Committer [1] is now closed.

Yes: 5
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus [2], this is 
sufficient to approve the nomination.


[1] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-August/009732.html


[2] http://openjdk.java.net/projects/#project-committer

Thanks,

Artem

CFV: New OpenJFX Committer: Mick Fleming

[Artem Ananiev]

I hereby nominate Mick Fleming (OpenJDK user name: mickf) to OpenJFX 
Commmitter.


Mick is a member of JavaFX Controls team at Oracle. He fixed many bugs 
and implemented tons of features in virtually every JavaFX Control, from 
buttons to tables. Here is a short list of his commits:


http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=mickf

As I wrote in another email, full list of changesets can be found from 
command line:


  hg log -u mickf

It shows far more than 32 entries, which would be enough for nomination 
to Reviewer, if we had this role OpenJFX.


Only current OpenJFX Committers [1] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.


For Lazy Consensus voting instructions, see [2].

Thanks,

Artem

[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

Re: Swing and JavaFX thread merge

[Artem Ananiev]

On 8/13/2013 7:17 PM, Werner Lehmann wrote:

Artem,

we already tested with 7u40 b35 - same thing:


Java Web Start 10.40.2.35
Using JRE version 1.7.0_40-ea-b35 Java HotSpot(TM) 64-Bit Server VM

...

runTest in AWT-EventQueue-2
jfx button click in JavaFX Application Thread
invokeLater from jfx button click in AWT-EventQueue-0
jbutton click in AWT-EventQueue-2
jfx button click in JavaFX Application Thread
invokeLater from jfx button click in AWT-EventQueue-0
jbutton click in AWT-EventQueue-2


OK. Thanks for confirmation. It's not related to AWT changes then.

Yesterday I spent an hour trying to understand, what thread group JavaFX 
event thread is created in. It seems there is no consistency between 
Windows, X11, and Mac OS X, which can be the source of the problems you 
observe.


Multiple AWT event dispatch threads is not a bug, it's a valid case, 
when running as an applet or as a JNLP application. The bug is when 
applet/application code is run on the wrong EDT, and this is what we 
have here.


BTW, it's not related to merging Swing and JavaFX threads, so we should 
either change the subject, or start a new discussion :)


Thanks,

Artem


Werner

On 13.08.2013 16:31, Artem Ananiev wrote:

Jeff, Werner,

thank you very much for detailed evaluation. The issues you observe may
be related to recent changes in AWT/Swing in 7u25. If my guess is
correct, they should be fixed in the latest 7u40 builds. I know it's not
released yet, but early access builds are available at java.net. Could
you run your apps with 7u40 and check if the problems are gone, please?

Thanks,

Artem

Re: Exception in one JFXPanel kills other JFXPanels, too

[Artem Ananiev]

Hi, Werner,

it looks like a bug in JFXPanel, could you file it to JIRA with a test 
case, please?


Thanks,

Artem

On 8/13/2013 2:32 PM, Werner Lehmann wrote:

Hi,

I have noticed the following problem with exception handling and
multiple JFXPanels (FX 2.2):

1. Two JFXPanels, J1 and J2
2. Throw NPE in layoutChildren of a control inside J1

This would print a stacktrace (see below). Then J2 is blocked: mouse
clicks have no effect anymore. I think I have seen something similar
with invalid FXML but did not check again now. On the other hand, if a
button action-event handler throws an exception everything is fine:
stacktrace is printed but the JFXPanels stay alive.

What is the deal here? When are exceptions lethal, and what can I do
to protect against this, preferably without adding a try..catch to each
layoutChildren (and whereever else this might be needed)...

Werner


java.lang.NullPointerException: kaboom
at
mint.javafx.scene.layout.designerpane.MintDesignerPane.layoutChildren(MintDesignerPane.java:192)

at javafx.scene.Parent.layout(Parent.java:1018)
at javafx.scene.Parent.layout(Parent.java:1028)
at javafx.scene.Scene.layoutDirtyRoots(Scene.java:513)
at javafx.scene.Scene.doLayoutPass(Scene.java:484)
at javafx.scene.Scene.access$3900(Scene.java:169)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2199)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:363)
at
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:460)
at
com.sun.javafx.tk.quantum.QuantumToolkit$9.run(QuantumToolkit.java:329)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at
com.sun.glass.ui.win.WinApplication.access$100(WinApplication.java:29)
at
com.sun.glass.ui.win.WinApplication$3$1.run(WinApplication.java:73)
at java.lang.Thread.run(Unknown Source)

Re: Swing and JavaFX thread merge

[Artem Ananiev]

Jeff, Werner,

thank you very much for detailed evaluation. The issues you observe may 
be related to recent changes in AWT/Swing in 7u25. If my guess is 
correct, they should be fixed in the latest 7u40 builds. I know it's not 
released yet, but early access builds are available at java.net. Could 
you run your apps with 7u40 and check if the problems are gone, please?


Thanks,

Artem

On 8/12/2013 4:51 PM, Werner Lehmann wrote:

Hi,

coincidentally we were experiencing the exact same problem with the
combination 7u25, OSX, Webstart. Also, we arrived at pretty much the
same workaround.

Investigation showed that multiple Swing eventqueues were created in the
above configuration. This would cause threading issues (NPE), paint
issues (flicker etc), drag-drop issues.

See below for a testcase: JFrame with a JButton and an fx button. When
clicked, the former prints its current thread, while the later switches
to EDT first (invokeLater) and then also prints the thread. On Windows,
this turns out to be the same thread as expected. On WebStart 7u25 OSX
we are getting different AWT-EventQueue-X threads.

Werner


public class TestSwingEDT extends JFrame{

  public static void main(final String[] args){
SwingUtilities.invokeLater(new Runnable() {
  @Override
  public void run() {
new TestSwingEDT().runTest(args);
  }
});
  }

  private void runTest(String[] args){

System.out.println(runTest in  + Thread.currentThread().getName());

this.setDefaultCloseOperation(EXIT_ON_CLOSE);
this.setSize(300, 200);

final JFXPanel jfxPanel = new JFXPanel();
Platform.runLater(new Runnable(){
  @Override
  public void run() {
Button btn = new Button(click me);
btn.onActionProperty().set(new EventHandlerActionEvent() {
  @Override public void handle(ActionEvent ae) {
System.out.println(jfx button click in  +
Thread.currentThread().getName());
SwingUtilities.invokeLater(new Runnable() {
  @Override public void run() {
System.out.println(invokeLater from jfx button click
in  + Thread.currentThread().getName());
  }
});
  }
});
HBox hbox = new HBox();
hbox.getChildren().add(btn);
jfxPanel.setScene(new Scene(hbox));
  }
});

JButton jbutton = new JButton(click me);
jbutton.addActionListener(new ActionListener() {
  @Override public void actionPerformed(java.awt.event.ActionEvent
e) {
System.out.println(jbutton click in  +
Thread.currentThread().getName());
  }
});

JPanel rootPanel = new JPanel();
rootPanel.add(jbutton);

this.getContentPane().add(jfxPanel, BorderLayout.NORTH);
this.getContentPane().add(rootPanel, BorderLayout.CENTER);

this.setVisible(true);

Platform.runLater(new Runnable(){
  @Override
  public void run() {
SwingUtilities.invokeLater(new Runnable() {
  @Override
  public void run() {
System.out.println(invokeLater in Platform.runLater in 
+ Thread.currentThread().getName());
  }
});
  }
});

  }
}

Re: Swing and JavaFX thread merge

[Artem Ananiev]

On 8/8/2013 1:45 AM, Jeff Martin wrote:

I thought I was getting this automatically - when I run on my
desktop, I can bring up a JOptionPane from a Swing thread and
JFXPanels (correctly) block. But when I run from Java Web Start, they
don't, and I end up with sporadic SwingUtilities.computeIntersection
NullPointerException.


Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane 
you described will work. As I wrote, it won't work by default in JDK8, 
you'll need to run your app with certain system property (something like 
-Djavafx.swing.singlethreaded=true).



Is there a secret setting that has a different default with JAWS?


NPEs look like a bug, either in AWT/FX, or in your application. I really 
doubt it's related to Java Web Start. Could you provide a test to 
reproduce the exceptions, please?


Thanks,

Artem


jeff


On Aug 7, 2013, at 5:06 AM, Artem Ananiev artem.anan...@oracle.com wrote:


Hi, Pedro Duque Vieira,

this is in progress. JDK part is tracked in 8015477:

http://bugs.sun.com/view_bug.do?bug_id=8015477

JavaFX part is described in RT-30694:

https://javafx-jira.kenai.com/browse/RT-30694

Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public 
API, it will be an experimental feature.

Thanks,

Artem

On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote:

Hi,

Some time ago there was a patch submitted which for all purposes merged the
swing and javafx thread, making it easier for developers working on a
swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX

Is this available now (I was under the impression it is)? How do I use it?

Thanks in advance,

Re: Swing and JavaFX thread merge

[Artem Ananiev]

Hi, Pedro Duque Vieira,

this is in progress. JDK part is tracked in 8015477:

http://bugs.sun.com/view_bug.do?bug_id=8015477

JavaFX part is described in RT-30694:

https://javafx-jira.kenai.com/browse/RT-30694

Note that in JDK8/JavaFX8 single-threaded mode will not be a part of 
public API, it will be an experimental feature.


Thanks,

Artem

On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote:

Hi,

Some time ago there was a patch submitted which for all purposes merged the
swing and javafx thread, making it easier for developers working on a
swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX

Is this available now (I was under the impression it is)? How do I use it?

Thanks in advance,

Re: A different way to handle pulse timing

[Artem Ananiev]

On 8/5/2013 10:26 PM, Richard Bair wrote:

In the past we have seen situations where there are so many
tasks on the user event thread, that user response (even on
desktop) was not acceptable. Some of these items are getting
better as we improve design (ie less redundant layout
operations causes by a single change/event).

Right, but I don't see how that could still happen in this
proposal? The problem before was the pulse events were handled
outside of the event queue (as I recall) so that they got higher
priority. We got rid of the higher priority and starvation
ceased. This proposal would not reintroduce priorities, so I
don't see how you could end up with input event starvation
again?

rendering is staged on the event queue (layout, adding the render
job to the render thread). It has been this way for quite a while
now. As far as I remember,( other than paths with live resize),
we have never had a mechanism that provided for event priority (at
least not on the Linux side where I tend to live).


This is how I thought it used to be done: we had (still have) a
separate glass thread which fires off once ever 16ms or so. We used
to take this pulse and handle it at the next available opportunity,
which was explicit prioritization. If the pulse handling took longer
than 16ms, by the time the pulse ended we'd have another pulse ready
to be handled and would starve the queue. Today, we get this event
and add it to the event queue, so we are never starving the event
queue.

In this proposal, we also would be putting the next pulse on the end
of the queue, so it is impossible to starve input events.


Putting the next pulse on the end of the queue is surprisingly difficult 
task, at least on Windows. If we use standard APIs provided by the 
platform, PostMessage() and SendMessage(), events are always put to the 
head of the queue. If we use timer events, they are of the lowest 
priority, so we'll have paint starvation instead of input events 
starvation.


Thanks,

Artem


Thanks
Richard

Re: A different way to handle pulse timing

[Artem Ananiev]

On 8/5/2013 9:09 PM, Richard Bair wrote:

In the past we have seen situations where there are so many tasks
on the user event thread, that user response (even on desktop) was
not acceptable. Some of these items are getting better as we
improve design (ie less redundant layout operations causes by a
single change/event).


Right, but I don't see how that could still happen in this proposal?
The problem before was the pulse events were handled outside of the
event queue (as I recall) so that they got higher priority. We got
rid of the higher priority and starvation ceased. This proposal would
not reintroduce priorities, so I don't see how you could end up with
input event starvation again?


Here is that bug:

RT-20656: Pending requests from Application.invokeLater can cause input 
event starvation


It is indeed fixed, but the fix was to make sure we always have a window 
to dispatch input events (sometimes, very small, but still). Higher 
priority for user/application runnables is still there.


Thanks,

Artem


BTW - it is very easy to write a bad app which will demonstrate
the problem. As a thought example - if on a button click, you
calculate PI to the nth digit before updating your text field - and
you do it in the event callback - you are stalling the user event
thread. Add in enough computes and you get an very unresponsive
app. Instead of computes, you can just call sleep to see the
problem too :-)


But this is the case today as well.

Richard

Re: A different way to handle pulse timing

[Artem Ananiev]

On 8/6/2013 6:07 PM, Scott Palmer wrote:


On 2013-08-06, at 9:10 AM, Artem Ananiev artem.anan...@oracle.com wrote:


On 8/5/2013 10:26 PM, Richard Bair wrote:


In this proposal, we also would be putting the next pulse on the
end of the queue, so it is impossible to starve input events.


Putting the next pulse on the end of the queue is surprisingly
difficult task, at least on Windows. If we use standard APIs
provided by the platform, PostMessage() and SendMessage(), events
are always put to the head of the queue. If we use timer events,
they are of the lowest priority, so we'll have paint starvation
instead of input events starvation.


If the OS message queue is fundamentally broken (i.e. it does not
behave like a queue), can all this be done on a proper queue that you
have control over?


I wouldn't say it's broken :) It's implemented this way by design. BTW, 
as far as I know, Mac OS X is similar to Windows wrt event handling: all 
the selectors (correspond to PostMessage() and SendMessage()) are 
processed before input events.



I.e. in the OS-specific message loop, just move the messages to a
more reasonably behaved queue.  Posting a request to process a pulse
would simply queue the operation on the well behaved queue and not
use the OS PostMessage or SendMessage mechanism at all.  I admit to
not knowing enough about Windows message processing to know if that
even makes sense.


What you describe is close to how JavaFX is implemented on embedded 
platforms. See Lens code in Glass for details. We do this, because on 
that platforms there is virtually no native event queue, so we have our 
own. However, on platforms like Windows or Mac OS X, we have to use 
native event queues, otherwise JavaFX apps won't be good citizens there.


This is what we have in AWT/Swing, where a native event queue is 
separate from Java event queue. I can't say the exact number of minor 
(e.g. sluggish window resizing), major (dragndrop not working), and even 
fatal (JVM crashes) issues we fixed in AWT, that were caused by this 
architecture with 2 queues, but believe me this number is huge.



(Windows seriously doesn't have a mechanism to put something on the
tail end of the message queue? Wow, don't they understand how a
queue is supposed to work?)


Why do you think it must be a queue? :) It can be a queue, but it can be 
something more complex as well. And yes, there is no easy way to put an 
event to the tail of the queue on Windows. What we can do is to put 
events to the queue with PostMessage/SendMessage, but dequeue them in 
different order. We prototyped that in the past, but didn't find it 
acceptable.


Thanks,

Artem


Scott

Re: CFV: New OpenJFX Committer:Daniel Blaukopf

[Artem Ananiev]

Vote: yes.

Artem

On 8/6/2013 7:15 PM, David Hill wrote:

I hereby nominate Daniel Blaukopf to OpenJFX Committer.
Daniel is a member of the Embedded Device team, which means he works
across various aspects of the platform. He is also the architect for the
embedded device space.

His recent work can be seen here:

   http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf

Votes are due by Aug 21, 2013.

Only current OpenJFX Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [2].

Thanks,
 David

[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

Re: A different way to handle pulse timing

[Artem Ananiev]

Hi, Richard,

as far as I can read it, your idea is to start preparing the next frame 
right after synchronization (scenegraph to render tree) is completed for 
the previous frame. Do I get it correctly? If yes, we'll likely 
re-introduce the old problem with input events starvation. There will be 
no or very little window, when the events can be processed on the event 
thread, because the thread will always be either busy handling CSS, 
animations, etc., or blocked waiting for the render thread to finish 
rendering.


See more comments/questions below.

On 7/26/2013 9:22 AM, Richard Bair wrote:

Hi,

I'm probably missing something obvious and you guys on Glass / Prism
/ Quantum can help set me straight. I was thinking tonight of a
different way of initiating pulse events that would, I think,
completely smooth out the pulses such that we don't end up with
drift due to the timer being at a different rate than the GPU.

Suppose we have two variables in the system (and for simplicity lets
talk about a single Scene, because one problem I think this idea has
is with multiple scenes and I want to discuss that separately after
the core mechanism is understood):

- boolean pendingPulse
- int runningAnimationCounter


We already have the latter. QuantumToolkit.animationRunnable is used to 
track if there are any live animations. When the last of them is 
finished, this runnable is set to null, this is my understanding.



Whenever an animation starts, the runningAnimationCounter is
incremented. When an animation ends, it is decremented (or it could
be a SetAnimation or whatever). The pendingPulse is simply false to
start with, and is checked before we submit another pulse. Whenever a
node in the scene graph becomes dirty, or the scene is resized, or
stylesheets are changed, or in any case something happens that
requires us to draw again, we check this flag and fire a new pulse if
one is not already pending.


Scene graph is only changed on the event thread. So my guess is that 
fire a new pulse is just


  Platform.runLater(() - pulse())

correct?


When a pulse occurs, we process animations first, then CSS, then
layout, then validate all the bounds, and *then we block* until the
rendering thread is available for synchronization. I believe this is
what we are doing today (it was a change Steve and I looked at with
Jasper a couple months ago IIRC).

But now for the new part. Immediately after synchronization, we check
the runningAnimationCounter. If it is  0, then we fire off a new
pulse and leave the pendingPulse flag set to true. If
runningAnimationCounter == 0, then we flip pendingPulse to false.
Other than the pick that always happens at the end of the pulse, we
do nothing else new and, if the pick didn't cause state to change, we
are now quiescent.

Meanwhile, the render thread has run off doing its thing. The last
step of rendering is the present, where we will block until the thing
is presented, which, when we return, would put us *immediately* at
the start of the next 16.66ms cycle. Since the render thread has just
completed its duties, it goes back to waiting until the FX thread
comes around asking to sync up again.

If there is an animation going on such that a new pulse had been
fired immediately after synchronization, then that new pulse would
have been handled while the previous frame was being rendered. Most
likely, by the time the render thread completes presenting and comes
back to check with the FX thread, it will find that the FX thread is
already waiting for it with the next frames data. It will synchronize
immediately and then carry on rendering another frame.


Given that you propose to fire a new pulse() whenever anything is 
changed in scene graph, and also right after synchronization, there is 
no need to have an external timer (QuantumToolkit.pulseTimer()) any longer.



I think the way this would behave is that, when an animation is first
played, you will get two pulses close to each other. The first pulse
will do its business and then synchronize and then immediately fire
off another pulse. That next pulse will then also get processed and
then the FX thread will block until the previous frame finishes
rendering. During this time, additional events (either application
generated via runLater calls happening on background threads, or from
OS events) will get queued up. Between pulse #2 and pulse #3 then a
bunch of other events will get processed, essentially playing
catch-up. My guess is that this won't be a problem but you might see
a hiccup at the start of a new animation if the event queue is too
full and it can't process all that stuff in 16ms (because at this
point we're really multi-theaded between the FX and render threads
and have nearly 16ms for each thread to do their business, instead of
only 8ms which is what you'd have in a single threaded system).

Another question I have is around resize events and how those work.
If they also come in to glass on the FX thread (but at a 

Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac

[Artem Ananiev]

On 7/25/2013 9:24 PM, Richard Bair wrote:

Hi Petr,

We are in a separate thread discussing jitter where being able to
measure dropped frames is crucial. We have the PulseLogger class
which keeps track of this kind of information (at least, it measures
the amount of time spent in a particular pulse). There is a message
that sometimes displays about dropping a frame, but I don't know if
it captures the same cases as what you have captured here. Where did
you instrument to measure which frames were actually rendered?


Just a short comment here. I'm not sure it matters, but it seems there 
is some misunderstanding here.


RT-26702 was the case, when a bug was in the mechanism used to measure 
performance. We counted the number of rendered frames in Prism/Quantum, 
but the number of frames really delivered to the screen was different. 
The message about dropped frames is likely about dropping at 
Prism/Quantum level, not at the Glass/CALayer level.


Petr's fix for RT-26702 addressed this problem, so more frame rendered 
in Quantum are now displayed on the screen. That's why even if you see 
FX perf counter now reports a lower number (comparing to what it did 
before the fix), the actual number of frames displayed to the screen is 
higher.


Thanks,

Artem


I need a reliable mechanism for measuring jitter. We're not running
full speed, so if I'm handling frames at less than 16ms per frame,
then I should never see any jitter, unless we have a loss of
synchronization between our pulse timer and the display. How can I
measure this reliably? Right now we have to just stare at our
monitors and see if something looks suspicious. I'd rather have a
fool-proof method of determining whether we're hitting each frame
right on target.

Any ideas?

Richard

On Jul 24, 2013, at 11:31 AM, Petr Pchelko petr.pche...@oracle.com
wrote:


Hello, Richard.

These changes fix the problem with dropping frames on Mac because
of locking between the render thread and UI thread.

I have made some measurements with Controls benchmark and GUIMark2.
The numbers without braces is the FPS rendered by Prism and the
braced numbers represent how many frames we are actually rendering
on the screen.

  Test Fix No Fix
bitmap-1000  76.1 (76.0)  75.3 (44.1)
bitmap-3000  38.3 (38.1)  36.9 (31.2)
bitmap-5000  23.4 (23.2)  22.6 (18.4)
vector   31.6 (31.3)  31.8 (29.0)
CheckBox 79(79)67(47)

As you could see, with the fix we almost never drop frames, all of them are 
actually delivered to the screen. Prism performance is improved in some cases 
too. These are not all the results, just examples to feel the difference.

With best regards. Petr.

On Jul 24, 2013, at 8:23 PM, Richard Bair richard.b...@oracle.com wrote:


The name of the issue is pretty ho-hum, but actually this was a huge amount of 
work to get finished. Petr, Artem, or Steve, can you give us a run-down of the 
performance impact of this change on Mac?

Thanks
Richard

On Jul 24, 2013, at 12:32 AM, hang...@oracle.com wrote:


Changeset: dd30604ab7d0
Author:Petr Pchelko petr.pche...@oracle.com
Date:  2013-07-24 11:24 +0400
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd30604ab7d0

RT-26702 Poor DisplacementMap effect performance on Mac
Reviewed-by: anthony, art, snorthov

! modules/graphics/src/main/native-glass/mac/GlassEmbeddedWindow+Overrides.m
! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.h
! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.m
! modules/graphics/src/main/native-glass/mac/GlassLayer3D.h
! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m
! modules/graphics/src/main/native-glass/mac/GlassOffscreen.h
! modules/graphics/src/main/native-glass/mac/GlassOffscreen.m
! modules/graphics/src/main/native-glass/mac/GlassView3D.m

Re: resize issue

[Artem Ananiev]

On 7/26/2013 7:35 PM, Peter Penzov wrote:

I tested to resize component using mouse drag in JVM 8 b94. It's working
very smooth and easy when I move the mouse and hold the border of the
component.
I also tested the same code in JVM 8 b99. It's not very easy to resize the
component. I cannot hold the border of the component for long time. I
suppose this is caused by possible bug. Before I open a bug in Jira I want
to ask you is this a known problem?


It sounds like a bug, but it's hard to say for sure. Could you provide a 
code snippet, or a simple test?


Thanks,

Artem

Re: WebView capabilities review

[Artem Ananiev]

On 7/25/2013 3:06 PM, Felix Bembrick wrote:

Artem, I don't think you can blame the slowness of WebView and famo.us
http://famo.us entirely on the lack of JIT as the 64-bit Qt WebView is
also based on WebKit and that site peforms extremely well with it.


Sure, there may be other reasons of slowness than the lack of JIT 
compilation on 64-bit Windows.


Thanks,

Artem


On 25 July 2013 20:21, Felix Bembrick felix.bembr...@gmail.com
mailto:felix.bembr...@gmail.com wrote:

I have noticed something curious.

When I run the impact.js demo that Klaus posted a link to I see a
very smooth animation.  The curious part is that on this same
machine I see noticeable flicker and jittering when I run even the
most simple JavaFX animation and have never seen one that performs
as smoothly as the impact.js demo within WebView.  Also, the
impact.js demo runs very smoothly even when I run the WebView maximised.

OK, so now I know that it can't be the actual graphics hardware or
driver that cause JavaFX animations to flicker and clearly JavaFX
*can* render animated content without jittering so why then do
simple animations (such as those from Ensemble) perform so poorly?


On 25 July 2013 02:02, Artem Ananiev artem.anan...@oracle.com
mailto:artem.anan...@oracle.com wrote:


On 7/24/2013 2:55 AM, Felix Bembrick wrote:

Windows 7 64-bit here.


On this platform, JavaFX web component is compiled without JIT
support for JavaScript:

https://javafx-jira.kenai.com/__browse/RT-24998
https://javafx-jira.kenai.com/browse/RT-24998

It explains why it is slow, but it doesn't explain rendering
artifacts.

Thanks,

Artem


On 24 July 2013 08:53, Richard Bair richard.b...@oracle.com
mailto:richard.b...@oracle.com wrote:

I've filed
https://javafx-jira.kenai.com/__browse/RT-31885
https://javafx-jira.kenai.com/browse/RT-31885, lets
see how
that turns out.

Richard

On Jul 23, 2013, at 3:49 PM, Richard Bair
richard.b...@oracle.com
mailto:richard.b...@oracle.com wrote:

Doh, that's just what you said :-)

On Jul 23, 2013, at 3:49 PM, Richard Bair
richard.b...@oracle.com
mailto:richard.b...@oracle.com

wrote:


I'm not seeing anything at all, beyond a fuzzy
background image

(similar app to yours):


import javafx.application.__Application;
import javafx.scene.Scene;
import javafx.scene.web.WebView;
import javafx.stage.Stage;

public class HelloWebView extends Application {
@Override public void start(Stage stage)
throws Exception {
WebView web = new WebView();
web.getEngine().load(http://__famo.us/
http://famo.us/);
Scene scene = new Scene(web);
stage.setScene(scene);
stage.setTitle(HelloWebView)__;
stage.show();
}

public static void main(String[] args) {
launch(args);
}
}

I'm on Mac. What OS are you running on?

Re: Disabling JavaFX minimise/maximise/etc buttons

[Artem Ananiev]

On 7/24/2013 12:34 AM, Anthony Petrov wrote:

Hi Werner,

On 07/23/2013 03:19 PM, Werner Lehmann wrote:

On 23.07.2013 12:39, Artem Ananiev wrote:

To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?


I create resizable modal dialogs on a frequent basis. To me, sizability
is a convenience for the user. At the same time, modal dialogs should
not be maximized. My opinion.


I don't agree. IMO, it's annoying when I'm able to resize a window
freely but unable to maximize it. This just doesn't look logical or
convenient.


+1


Unminimizable windows are annoying. If we disable that, we'll likely get
some weirdness, e.g. Win+M or Win+D on Windows will leave the window on
the desktop, which is not what users expect.


Minimizing a modal dialog does not achieve much because the owning
window is still blocked. Unless that window is minimized along. At least
Windows usually disables the window decoration buttons of the owning
window though.


Indeed. I was thinking about implementing the behavior that OS X
provides for native windows: if you iconify an owned modal dialog, its
owner gets iconified as well. This looks very convenient. We might try
to implement this in Glass for other platforms as well. Or
alternatively, we could provide an API to disable window iconification.


Modal dialogs are (or should be) used to get some input from user. 
Window closing confirmation is a good example. Application cannot 
proceed further, until it have the input, so it doesn't make sense to 
minimize the modal dialog and leave application in the suspended state.


Thanks,

Artem


--
best regards,
Anthony

Re: Disabling JavaFX minimise/maximise/etc buttons

[Artem Ananiev]

On 7/24/2013 12:45 AM, Fabrizio Giudici wrote:

On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov
anthony.pet...@oracle.com wrote:


I don't agree. IMO, it's annoying when I'm able to resize a window
freely but unable to maximize it. This just doesn't look logical or
convenient.


I'm with Werner here. Maximixing a dialog is usually ugly from the
aesthetic point of view, but sometimes I'm annoyed by dialogs that are
just a bit too narrow for entering a text, or something else
(incidentally, e.g. the Java control panel seems to be filled with
non-resizable windows designed just to annoy people :-). I'd just like
to stretch them a bit.


Could you identify the boundary between just making a window larger and 
maximizing it? I can't. What about Windows 7 snap feature, is it 
resizing or maximizing? In other words, my understanding is that if a 
window is resizable, it should be maximizable as well. However, as I 
wrote in my previous emails, sometimes it's out of Java control: we can 
say if a window should be resizable or not, and the platform decides if 
it is minimizable/maximizable or not.


Thanks,

Artem


But I don't know how this stands with the various operating system
design guidelines.

Re: Disabling JavaFX minimise/maximise/etc buttons

[Artem Ananiev]

On 7/22/2013 11:14 AM, Pavel Safrata wrote:

Hi Jonathan,
I believe this has been neither requested nor discussed so far. I don't
see why this couldn't be added, it just might have to be a conditional
feature, we'll have to check. Feel free to file a feature request.


Some native platforms (mostly, X window managers) don't provide direct 
APIs to enable/disable certain window decoration buttons. A library or 
an application may provides some hints, which may or may not be 
respected by WM.


I like what we have right now, StageStyle approach. Application defines 
the purpose of the window and let the platform decide, what are 
available actions for it.


Thanks,

Artem


Regards,
Pavel

On 21.7.2013 4:44, Jonathan Giles wrote:

Hi all,

For once this is a request for more information from another JavaFX
team, rather than a review request, etc! :-)

I'm keen to see support in JavaFX Stage / Window classes for an API
that would allow for the minimize / maximize / full screen / etc
buttons to be disabled. I'm aware of the StageStyle.UTLITY option
(which does disable the minimize button), but sometimes you don't want
a utility stage style, but you do want to prevent minimizing a stage.
My particular use case is dialogs - you can see a discussion of the
issue at [1].

For example, I note that Stage has an iconfied property to represent
whether the stage is minimized, but no property to specify whether the
stage should be allowed to be iconified (setIconifiable(boolean),
boolean isIconifiable(), for example). Is there a reason for this or
just that this API hasn't been required yet?

In short, I would love API to allow me to specify whether a stage can
be minimised, maximised and made full screen, and for this to follow
through to the buttons available in the native titlebar area of the
stage. Does such an API exist, is there a valid reason why it doesn't,
or should I file a jira to request such API?

[1]
https://bitbucket.org/controlsfx/controlsfx/issue/49/dialogs-should-use-native-title-bars


Thanks!
-- Jonathan

Re: JavaFX 8 Progress

[Artem Ananiev]

On 7/18/2013 3:00 AM, David Ray wrote:

Hi Richard,

I don't see any mention of WebStart and JavaFX on the milestone list - are 
issues surrounding (and suffocating :)) WebStart going to addressed as part of 
the JDK release 8 instead?


Java Plugin and Java Web Start are not parts of JavaFX (although JavaFX 
provides some APIs for them), they are shared between JDK and JavaFX and 
released as a part of Oracle JDK8 (not included to OpenJDK).


Thanks,

Artem


David

Sent from my iPhone

On Jul 17, 2013, at 12:06 PM, Richard Bair richard.b...@oracle.com wrote:


Hi Peter,

Our dates match up with JDK 8: http://openjdk.java.net/projects/jdk8/milestones

Feature complete was a month ago (but little API tweaks continue to happen). 
Things are supposed to be reasonably stable by October 24 (Zero Bug Bounce 
http://openjdk.java.net/projects/jdk8/milestones#Zero_Bug_Bounce) and GA in 
March.

Richard

On Jul 17, 2013, at 9:52 AM, Peter Penzov peter.pen...@gmail.com wrote:


Hi,
  I'm new to JavaFX I'm interested what is the current progress of
development of JavaFX 8. I want to use it for base framework for my
enterprise application but I have concerns is it stable to be used? Can you
give me some information do you plan to add something else before the
official release?

Best wishes,
Peter

Re: Experience with piecewise migration Swing - JFX

[Artem Ananiev]

On 6/17/2013 5:17 PM, Anthony Petrov wrote:

On 06/17/13 16:35, Werner Lehmann wrote:

In addition to what has been said before, you could check Jira for
keywords jfxpanel and/or swing. Just today we had another Mac-only
problem. Apparently AWT is not as thread-safe on Mac as it is on
Windows, resulting in deadlocks in native AWT code (which currently is a
guess, not confirmed, RT-31124).


I haven't investigated deeply, but since you've mentioned cursors I
believe this issue has been fixed already. Please try 7u40 and/or 8 ea
builds.


Even with one JFXPanel and other Swing UI on the same window, you'll get
a problem with tab focus movement: the jfxpanel would happily receive
focus but then users cannot tab out of the jfxpanel.


Did you file a bug for this issue?


There is already filed one:

RT-10919: Provide possibility to traverse focus out of FX scene

Thanks,

Artem


Also seen today: after closing the last JFXPanel while the Swing
application continues, FX would exit the platform (not the VM) and you
cannot use another JFXPanel. There is probably some workaround available.


You want to call Platform.setImplicitExit(false). Please see

http://docs.oracle.com/javafx/2/api/javafx/application/Platform.html#setImplicitExit(boolean)


And just in case it has not been said before: you cannot have a Stage on
top of a JFrame (modal or not). This forces you to wrap a JFXPanel into
a JDialog.


To clarify: you can't make a Swing frame be a parent of an FX stage,
meaning that you can't maintain a particular z-order between the two. So
you have to wrap a JFXPanel into a JDialog to implement this behavior.

--
best regards,
Anthony



I have also seen a performance problem. Try an indeterminate progressbar
in a JFXPanel. The progressbar width directly correlates with CPU usage.
With ~400px width I get about 20% CPU usage (almost one core). This is
probably caused by constant pixel shifting to AWT.

Werner

On 14.06.2013 17:08, Robert Krüger wrote:

What are the hidden problems one should be
aware of (other than having 2 UI threads).