Re: Default PointLight for Scene

[Chien Yang]

No, this light is created internally within JavaFX as a convenient light 
source if the scene doesn't have one. User can't access to it reference.


You can find this information in the Scene class documentation:

Class Scene

...

A default headlight will be added to a scene that contains one or more 
Shape3D nodes, but no light nodes. This light source is a Color.WHITE 
PointLight placed at the camera position.



- Chien



On 05/23/2017 09:11 AM, Nir Lisker wrote:

A Scene supplies a default PointLight if it contains a 3D object. However,
adding a Light to any group in the scene removes the default light. Is it
possible to retain the light, or get a reference to it from the scene?

[10] Code Review Request For 8178837: Potential performance drawback due to type mismatch

[Chien Yang]

Hi Kevin,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8178837
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8178837/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8178804: Excessive memory consumption in TriangleMesh/MeshView

[Chien Yang]

Hi Kevin,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8178804
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8178804/webrev.00/

Thanks,
- Chien

Re: JavaFX graphics performance

[Chien Yang]

Hi Michael,

Yes, this is a server bug and a backport to 8u and 9 is also being 
consider at this moment. Thanks for bringing it to our attention.


Thanks,
- Chien

On 4/18/17, 2:22 AM, Michael Paus wrote:

Hi

In
https://bugs.openjdk.java.net/browse/JDK-8178804
"Excessive memory consumption in TriangleMesh/MeshView"
you wrote:
There is a missing divide (by VERTEX_SIZE_VB) when computing the 
growth of vertexBuffer array as needed. Hence it has the potential of 
creating a vertexBuffer and some cached data to 9 times as big as 
designed. However this bug only affect Mesh with 
VertexFormat.POINT_NORMAL_TEXCOORD.


This somehow contradicts your last comment in
https://bugs.openjdk.java.net/browse/JDK-8089605
"[3D] TriangleMesh/MeshView high memory/CPU usage"
Application should use the new user-defined normals format for dynamic 
mesh to avoid high memory and CPU usage.


I hope the bug fix will also be backported to Java 8.
Michael

Am 12.04.17 um 22:19 schrieb Chien Yang:
BTW, it is a bug that we are unaware of if you are seeing a 60X 
nominal memory consumption in your program.  Please file a JIRA with 
a test program and we will investigate it.


Thanks,

- Chien


On 4/10/2017 1:08 PM, Kevin Rushforth wrote:
We are planning some performance improvements in JDK 10, mostly in 
the areas of CSS and layout. If you have specific concerns in other 
areas we could look into them. Having a specific test case that 
shows a performance problem would be a good start.


-- Kevin


Michael Paus wrote:

Hi,

more and more people ask me why I am still doing GUI development in 
JavaFX instead
of following the  mainstream and use some web technology. One of 
the arguments
I could use in the past was performance but nowadays this does not 
seem to be such
a valid argument anymore. Web technologies are catching up quickly 
and JavaFX currently
has not much to offer here. Actually the general drawing 
performance is very bad compared
to what is in principle possible with a modern GPU. I even tried to 
use a TriangleMesh
to better exploit the graphics hardware but this approach is also 
limited by the fact that
a TrinangleMesh has an excessive memory usage (about 60 times its 
nominal memory
consumption). I would therefore like to ask whether there are 
already any plans for Java 10

to improve this situation?

Michael

Re: JavaFX graphics performance

[Chien Yang]

BTW, it is a bug that we are unaware of if you are seeing a 60X nominal 
memory consumption in your program.  Please file a JIRA with a test 
program and we will investigate it.


Thanks,

- Chien


On 4/10/2017 1:08 PM, Kevin Rushforth wrote:
We are planning some performance improvements in JDK 10, mostly in the 
areas of CSS and layout. If you have specific concerns in other areas 
we could look into them. Having a specific test case that shows a 
performance problem would be a good start.


-- Kevin


Michael Paus wrote:

Hi,

more and more people ask me why I am still doing GUI development in 
JavaFX instead
of following the  mainstream and use some web technology. One of the 
arguments
I could use in the past was performance but nowadays this does not 
seem to be such
a valid argument anymore. Web technologies are catching up quickly 
and JavaFX currently
has not much to offer here. Actually the general drawing performance 
is very bad compared
to what is in principle possible with a modern GPU. I even tried to 
use a TriangleMesh
to better exploit the graphics hardware but this approach is also 
limited by the fact that
a TrinangleMesh has an excessive memory usage (about 60 times its 
nominal memory
consumption). I would therefore like to ask whether there are already 
any plans for Java 10

to improve this situation?

Michael

[9] Code Review Request 8163385: Fix doclint errors and warnings in javafx.controls module

[Chien Yang]

Hi Jonathan and Kevin,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8163385

Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8163385/webrev.00/

Thanks,

- Chien

Re: [9] Code Review Request For 8163384: Fix doclint errors and warnings in javafx.graphics module

[Chien Yang]

Hi Jonathan,

Thanks for the valuable recommendations! I will make corrections based 
on this list. Please send me additional recommendations if you have more.


Thanks,
- Chien

On 2/28/17, 4:00 PM, Jonathan Gibbons wrote:

Chien,

It's good to see these issues being addressed. I've browsed maybe a 
third of the files, enough to see some common patterns that you might 
want to address. The most prevalent comment is issues with 
combinations of , {@code}, {@literal}, and entities, but I'm also 
seeing empty descriptions for methods, and empty alt text for images 
as well.


Providing empty alt="" for images is not really living up to the 
intent of the Accessibility Guidelines.

See https://www.w3.org/TR/WCAG20-TECHS/H37.html

There are some places, e.g.
http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/modules/javafx.graphics/src/main/java/javafx/concurrent/Service.java.sdiff.html 

where it might be more convenient to use a multi-line {@code } block, 
rather than use entities for awkward characters in the code.
In general, the use of ... should be 
considered an anti-pattern.  Consider using {@code ... } 
instead.


http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/modules/javafx.graphics/src/main/java/javafx/css/CssMetaData.java.sdiff.html 


line 59, use {@code

http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/modules/javafx.graphics/src/main/java/javafx/css/Size.java.sdiff.html 


Missing method comments. e.g. line 45, 53

http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java.sdiff.html 


line 66, Don't use entities inside {@code}

http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java.sdiff.html 


line 186: Weird mix of  and {@literal}.  Just use {@code}.

http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java.sdiff.html 


More methods with no descriptions

http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/modules/javafx.graphics/src/main/java/javafx/css/StyleablePropertyFactory.java.sdiff.html 


Use {@code

http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/modules/javafx.graphics/src/main/java/javafx/css/StyleablePropertyFactory.java.sdiff.html 


line 550: {@code} is more idiomatic than {@literal

http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/modules/javafx.graphics/src/main/java/javafx/css/StyleablePropertyFactory.java.sdiff.html 

There are many instances in the file where a pattern like 
"CssMetaDataS, Enum" might be better written with an enclosing 
{@code } or {@literal.


-- Jon

On 02/28/2017 03:00 PM, Chien Yang wrote:

Hi all,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8163384

Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/


Thanks,

- Chien

[9] Code Review Request For 8163384: Fix doclint errors and warnings in javafx.graphics module

[Chien Yang]

Hi all,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8163384

Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8163384/webrev.00/


Thanks,

- Chien

[9] Code Review Request For 8173796: Overriden method, requestLayout(), by subclass of Parent didn't get call when process layout

[Chien Yang]

Hi Kevin and Jonathan,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8173796

Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8173796/webrev.00/

Thanks,

- Chien

Code Review Request 8172364: Ensemble8 Canvas Fireworks jitters while animating

[Chien Yang]

Hi Kevin,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8172364
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8172364/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8171852: JavaFX Stage flickers on resize on Windows platforms

[Chien Yang]

Hi Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8171852
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8171852/webrev.00/

Thanks,
- Chien

8170624: [Mac] HostServices.showDocument() throws IllegalAccessException

[Chien Yang]

Hi Kevin,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8170624
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8170624/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8170500: Interminate ProgressIndicator no longer animates if scene is set on stage before content is added

[Chien Yang]

Hi Jonathan,

Please review the proposed fix and investigation in the JIRA.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8170500

Thanks,
- Chien

[9] Code Review Request For 8170421: Ensemble8 black flash at startup on b145+

[Chien Yang]

Jim or Kevin,

Please review this simple fix posted in the JIRA:

https://bugs.openjdk.java.net/browse/JDK-8170421

Thanks,
- Chien

[9] Code Review Request For 8166932: Fix @Deprecated annotations for deprecated JavaFX methods

[Chien Yang]

Hi Jim and Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8166932
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8166932/webrev.00/

Thanks,
- Chien

Re: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background

[Chien Yang]

Yes, we decide to punt on ImagePattern as there isn't a trivial way to 
find a reasonable background color for it.


- Chien

On 11/10/16, 10:22 AM, Jim Graham wrote:

I guess we'll punt on ImagePattern?

Other than that the fix looks fine...

...jim

On 11/9/16 5:35 PM, Chien Yang wrote:

Hi Jim and Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8088179
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/

Thanks,
- Chien

Re: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background

[Chien Yang]

I have tested with different StageStyle and Fill combinations, and all 
seems to work well with the proposed fix. No more white flashing if the 
Scene.fill is set with a color(with/without alpha).


- Chien

On 11/10/16, 4:58 AM, Kevin Rushforth wrote:

Hi Tom,

This is a good question, and will needs to be checked. If it is a 
problem, then one possibility would be to modify the fix to skip the 
call to setBackground if StageStyle == TRANSPARENT.


-- Kevin


Tom Schindl wrote:

Hi,

Might be dumb questions but

Did you try that this doesn't interfere with stages who have been created with 
StageStyle.TRANSPARENT?

What happens if i set the Scene.fill to an rgba value? Doesn't this lead to a 
different color than what you get today where the background  stage background 
is always white?

Tom

Von meinem iPhone gesendet

   

Am 10.11.2016 um 02:35 schrieb Chien Yang<chien.y...@oracle.com>:

Hi Jim and Kevin,

Please review the proposed fix:

JIRA:https://bugs.openjdk.java.net/browse/JDK-8088179
Webrev:http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/

Thanks,
- Chien
 


   

[9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background

[Chien Yang]

Hi Jim and Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8088179
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8168616: -Xcheck:jni indicates there are missing exception checks in Font

[Chien Yang]

Hi Phil,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8168616
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8168616/webrev.00/

Thanks,
- Chien

[8u] Code Review Request For 8168821: Cleanup whitespace after fix for JDK-8156078

[Chien Yang]

Hi Kevin,

Please review this one line cleanup fix (diff in the JIRA):

JIRA: https://bugs.openjdk.java.net/browse/JDK-8168821

Thanks,
- Chien

[9] Code Review Request For 8166470: -Xcheck:jni indicates there are missing exception checks in Glass

[Chien Yang]

Hi Kevin,

Please the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8166470
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8166470/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8130675:Document that setting scene on stage changes stage size unless explicitly set

[Chien Yang]

Hi Kevin,

Please review this proposed doc fix:

JIRA:https://bugs.openjdk.java.net/browse/JDK-8130675
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8130675/webrev.00/

Thanks,
- Chien

Re: Memory leaks on Linux with hardware renderer

[Chien Yang]

Based on my recollection, this oddity (2 contexts) is because we use 
CALayer on Mac. We have tested in early prototype, when we did the 
switch from JOGL to native GL, Prism implementation on Linux works fine 
with a single GL context.


- Chien

On 8/11/2016 2:08 PM, Jim Graham wrote:
It looks like we create a dummy drawable for the context and install 
it when we are done with the frame.  This appeared in rev 
bbb8d2772b37, but it looks like that revision involved removing the 
unnecessary RenderingContext class, so we may have been doing 
something similar via the RenderingContext class and the code was 
merely moved into SwapChain when the other class was deleted.  Further 
investigation would be needed, but my mercurial rev/diffing skills are 
pretty primitive.  Anyone care to dig a little on this and figure out 
if there is a reason for us to unset the drawable at the end of a frame?


In either case, if we had 2 windows open, and that will happen if 
there is a simple popup on a choice box or a menu item I think 
unfortunately, then we'd still have the problem so whether or not it 
happens with a single window with no popup items in it, it still looks 
like we could potentially trigger this in common cases anyway.  We 
should track the fix to GLX and make sure we document required patches 
if there is a fix...


...jim

On 8/11/16 6:13 AM, Itai wrote:

I'm sorry to see the issue could still not be reproduced on any OpenJFX
team members.

Meanwhile, I have noticed a user on reddit (JavaFX sub-reddit) had 
the same

issue:
https://www.reddit.com/r/JavaFX/comments/4nr2ln/memory_leak_when_calling_imageviewsettranslatex/ 


.
However, they have managed to profile it (VisualVM has a bug making it
nearly impossible to CPU profile JavaFX programs), and found out a 
lot of

time is taken by `com.sun.prism.es2.X11GLContext.makeCurrent`.

Taking this lead, I have found this:
http://www.gamedev.net/topic/679705-glxmakecurrent-slowly-leaks-memory/

Sadly I don't know enough about OpenGL to understand most of it, but it
seems to me like it's the same issue, so possibly it's not a Java 
issue at
all. However, maybe it can be avoided? In this linked post it is 
mentioned

that the leak only happens when having two windows, but in JavaFX this
always happens, so maybe there is a redundant call to `makeCurrent`?

Hope this helps to find the source of the problem, and if it's indeed
outside of Java/JavaFX scope - report it to the relevant project.

On Thu, Jul 21, 2016 at 6:12 PM, Kevin Rushforth 
:

I'll add a comment to that effect (although our incident triage 
team is

good about spotting such duplicates).

-- Kevin


Itai wrote:

Thank you. Having gotten no reply, and seeing the bug report was 
closed
and with not means of commenting in the bug report system, I have 
since
(about an hour ago) filed a more detailed report (JI-9042009). I 
believe
they could be safely merged, but the second one does contain some 
more

info.
On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com > 
wrote:


JI-9041860 has now been transferred to the JDK project as:

https://bugs.openjdk.java.net/browse/JDK-8161911

Our support engineer was not able to reproduce the problem, so
closed it as such. Based on the additional information you
provided, I have reopened the bug and will ask someone on our 
team

with a physical Linux setup to try to reproduce it.

To answer your question, we are not aware of any such leaks.

-- Kevin



Itai wrote:

I'm experiencing multiple memory leaks with JavaFX on Linux,
to the point
where I'm not sure which bug to report, as it seems like a
systematic
issue.

The memory leak seems to be completely absent when using the
software
renderer (-Dprism.order=sw), and does not seem to happen on
Windows
(presumably not on Mac either, although I have no Mac to test
it).

Test cases include:

1. Use ProgressIndicator with progress set to Indeterminate -
with default
(HW) renderer memory consumption quickly rises, climbing to
8GB and more if
not killed. With software renderer memory usage is 
reasonable.

2. Using Scene Builder - after a few minutes with Scene
Builder it quickly
gobbles up all system memory - again, problem seems to go 
away

if using
software renderer. This test is less 

[9] Code Review Request For 8163383: Fix doclint errors and warnings in javafx.base module

[Chien Yang]

Hi Kevin,

Please review this proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8163383
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8163383/webrev.00/

Thanks,
- Chien

Re: [8udev (backport)] Code Review Request For 8163302: Stage alwaysOnTop property not reset to false if permission is denied

[Chien Yang]

Thanks for the reminder. I have just resent it with the main Bug ID and 
updated the JIRA.


- Chien


On 08/05/16 13:47, Kevin Rushforth wrote:
This review request is using the wrong Bug ID. We never use the 
backport ID for anything (ever), so please resend with the correct 
subject line, which should have the Bug ID of the main bug: 8156078


Thanks.

-- Kevin


Chien Yang wrote:

Hi Kevin,

Please review the proposed backport:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8163302

Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8163302/webrev.00/

Thanks,

- Chien

[8udev (backport)] Code Review Request For 8156078: Stage alwaysOnTop property not reset to false if permission is denied

[Chien Yang]

Hi Kevin,

Please review the proposed backport:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8156078

Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8156078/backport.00/

Thanks,

- Chien

[8udev (backport)] Code Review Request For 8163302: Stage alwaysOnTop property not reset to false if permission is denied

[Chien Yang]

Hi Kevin,

Please review the proposed backport:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8163302

Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8163302/webrev.00/

Thanks,

- Chien

Code Review Request For 8156078: Stage alwaysOnTop property not reset to false if permission is denied

[Chien Yang]

Hi Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8156078
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8156078/webrev.00/

Thanks,
- Chien

Code Review Request For 8162883: ESC button fails to cancel Dialog

[Chien Yang]

Hi Jonathan and Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8162883
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8162883/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8154148: JavaFX crashes on startup when run on Mac in VMWare

[Chien Yang]

Hi Kevin and Dave,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8154148
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8154148/webrev.00/

Thanks,
- Chien

Re: CFV: New OpenJFX Committer: Ankit Srivastava

[Chien Yang]

Vote: YES

On 7/19/16 6:37 AM, David Hill wrote:


I hereby nominate Ankit Srivastava to OpenJFX Committer.

Ankit Srivastava is part of the JavaFX team focusing on Web.

A list of Ankit's commits and reviews is available by the following links

http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivast...@oracle.com 


http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava

Votes are due by August 3th, 2016.

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

[9] Code Review Request For 8148721: Memory leak caused by scroll gesture

[Chien Yang]

Hi Jonathan,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8148721
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8148721/webrev.00/

Thanks,
- Chien

Re: ProgressIndicator indeterminate transition bugs

[Chien Yang]

Hi Diego,

As far as I'm aware these fixes aren't candidates for back port to 8. We 
will have to evaluate them if you can provide us a good justification 
for doing so.


Thanks,
- Chien

On 7/13/16, 4:40 AM, Cirujano Cuesta, Diego wrote:

Hi Chien, Jonathan,

I saw treeNode and the progress indicator issues are all done as talked, GREAT!

Are they planned to be included in Java 8?

Cheers,
Diego

-Original Message-
From: Chien Yang [mailto:chien.y...@oracle.com]
Sent: Dienstag, 8. März 2016 20:41
To: Cirujano Cuesta, Diego<diego.cirujano-cue...@zeiss.com>; 
jonathan.gi...@oracle.com; openjfx-dev@openjdk.java.net
Subject: Re: ProgressIndicator indeterminate transition bugs

You may track the progress of this work with this JIRA for now. We are still 
investigating the scope and impact of this work. We may decide to create a new 
JIRA and resolve this as a duplicate if we decide to go with a better naming.

https://bugs.openjdk.java.net/browse/JDK-8090322

- Chien


On 03/08/16 01:58, Cirujano Cuesta, Diego wrote:

Great! In that case forget the patch I made, it doesn’t make sense until the 
treeVisible property is implemented. Is there any jira ticket that I could 
follow?

Thank you Jonathan.

From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Dienstag, 8. März 2016 10:01
To: Cirujano Cuesta, Diego; openjfx-dev@openjdk.java.net
Subject: RE: ProgressIndicator indeterminate transition bugs

The plan is that a new public API will be developed that matches the 
expectations, whilst retaining the existing treeVisible semantics in that API. 
Chien will be looking into this in the coming weeks. At that point we can 
properly fix these issues.

-- Jonathan
Sent from a touch device. Please excuse my brevity.
On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, 
Diego"<diego.cirujano-cue...@zeiss.com<mailto:diego.cirujano-cue...@zeiss.com>>  
wrote:

Hi all,

As I understood in the comments(JDK-8094829, JDK-8094078), treeVisible is 
buggy. Is it still buggy? If yes, is there intention to fix the treeVisible 
behavior? In case of fixing this it could be used to fix this issue. If I am 
not wrong, treeVisible is still used by Node, SwingNode and MediaView.

@Jonathan As you mentioned in JDK-8094829 "having a correctly working treeVisible 
property would be immensely useful." And I am completely agree and I would like to 
add that having in the public API would be even better :-).

Thank you,
Diego

-Original Message-
From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Sonntag, 28. Februar 2016 22:54
To: Cirujano Cuesta, Diego;
openjfx-dev@openjdk.java.net<mailto:openjfx-dev@openjdk.java.net>
Subject: Re: ProgressIndicator indeterminate transition bugs

If you can, are you able to file bug reports for these?

-- Jonathan

On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote:

   Hi all,

   We found two important bugs in ProgressIndicator that are related with the 
following tickets:

   https://bugs.openjdk.java.net/browse/JDK-8094829
   https://bugs.openjdk.java.net/browse/JDK-8094078

   Now are quite critical because in a 4K monitor may cause 
OutOfMemoryException.

   Using the following example:
   "
   public class JFXMain extends Application{

@Override
public void start(Stage primaryStage) throws Exception {
HBox root = new HBox();
ToggleButton toggleButton = new ToggleButton();
ProgressIndicator progressIndicator = new 
ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS);
StackPane stackPane = new StackPane(progressIndicator);
stackPane.visibleProperty().bind(toggleButton.selectedProperty());
root.getChildren().addAll(toggleButton, stackPane);
primaryStage.setScene(new Scene(root));
primaryStage.show();
}
   }
   "

   ** First bug **

   Starting the Progress Indicator with indeterminate progress will
   trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599
   start the animation even is not shown already:
   indeterminateTransition.playFromStart();

   ** Second bug **

   With the last commits in ProgressIndicator, as commented in JDK-8094829, the 
listeners do not care about the real visibility of the node(before it was used 
impl_treeVisibleProperty()). The consequence is that the ProgressIndicator in 
the example won´t be stopped.

   I can imagine that impl_treeVisibleProperty() should not be used and Jonathan G. said: 
" but I can't reliably fix that without an API such as what I expect the treeVisible 
API should do." But we did not find such alternative property.

   The solution we though is the usage of internal tree visible property like 
this:

   1. Modify method:
   "
protected void updateAnimation(boolean isTreeVisible) { "
   2. Remove current calls to method in
   "
@Override protected void handleCont

[9] Code Review Request For 8088846: PopupWindow does not disappear when associated Control is not visible.

[Chien Yang]

Hi Dave and Jonathan,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8088846
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088846/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8090322: Need new tree visible property in Node that consider Scene and Stage visibility

[Chien Yang]

Hi Jonathan,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8090322

Thanks,
- Chien

[9] Code Review Request For 8158006: Improve javadoc for abstract classes that application should not directly extend

[Chien Yang]

Hi Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8158006
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8158006/webrev.00/

Thanks,
- Chien

[9] Review Request For 8158948: SceneBuilder needs public access to CSS styling support from JavaFX that is no longer available

[Chien Yang]

Hi Kevin,

Please review this proposed fix as we have discussed earlier.

Webrev: https://bugs.openjdk.java.net/browse/JDK-8158948

Thanks,
- Chien

[9] Code Review Request For 8159005: SceneBuilder needs public access to FXMLLoader setStaticLoad support from JavaFX that is no longer available

[Chien Yang]

Hi Kevin,

Please review this proposed fix as we have discussed earlier.

Webrev: https://bugs.openjdk.java.net/browse/JDK-8159005

Thanks,
- Chien

[9] Code Review Request For 8158004: Node, Shape and Shape3D need meaningful runtime exception message when application directly extends these classes

[Chien Yang]

Hi Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8158004
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8158004/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8157500: Create unit tests for new public methods in GridPane

[Chien Yang]

Hi Kevin,

Please review the proposed unit test:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8157500
Webev: http://cr.openjdk.java.net/~ckyang/JDK-8157500/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8159383: Mouse hover on Webview scroll bar leads to NPE in ScrollBarThemeImpl.hitTest

[Chien Yang]

Hi Kevin,

Please review the simple bug fix as we have investigated:

https://bugs.openjdk.java.net/browse/JDK-8159383

Thanks,
- Chien

[9] Code Review Request For 8159021: Redo layout bounds tests in GroupTest

[Chien Yang]

Kevin and Vadim,

Please review this simple fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8159021
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8159021/webrev.00/

Thanks,
- Chien

[9] Code Review For 8144585: Encapsulate JavaFX impl_* implementation methods

[Chien Yang]

Hi all,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8144585
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8144585/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8158659: Encapsulate impl_ methods in Node and its subclasses

[Chien Yang]

Hi all,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8158659
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8158659/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8157900: Encapsulate JavaFX impl_* implementation methods in Node (peer and dirty)

[Chien Yang]

Hi Kevin, Jonathon and Vadim,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8157900
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8157900/webrev.00/

PS: This is a huge webrev and touches many components. I believe most 
component owners would want to do a quick cursory review except those 
that I tagged.


Thanks,
- Chien

[9] Code Review Request For 8091874: Need API in GridPane to get row count, column count, and cell bounds

[Chien Yang]

Hi Kevin,

Please review the suggested fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8091874
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8091874/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8157350: Encapsulate impl_ methods in Shapes related classes

[Chien Yang]

Hi Kevin,

Please review the proposed fix as we have discussed.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8157350
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8157350/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8157295: Encapsulate impl_ methods in Scene and KeyValue classes

[Chien Yang]

Hi Jonathan and Kevin,

Please review the proposed fix:

Webrev: https://bugs.openjdk.java.net/browse/JDK-8157295
JIRA: http://cr.openjdk.java.net/~ckyang/JDK-8157295/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8155998: Encapsulate JavaFX impl_* implementation methods in stage package

[Chien Yang]

Hi Jonathan and Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8155998
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8155998/webrev.00/

Thanks,
- Chien

Re: [9] Code Review Request For 8155762: Encapsulate JavaFX impl_* implementation methods in transform package

[Chien Yang]

Hi Jim,

Just quick reply to some of your questions.

1) TransformUtils.java: My initial take was to delete this class but 
after chatting with Kevin, we decided to keep it in the interest of 
limiting the scope of this change. Moving those methods will touch much 
more files. We have about 2 weeks to finish the whole encapsulation of 
all JavaFX impl_* methods.


2) TransformHelper.java: This is the class naming pattern we use to 
encapsulate all accessor interface classes. Also only less than half of 
TransformUtils.java was moved into TransformHelper.java. A big portion, 
ImmutableTransform, has to move into Transform.java.


3) ImmutableTransform: Yes, this is unclean in my opinion when I was 
reading it. However this is design/implementation cleanup work is out of 
the scope of this JIRA. I would suggest we file a separate JIRA for it 
and since you are the code owner of Transform you can have it too! :-)


Lastly, JavaFX code review is done in the JIRA so that discussion of 
that issue will stay in that JIRA.


Thanks,
- Chien


On 5/6/16, 8:10 PM, Jim Graham wrote:
TransformUtils.java - can't this class be deleted now since all it 
exists to do is to forward to TransformHelper?


Alternatively, why create TransformHelper in the first place when it 
is 90% just a copy of what TransformUtils used to be (ignoring the 
inner class that got moved to Transform) with an accessor interface 
thrown in for good measure?  Just to change the name?  That could be 
done by using a source rename rather than gutting the old file and 
creating the new one from scratch...?  And we don't need both of them, 
do we?


Transform.java, line 2172 & 2187 - is there a reason to forward to the 
factory rather than just instantiating directly?


Transform.java, line 2177 & 2189 - I suppose the reason that the 
arguments are not declared to be Immutable in the first place is that 
some of these are used from other packages that have no visibility to 
the Immutable.  I was going to say that we should protect against them 
not being Immutables, but I guess these uses are hidden so it doesn't 
really affect anything by doing the cast - but it seems sloppy when 
looking at the code without looking everywhere to see how they are 
used (which I suppose is short-hand for "someone in the future might 
mess up because it's not obvious that these can't deal with any other 
type").


TransformHelper.java, line 108 & 112 - [formatting] perhaps move the 
m[xyz],tx to the next line for consistency between the two (like 68 & 
76)?


The implementation of ImmutableTransform copies a fair bit of 
internals from Affine, but it could just wrap an Affine and save 
itself all of that work.  Arguably, we could make it a super-class of 
Affine and then it would own all of that code and Affine would 
subclass only for the modification methods, but we'd either have to 
expose it as a public class or have an unexplained inaccessible 
superclass on Affine...? (Also, it's not clear if public methods on a 
non-public superclass of Affine would be visible through Affine so 
Affine would either have to have forwarding methods or we'd have to 
make the super class public).


On the other hand, what would be wrong with having a public BaseAffine 
that was Affine without its modification methods, and having Affine 
subclass it?  It would be effectively Immutable, but using the word 
Immutable in its name might sound like a promise which would be 
violated by its subclass - better to leave that property implied by 
its lack of mutating methods and possibly mentioning the intent in the 
javadoc...


...jim

On 5/3/2016 11:24 PM, Chien Yang wrote:

Kevin and Jim,

Please review the proposed fix:

Webrev: https://bugs.openjdk.java.net/browse/JDK-8155762
JIRA: http://cr.openjdk.java.net/~ckyang/JDK-8155762/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8156170: Clean up Stage and StageHelper

[Chien Yang]

Hi Kevin and Jonathan,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8156170
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8156170/webrev.00/

- Chien

[9] Code Review Request For 8155762: Encapsulate JavaFX impl_* implementation methods in transform package

[Chien Yang]

Kevin and Jim,

Please review the proposed fix:

Webrev: https://bugs.openjdk.java.net/browse/JDK-8155762
JIRA: http://cr.openjdk.java.net/~ckyang/JDK-8155762/webrev.00/

Thanks,
- Chien

Re: Code Review Request For 8155757: Encapsulate impl_ methods in animation, canvas, image, input, layout, paint, and text packages

[Chien Yang]

Hi Jim,

Thanks for sharing this information and your thought. I'm not sure is 
this saving worth violating the principle of minimizing scope in code. I 
guess you did bring up a good point let me think over it and discuss 
with Kevin tomorrow.


- Chien

On 4/29/16, 4:04 PM, Jim Graham wrote:
One comment on the implementation.  For the methods used by an 
accessor inner class, if you make them private in the outer class then 
that inner class will need a hidden accessor method to be added in the 
bytecodes.  If you make them package-private then they can access the 
method directly.


Basically, an inner class is really "just another class in the 
package, but with a special name" and actually have no access to 
private methods in their outer classes at all, but javac works around 
this by adding a hidden method that has more open access and using that.


An example is Image.getPlatformImage() - you turned it from "public 
and impl_" into private.  Why not just leave it 
package-private/default access?


For example, compiling this class:

public class InnerPrivateTest {
private void foo() {}
public class InnerClass {
public void bar() { foo(); }
}
}

yields this byte code for InnerPrivateTest.class:

public class InnerPrivateTest {
  public InnerPrivateTest();
Code:
   0: aload_0
   1: invokespecial #2  // Method 
java/lang/Object."":()V

   4: return

  private void foo();
Code:
   0: return

  static void access$000(InnerPrivateTest);
Code:
   0: aload_0
   1: invokespecial #1  // Method foo:()V
   4: return
}

and this for the InnerClass:

public class InnerPrivateTest$InnerClass {
  final InnerPrivateTest this$0;

  public InnerPrivateTest$InnerClass(InnerPrivateTest);
Code:
   0: aload_0
   1: aload_1
   2: putfield  #1  // Field 
this$0:LInnerPrivateTest;

   5: aload_0
   6: invokespecial #2  // Method 
java/lang/Object."":()V

   9: return

  public void bar();
Code:
   0: aload_0
   1: getfield  #1  // Field 
this$0:LInnerPrivateTest;
   4: invokestatic  #3  // Method 
InnerPrivateTest.access$000:(LInnerPrivateTest;)V

   7: return
}

Changing the access on foo() to default (package private), yields this 
byte code:


public class InnerPackageTest {
  public InnerPackageTest();
Code:
   0: aload_0
   1: invokespecial #1  // Method 
java/lang/Object."":()V

   4: return

  void foo();
Code:
   0: return
}

public class InnerPackageTest$InnerClass {
  final InnerPackageTest this$0;

  public InnerPackageTest$InnerClass(InnerPackageTest);
Code:
   0: aload_0
   1: aload_1
   2: putfield  #1  // Field 
this$0:LInnerPackageTest;

   5: aload_0
   6: invokespecial #2  // Method 
java/lang/Object."":()V

   9: return

  public void bar();
Code:
   0: aload_0
   1: getfield  #1  // Field 
this$0:LInnerPackageTest;
   4: invokevirtual #3  // Method 
InnerPackageTest.foo:()V

   7: return
}

...jim

On 4/29/16 11:50 AM, Chien Yang wrote:

Hi Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8155757
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8155757/webrev.00/

Thanks,
- Chien

Code Review Request For 8155757: Encapsulate impl_ methods in animation, canvas, image, input, layout, paint, and text packages

[Chien Yang]

Hi Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8155757
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8155757/webrev.00/

Thanks,
- Chien

[9] Code Review Request For 8155053: Encapsulate impl_ methods in Effect and on the setting of TraversalEngine

[Chien Yang]

Hi Kevin,

Please review the purposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8155053
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8155053/webrev.00/

Thanks,
- Chien

Re: Jvm crash: es2 pipeline crashs jvm on macosx vm

[Chien Yang]

Hi Ali,

Context management is tightly couple between Glass and Prism. The fix 
will likely touches both places.


- Chien

On 4/16/16, 11:05 AM, Ali Ebrahimi wrote:

Hi,

On Sat, Apr 16, 2016 at 10:11 PM, Chien Yang <chien.y...@oracle.com 
<mailto:chien.y...@oracle.com>> wrote:


Hi Ali,

Thanks! I believe we have enough information from what you have
already shared here and in JI-9035391. You can track the progress
of this issue with JI-9035391 when it is transferred to JBS.

But JI-9035391 is relate to Prism software pipeline error that happens 
in glass native code. I think these are separate issues.


--

Best Regards,
Ali Ebrahimi

Re: Jvm crash: es2 pipeline crashs jvm on macosx vm

[Chien Yang]

Hi Ali,

Thanks! I believe we have enough information from what you have already 
shared here and in JI-9035391. You can track the progress of this issue 
with JI-9035391 when it is transferred to JBS.


- Chien

On 4/14/16, 10:58 PM, Ali Ebrahimi wrote:

Hi Chien,

I googled and found there are already similar crash reports in javafx8 
timeframe for this problem:

https://bugs.openjdk.java.net/browse/JDK-8096072
https://bugs.openjdk.java.net/browse/JDK-8092559

Since I can't comment on this issues on jira to add my patch, should I 
report new bug report for FX9?

Note: This patch also works for javafx8.

On Fri, Apr 15, 2016 at 2:07 AM, Chien Yang <chien.y...@oracle.com 
<mailto:chien.y...@oracle.com>> wrote:


Thanks reporting your finding and suggestion. Do you mind filing a
bug report?  Please include the steps and your system
configuration that we may reproduce  the crash on our end.

https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report

Thanks,
- Chien


On 4/14/2016 12:16 PM, Ali Ebrahimi wrote:

When running javafx apps with es2 pipeline on macosx vm I get
jvm crash.

The following patch fixes this issue and I can run Ensemple8
application
with es2 pipeline successfully.
The good news is that 3D support is works fine.

diff -r 3f15f2e59063

modules/graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m
---

a/modules/graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m
Wed
Apr 13 12:36:43 2016 -0700
+++

b/modules/graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m
Thu
Apr 14 23:45:18 2016 +0430
@@ -68,7 +68,12 @@
  NSOpenGLPixelFormat *fmt = [[NSOpenGLPixelFormat alloc]
initWithAttributes : attribs];
  if (fmt == nil) {
  // should we fallback to defaults or not?
-fmt = [NSOpenGLView defaultPixelFormat];
+//fmt = [NSOpenGLView defaultPixelFormat];
+NSOpenGLPixelFormatAttribute attributes[] = {
+NSOpenGLPFAAllowOfflineRenderers,
+0
+};
+fmt = [[NSOpenGLPixelFormat alloc] initWithAttributes :
attributes];
  }

  [pool release];





--

Best Regards,
Ali Ebrahimi

[9] Code Review Request: 8144556: Add support to allow user specified rendering order

[Chien Yang]

Please review the proposed specification and implementation.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8144556
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8144556/webrev.00/

- Chien

Re: JavaFX Application Heat up MacBook Pro

[Chien Yang]

BTW, I did a 15 min run of Ensemble8 testing a series of programs on my 
MBP 15 this morning. The machine remains cool and its fan remains off. 
Can you provide the steps on how you heated up your MBP running 
Ensemble8? Did you have other programs running?


Thanks,
- Chien

On 3/27/16, 11:37 PM, Chien Yang wrote:
You are correct. MBP 13 only has an integrated GPU and those 2 fixes 
mentioned earlier don't apply to your case.


- Chien

On 3/25/16, 3:15 PM, Tai Hu wrote:

I have a MacBook Pro 13 inch (2014 model). If I remembered correctly, it
only has an integrated GPU. There is no discreet GPU

Thanks,

Tai

On Friday, March 25, 2016, Phil Race<philip.r...@oracle.com>  wrote:



See https://developer.apple.com/library/mac/qa/qa1734/_index.html
It is mentioned in (one of) the bugs you can get to if you follow 
the JBS

bug trail

-phil.

On 3/25/2016 2:48 PM, Tai Hu wrote:


Thanks for the info. What entry should I put into info.plist?

Thanks

On Friday, March 25, 2016, Kevin Rushforth<kevin.rushfo...@oracle.com>
wrote:

Yes, 8u77 has the FX fix for this issue:

https://bugs.openjdk.java.net/browse/JDK-8132775

However, due to the way Apple chose to enable this, you will need to
package your application with the appropriate entry in the Info.plist
file.

The equivalent AWT fix --
https://bugs.openjdk.java.net/browse/JDK-8041900
-- is fixed in 8u92 which is scheduled to be released next month.

-- Kevin


Tai Hu wrote:

I am on the latest 8u77.

On Friday, March 25, 2016, Scott Palmer<swpal...@gmail.com>  wrote:



What version of JavaFX are you running?
There is a known issue, where JavaFX (and AWT/Swing) trigger 
activation

of
the discreet GPU.  I believe for FX the issue has been resolved 
in the
latest version, but the equivalent AWT fix hasn't made it to a 
released

version yet.

Scott



On Mar 25, 2016, at 4:12 PM, Tai Hu<tai...@veroanalytics.com


<javascript:;>>  wrote:


My JavaFX application runs fine on a Windows box with less than 
10% of


CPU usage. However, if I run the same application on a MacBook 
Pro 13

inch
(Laptop monitor, no external monitor). About 30 seconds after I
launched
application, MacBook cooling fan will kick in and running high, 
just a

few
minutes later, laptop is too hot to put directly on your lap. 
Actually

I
tried Ensemble app, which has exactly same issue. Few minutes after
launch,
fan kicks in and laptop become hot. I put my application under 
VisualVM

and
also checked Mac Activity Monitor, based on the number both of them
show
the CPU usage is not extremely high and average out about 25% and
sometimes
spike to 40%. But entire machine heats up. Almost all of our Mac
clients
complained about this issue to us. Does anyone could shield some 
light

on
this issue?


Thanks,

Tai

Re: JavaFX Application Heat up MacBook Pro

[Chien Yang]

You are correct. MBP 13 only has an integrated GPU and those 2 fixes 
mentioned earlier don't apply to your case.


- Chien

On 3/25/16, 3:15 PM, Tai Hu wrote:

I have a MacBook Pro 13 inch (2014 model). If I remembered correctly, it
only has an integrated GPU. There is no discreet GPU

Thanks,

Tai

On Friday, March 25, 2016, Phil Race  wrote:



See https://developer.apple.com/library/mac/qa/qa1734/_index.html
It is mentioned in (one of) the bugs you can get to if you follow the JBS
bug trail

-phil.

On 3/25/2016 2:48 PM, Tai Hu wrote:


Thanks for the info. What entry should I put into info.plist?

Thanks

On Friday, March 25, 2016, Kevin Rushforth
wrote:

Yes, 8u77 has the FX fix for this issue:

https://bugs.openjdk.java.net/browse/JDK-8132775

However, due to the way Apple chose to enable this, you will need to
package your application with the appropriate entry in the Info.plist
file.

The equivalent AWT fix --
https://bugs.openjdk.java.net/browse/JDK-8041900
-- is fixed in 8u92 which is scheduled to be released next month.

-- Kevin


Tai Hu wrote:

I am on the latest 8u77.

On Friday, March 25, 2016, Scott Palmer  wrote:



What version of JavaFX are you running?

There is a known issue, where JavaFX (and AWT/Swing) trigger activation
of
the discreet GPU.  I believe for FX the issue has been resolved in the
latest version, but the equivalent AWT fix hasn't made it to a released
version yet.

Scott



On Mar 25, 2016, at 4:12 PM, Tai Hu>  wrote:


My JavaFX application runs fine on a Windows box with less than 10% of


CPU usage. However, if I run the same application on a MacBook Pro 13

inch
(Laptop monitor, no external monitor). About 30 seconds after I
launched
application, MacBook cooling fan will kick in and running high, just a
few
minutes later, laptop is too hot to put directly on your lap. Actually
I
tried Ensemble app, which has exactly same issue. Few minutes after
launch,
fan kicks in and laptop become hot. I put my application under VisualVM
and
also checked Mac Activity Monitor, based on the number both of them
show
the CPU usage is not extremely high and average out about 25% and
sometimes
spike to 40%. But entire machine heats up. Almost all of our Mac
clients
complained about this issue to us. Does anyone could shield some light
on
this issue?


Thanks,

Tai

Re: ProgressIndicator indeterminate transition bugs

[Chien Yang]

You may track the progress of this work with this JIRA for now. We are 
still investigating the scope and impact of this work. We may decide to 
create a new JIRA and resolve this as a duplicate if we decide to go 
with a better naming.


https://bugs.openjdk.java.net/browse/JDK-8090322

- Chien


On 03/08/16 01:58, Cirujano Cuesta, Diego wrote:

Great! In that case forget the patch I made, it doesn’t make sense until the 
treeVisible property is implemented. Is there any jira ticket that I could 
follow?

Thank you Jonathan.

From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Dienstag, 8. März 2016 10:01
To: Cirujano Cuesta, Diego; openjfx-dev@openjdk.java.net
Subject: RE: ProgressIndicator indeterminate transition bugs

The plan is that a new public API will be developed that matches the 
expectations, whilst retaining the existing treeVisible semantics in that API. 
Chien will be looking into this in the coming weeks. At that point we can 
properly fix these issues.

-- Jonathan
Sent from a touch device. Please excuse my brevity.
On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, Diego" 
> wrote:

Hi all,

As I understood in the comments(JDK-8094829, JDK-8094078), treeVisible is 
buggy. Is it still buggy? If yes, is there intention to fix the treeVisible 
behavior? In case of fixing this it could be used to fix this issue. If I am 
not wrong, treeVisible is still used by Node, SwingNode and MediaView.

@Jonathan As you mentioned in JDK-8094829 "having a correctly working treeVisible 
property would be immensely useful." And I am completely agree and I would like to 
add that having in the public API would be even better :-).

Thank you,
Diego

-Original Message-
From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Sonntag, 28. Februar 2016 22:54
To: Cirujano Cuesta, Diego; 
openjfx-dev@openjdk.java.net
Subject: Re: ProgressIndicator indeterminate transition bugs

If you can, are you able to file bug reports for these?

-- Jonathan

On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote:

  Hi all,

  We found two important bugs in ProgressIndicator that are related with the 
following tickets:

  https://bugs.openjdk.java.net/browse/JDK-8094829
  https://bugs.openjdk.java.net/browse/JDK-8094078

  Now are quite critical because in a 4K monitor may cause OutOfMemoryException.

  Using the following example:
  "
  public class JFXMain extends Application{

   @Override
   public void start(Stage primaryStage) throws Exception {
   HBox root = new HBox();
   ToggleButton toggleButton = new ToggleButton();
   ProgressIndicator progressIndicator = new 
ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS);
   StackPane stackPane = new StackPane(progressIndicator);
   stackPane.visibleProperty().bind(toggleButton.selectedProperty());
   root.getChildren().addAll(toggleButton, stackPane);
   primaryStage.setScene(new Scene(root));
   primaryStage.show();
   }
  }
  "

  ** First bug **

  Starting the Progress Indicator with indeterminate progress will
  trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599
  start the animation even is not shown already:
  indeterminateTransition.playFromStart();

  ** Second bug **

  With the last commits in ProgressIndicator, as commented in JDK-8094829, the 
listeners do not care about the real visibility of the node(before it was used 
impl_treeVisibleProperty()). The consequence is that the ProgressIndicator in 
the example won´t be stopped.

  I can imagine that impl_treeVisibleProperty() should not be used and Jonathan G. said: 
" but I can't reliably fix that without an API such as what I expect the treeVisible 
API should do." But we did not find such alternative property.

  The solution we though is the usage of internal tree visible property like 
this:

  1. Modify method:
  "
   protected void updateAnimation(boolean isTreeVisible) { "
  2. Remove current calls to method in
  "
   @Override protected void handleControlPropertyChanged(String p) {
   super.handleControlPropertyChanged(p);

   if ("INDETERMINATE".equals(p)) {
   initialize();
   } else if ("PROGRESS".equals(p)) {
   updateProgress();
   }
}
  "
  3. Add listener at the end of the IndeterminateSpinner contructor the 
visibility listener:
  "
   private IndeterminateSpinner(boolean spinEnabled, Paint 
fillOverride) {
[...]
   impl_treeVisibleProperty().addListener((obs, oldVal, newVal) ->{
   updateAnimation(newVal);
   });
 }
  "

  What do you think?

  Additional note: I would like to add one more thing. I think that could be 
very good a property ReadOnlyBooleanProperty treeVisibleProperty() available in 
all Nodes.

  Please let me know if we can do 

Re: GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradient,_PAD on Vivante ARM)

[Chien Yang]

Hi Maurice,

Can you please file a JIRA on this issue?

Thanks,
- Chien

On 3/1/16, 11:45 PM, Maurice wrote:


Jim,

A solution in line of that of Johan Vos [1] works. JavaFX can be run 
and doesn't crash on startup when compiling the shaders. I think they 
should be taken into account for at least JavaFX 9, as it reduces a 
very serious bug to a possible optimization.


Maurice.

[1] 
https://bitbucket.org/javafxports/8u60-rt/commits/595633bbaae36f98d85d47d276294442ea43488c


Op 02-03-16 om 02:22 schreef Jim Graham:
The thing about this use of pixcoord is that the same information can 
be supplied much more efficiently as a pair of texture coordinates.  
The value of pixcoord ends up being a linear equation over the area 
of the primitive which is exactly what texture coordinate samples 
give you for free.


I believe some of the other gradient methods use that texture 
coordinate technique to avoid having to use pixcoord, but the issue 
is that we've hard-coded all of our VertexBuffer streams to have 
exactly 2 sets of texture coordinates and so you only get room to 
pass in so many values and these (i.e. this family of) shaders are 
already using those texture coordinates to pass in too many values to 
leave enough free for the gradient fractions.


This shader could be avoided, I believe, by rasterizing the shape 
into an alpha mask and using one of the alpha mask gradient shaders 
that doesn't rely on pixcoord.  In fact, in some embedded 
environments these shaders have so many computations per pixel that 
running the shape rasterizer on the CPU actually wins performance 
(and especially if you cache the alpha masks as some of our NGShape 
nodes do)...


...jim

On 3/1/16 9:10 AM, Maurice wrote:

Re: GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradient,_PAD on Vivante ARM)

[Chien Yang]

Thanks for the information. It is worth filing a JIRA with a detail 
information of your embedded device at this point.


https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report

Thanks,
- Chien

On 2/29/2016 10:35 AM, Maurice wrote:
No, I build them myself from the instructions on the Wiki 
<https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float>. 



Maurice.

Op 29-02-16 om 17:49 schreef Chien Yang:
I have a quick question. Did you get your embedded JavaFX library 
from Glueon?


http://gluonhq.com/open-source/javafxports/downloads/

- Chien


On 2/29/16, 7:21 AM, Maurice wrote:
Should I file a bug? I can't determine whether this is a client 
platform issue or a major bug in the EGL that JavaFX is using. In 
any case, it does not work on my embedded device.


Maurice.

Op 28-02-16 om 18:33 schreef Maurice:
  When I run the glslangValidator on 
FillRoundRect_LinearGradient_PAD.frag it gives the following error:
ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es


When I move pixcoord's declaration on line 19 into the main() 
function it gives no errors.


This is the full output of find -name "*.frag" -exec 
glslangValidator {} \;


ERROR: 0:53: 'oTexCoords' : undeclared identifier
ERROR: 0:53: 'texture2D' : no matching overloaded function found
ERROR: 0:53: '=' :  cannot convert from 'const float' to 'temp 
highp 4-component vector of float'

ERROR: 3 compilation errors.  No code generated.


ERROR: 0:55: 'oTexCoords' : undeclared identifier
ERROR: 0:55: 'texture2D' : no matching overloaded function found
ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
ERROR: 0:55: 'rgb' : vector field selection out of range
ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp 
highp 3-component vector of float'

ERROR: 5 compilation errors.  No code generated.


ERROR: 0:53: 'oTexCoords' : undeclared identifier
ERROR: 0:53: 'texture2D' : no matching overloaded function found
WARNING: 0:53: 'return' : type conversion on return values was not 
explicitly allowed until version 420

ERROR: 2 compilation errors.  No code generated.


ERROR: 0:55: 'oTexCoords' : undeclared identifier
ERROR: 0:55: 'texture2D' : no matching overloaded function found
ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
ERROR: 0:55: 'rgb' : vector field selection out of range
ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp 
highp 3-component vector of float'

ERROR: 5 compilation errors.  No code generated.


ERROR: 0:18: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:18: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:53: 'oTexCoords' : undeclared identifier
ERROR: 0:53: 'texture2D' : no matching overloaded function found
ERROR: 0:53: '=' :  cannot convert from 'const float' to 'temp 
highp 4-component vector of float'

ERROR: 3 compilation errors.  No code generated.


ERROR: 0:55: 'oTexCoords' : undeclared identifier
ERROR: 0:55: 'texture2D' : no matching overloaded function found
ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
ERROR: 0:55: 'rgb' : vector field selection out of range
ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp 
highp 3-component vector of float'

ERROR: 5 compilation errors.  No code generated.


ERROR: 0:53: 'oTexCoords' : undeclared identifier
ERROR: 0:53: 'texture2D' : no matching overloaded function found
WARNING: 0:53: 'return' : type conversion on return values was not 
explicitly allowed until version 420

ERROR: 2 compilation errors.  No code generated.


ERROR: 0:55: 'oTexCoords' : undeclared identifier
ERROR: 0:55: 'texture2D' : no matching overloaded function found
ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
ERROR: 0:55: 'rgb' : vector field selection out of range
ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp 
highp 3-component vector of float'

ERROR: 5 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:17: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:1

Re: GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradient,_PAD on Vivante ARM)

[Chien Yang]

I have a quick question. Did you get your embedded JavaFX library from 
Glueon?


http://gluonhq.com/open-source/javafxports/downloads/

- Chien


On 2/29/16, 7:21 AM, Maurice wrote:
Should I file a bug? I can't determine whether this is a client 
platform issue or a major bug in the EGL that JavaFX is using. In any 
case, it does not work on my embedded device.


Maurice.

Op 28-02-16 om 18:33 schreef Maurice:
  When I run the glslangValidator on 
FillRoundRect_LinearGradient_PAD.frag it gives the following error:
ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es


When I move pixcoord's declaration on line 19 into the main() 
function it gives no errors.


This is the full output of find -name "*.frag" -exec glslangValidator 
{} \;


ERROR: 0:53: 'oTexCoords' : undeclared identifier
ERROR: 0:53: 'texture2D' : no matching overloaded function found
ERROR: 0:53: '=' :  cannot convert from 'const float' to 'temp highp 
4-component vector of float'

ERROR: 3 compilation errors.  No code generated.


ERROR: 0:55: 'oTexCoords' : undeclared identifier
ERROR: 0:55: 'texture2D' : no matching overloaded function found
ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
ERROR: 0:55: 'rgb' : vector field selection out of range
ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp highp 
3-component vector of float'

ERROR: 5 compilation errors.  No code generated.


ERROR: 0:53: 'oTexCoords' : undeclared identifier
ERROR: 0:53: 'texture2D' : no matching overloaded function found
WARNING: 0:53: 'return' : type conversion on return values was not 
explicitly allowed until version 420

ERROR: 2 compilation errors.  No code generated.


ERROR: 0:55: 'oTexCoords' : undeclared identifier
ERROR: 0:55: 'texture2D' : no matching overloaded function found
ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
ERROR: 0:55: 'rgb' : vector field selection out of range
ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp highp 
3-component vector of float'

ERROR: 5 compilation errors.  No code generated.


ERROR: 0:18: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:18: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:53: 'oTexCoords' : undeclared identifier
ERROR: 0:53: 'texture2D' : no matching overloaded function found
ERROR: 0:53: '=' :  cannot convert from 'const float' to 'temp highp 
4-component vector of float'

ERROR: 3 compilation errors.  No code generated.


ERROR: 0:55: 'oTexCoords' : undeclared identifier
ERROR: 0:55: 'texture2D' : no matching overloaded function found
ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
ERROR: 0:55: 'rgb' : vector field selection out of range
ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp highp 
3-component vector of float'

ERROR: 5 compilation errors.  No code generated.


ERROR: 0:53: 'oTexCoords' : undeclared identifier
ERROR: 0:53: 'texture2D' : no matching overloaded function found
WARNING: 0:53: 'return' : type conversion on return values was not 
explicitly allowed until version 420

ERROR: 2 compilation errors.  No code generated.


ERROR: 0:55: 'oTexCoords' : undeclared identifier
ERROR: 0:55: 'texture2D' : no matching overloaded function found
ERROR: 0:55: 'scalar swizzle' : not supported with this profile: es
ERROR: 0:55: 'rgb' : vector field selection out of range
ERROR: 0:55: '=' :  cannot convert from 'const float' to 'temp highp 
3-component vector of float'

ERROR: 5 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:17: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not supported with 
this profile: es

ERROR: 1 compilation errors.  No code generated.


ERROR: 0:19: 'non-constant global initializer' : not 

Code Review Request For 8137252: JavaFX StackPane bounds not updated

[Chien Yang]

Hi Kevin and Jonathan,

Please review the proposed fix and the detail of the fix is recorded in 
the JIRA:


JIRA: https://bugs.openjdk.java.net/browse/JDK-8137252
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8137252/webrev.00/

Thanks,
- Chien

Re: Canvas Clip performance

[Chien Yang]

It will be great if you can include in your bug report the following 2 
piece of information:


1) Run your program with -Dprism.verbose=true. This will give us the 
graphics hardware information of your system.


2) Run your program with -Dprism.order=sw. This will force JavaFX to use 
its software pipe instead of hardware graphics acceleration. It will be 
good to know whether the poor performance is due to use of d3d pipe.


- Chien

On 2/5/16, 7:34 AM, Kevin Rushforth wrote:
Please file a bug. It might be possible for us to find a workaround, 
although it might also be possible that this is just an unfortunate 
limitation of Intel HD.


-- Kevin


Elric Morgenstern wrote:
Ok. Maybe the problems I am experiencing now with JavaFX are the 
reason why

D3D is not enabled for J2D?

I think Intel Graphics are rather widespread among laptops, so I'm a bit
surprised at the huge performance drop (from solid 60 FPS to 8 once I 
use a
spherical clip shape). I'd think Intel Graphics hardware form part of 
the

test set. I'm using a fairly common laptop (especially around business
circles) Dell Latitude E6410.

Any chance of this being investigated or do you think I will have to 
settle

with a workaround?


On Fri, Feb 5, 2016 at 1:01 AM, Philip Race  
wrote:



On 2/4/16, 2:59 PM, Elric Morgenstern wrote:


I see. Interesting. Isn't there a switch to toggle it on JDK8?


There is no switch that can enable it if it is disabled by 'default'.

Assuming you are talking about JavaFX, right? Because you were 
referring

to
Java2D in your reply.

No I am talking about 2D. What I meant was that maybe the 
performance issue

is inherent in the card and the only reason it looks OK with Java2D on
Intel is
that we aren't using anything much at all of the Intel chip and are 
doing

the work
on the cpu instead.

-phil.




On Thu, Feb 4, 2016 at 11:52 PM, Philip Race
wrote:

Java 2D does not (generally) enable D3D on Intel.
We tried for JDK 8 but there were problems and it was disabled 
again in

8u40 I think.
JDK 9 EA builds (currently) still have it enabled to help get some
testing
so
if you are running an 8ux release you might want to switch to 9 to 
get a

fairer comparison.

-phil.



On 2/4/16, 2:49 PM, Elric Morgenstern wrote:

Hi guys,

I've noticed that clipping performance (Canvas GraphicsContext) is
extremely bad on an Intel HD graphics chip. One rectangular clip is
fine,
anything beyond that, or a spherical clip shape, will bring the
framerate
to its knees.

I notice no performance difference on my GeForce system, but on the
integrated chip my application is basically insufferable.

The same thing performed with Java2D experiences no performance 
issues

on
neither system.

Any ideas?

Re: Canvas Clip performance

[Chien Yang]

Hi Elric,

Thanks for the extra information. This seems to rule out that the drop 
in performance might have to do with Intel HD:


> D3D no clipping:   very comfortable 60 FPS
> D3D clipping: 10 FPS

> Software no clipping: 30 FPS
> Software clipping: 8 FPS

It will still be useful to us if you can file a performance bug with a 
test program. This will help us to ensure that future fixes in this area 
will also cover your test case.


Thanks,
- Chien

On 2/5/2016 2:52 PM, Elric Morgenstern wrote:

Hi Chien, Kevin,

this is the result of verbose=true:

Prism pipeline init order: d3d sw
Using native-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.d3d.D3DPipeline
Loading D3D native library ...
succeeded.
D3DPipelineManager: Created D3D9Ex device
Direct3D initialization succeeded
(X) Got class = class com.sun.prism.d3d.D3DPipeline
Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline
Maximum supported texture size: 8192
Maximum texture size clamped to 4096
OS Information:
Windows 7 build 7601
D3D Driver Information:
Intel(R) HD Graphics
\\.\DISPLAY1
Driver igdumdx32.dll, version 8.15.10.2827
Pixel Shader version 3.0
Device : ven_8086, dev_0046, subsys_040A1028
Max Multisamples supported: 0
 vsync: true vpipe: true

Loading Prism common native library ...
succeeded.


The performance when using oval clipping also drops considerably when 
using the software pipe, but to about the same as when using D3D clipping.

D3D no clipping:   very comfortable 60 FPS
D3D clipping: 10 FPS

Software no clipping: 30 FPS
Software clipping: 8 FPS

I haven't filed a bug (yet), because there are already some issues 
that could be related to my problem:

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8090206
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8088687

The comments in this "fixed" bug report also indicate a stark 
disparity between rectangular and oval clipping:

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8098079

Then there is this, but it's already set to fixed:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8096359

It's worth mentioning that it's not just an oval clip shape that 
causes performance drops, but also using more than one rectangular shape.

Every rectangular shape beyond the first seems to reduce my FPS by 10.

I'm using JDK 1.80_60 by the way.




On Fri, Feb 5, 2016 at 6:38 PM, Chien Yang <chien.y...@oracle.com 
<mailto:chien.y...@oracle.com>> wrote:


It will be great if you can include in your bug report the
following 2 piece of information:

1) Run your program with -Dprism.verbose=true. This will give us
the graphics hardware information of your system.

2) Run your program with -Dprism.order=sw. This will force JavaFX
to use its software pipe instead of hardware graphics
acceleration. It will be good to know whether the poor performance
is due to use of d3d pipe.

- Chien


On 2/5/16, 7:34 AM, Kevin Rushforth wrote:

Please file a bug. It might be possible for us to find a
workaround, although it might also be possible that this is
just an unfortunate limitation of Intel HD.

-- Kevin


Elric Morgenstern wrote:

Ok. Maybe the problems I am experiencing now with JavaFX
are the reason why
D3D is not enabled for J2D?

I think Intel Graphics are rather widespread among
laptops, so I'm a bit
surprised at the huge performance drop (from solid 60 FPS
to 8 once I use a
spherical clip shape). I'd think Intel Graphics hardware
form part of the
test set. I'm using a fairly common laptop (especially
around business
circles) Dell Latitude E6410.

Any chance of this being investigated or do you think I
will have to settle
with a workaround?


On Fri, Feb 5, 2016 at 1:01 AM, Philip Race
<philip.r...@oracle.com <mailto:philip.r...@oracle.com>>
wrote:

On 2/4/16, 2:59 PM, Elric Morgenstern wrote:

I see. Interesting. Isn't there a switch to toggle
it on JDK8?

There is no switch that can enable it if it is
disabled by 'default'.

Assuming you are talking about JavaFX, right?
Because you were referring
to
Java2D in your reply.

No I am talking about 2D. What I meant was that maybe
the performance issue
is inherent in the card and the only reason it looks
OK with Java2D on
Intel is
that we 

Code Review Request For JDK-8140306: Add regression test for JDK-8136495

[Chien Yang]

Hi Kevin,

Please review the proposed robot test:

http://cr.openjdk.java.net/~ckyang/JDK-8140306/webrev.00/

I have verified that it works well on Mac, Linux and Windows.

Thanks,
- Chien

Code Review Request For JDK-8147010: Update JavaFX for move of sun.misc.PerformanceLogger to sun.awt.util

[Chien Yang]

Hi Kevin,

Please review the proposed fix:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8147010
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8147010/webrev.00/

Thanks,
- Chien

Code Review Request For JDK-8090185: Ubuntu: switching to fullscreen from primary stage in browser displays grey screen

[Chien Yang]

Hi Kevin,

Please review the proposed fix as we have investigated yesterday:

The fix is to check and handle correctly when there is change in the 
underlaying nativeWindow. This is the case happened on Linux when we do 
fullscreen in Applet mode.


Passed dev-build-lite run on Linux and Mac.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8090185
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8090185/webrev.00/
Thanks,
- Chien

Re: Huge JavaFX performance drop in Debian Jessie

[Chien Yang]

Hi Chris,

JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There 
is a high likelihood that the drop in performance is caused by the 
switch from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 
3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing 
JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command.


- Chien

On 12/21/2015 03:02 PM, Chris Newland wrote:

Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy to
Debian Jessie and JavaFX performance has suffered a huge drop :(

Possibly not JavaFX related but native apps (firefox etc) all seem to
perform the same and glxgears runs full sync framerate and 350fps
unsynced.

JavaFX stages open blank and can take 5 seconds to render. Trying to
scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app
for 10s+.

Previously stages opened in under 1s and scrolling was instant.

My DemoFX test platform (Canvas based effects) seems to run the same so it
only appears to be windows / stages that are affected.

It's an old (2010) system but JavaFX performance has dropped from slow to
unusable.

Will keep investigating and test on my Debian desktop once I upgrade it to
Jessie.

Cheers,

Chris
@chriswhocodes

JavaFX debug:

Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension initializeIfAvailable
INFO: Failed to initialize management extension
java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at 
com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40)
at
com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669)
at
com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:695)
at
com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(LauncherImpl.java:182)
at java.lang.Thread.run(Thread.java:745)

Prism pipeline init order: es2 sw
Using java-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.es2.ES2Pipeline
Loading ES2 native library ... prism_es2
Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from
relative path
succeeded.
GLFactory using com.sun.prism.es2.X11GLFactory
(X) Got class = class com.sun.prism.es2.ES2Pipeline
Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline
JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from
relative path
Maximum supported texture size: 2048
Non power of two texture support = true
Maximum number of vertex attributes = 16
Maximum number of uniform vertex components = 16384
Maximum number of uniform fragment components = 16384
Maximum number of varying components = 32
Maximum number of texture units usable in a vertex shader = 8
Maximum number of texture units usable in a fragment shader = 8
Graphics Vendor: Intel Open Source Technology Center
Renderer: Mesa DRI Intel(R) IGD
 Version: 2.1 Mesa 10.3.2
  vsync: true vpipe: true
Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so from
relative path
Loaded
/home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so
from relative path
Loaded
/home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so from
relative path
ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag
new alphas
ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag
ES2ResourceFactory: Prism - createStockShader:
Texture_LinearGradient_PAD.frag
ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag
ES2ResourceFactory: Prism - createStockShader: Solid_TextureFirstPassLCD.frag
ES2ResourceFactory: Prism - createStockShader:
Solid_TextureSecondPassLCD.frag
ES2ResourceFactory: Prism - createStockShader:
FillPgram_LinearGradient_PAD.frag
ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag
ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag
new alphas
new alphas
PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4

Re: CFV: New OpenJFX Committer: Johan Vos

[Chien Yang]

Vote: YES

On 12/21/2015 11:45 AM, David Hill wrote:


I hereby nominate Johan Vos to OpenJFX Committer.

Johan Vos (jvos) has been active in the OpenJFX community, and 
instrumental in the maturity of Monocle, the owner of the Android and 
IOS ports and is an OpenJFX Author.


A list of Johan's commits is also available by the following links

http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos
http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos

Votes are due by January 5th, 2016.

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: [Review request] 8145143: Promote Image.impl_getUrl() to public API as Image.getUrl()

[Chien Yang]

The patch looks good to me as it is. Question: Will the change to 
Optional makes it at odd with the existing public constructors? Or API 
cleanliness though I do see the beauty of using Optional here.


- Chien

On 12/10/15, 2:16 PM, David Grieve wrote:
I believe the url might be used in the CSS engine for caching images 
loaded from .css files. If the css image cache is made public (I don't 
know if that is planned, but it should be considered), then this API 
will matter.


On 12/10/15 4:39 PM, Kevin Rushforth wrote:
That's an interesting question. We haven't used Optional for such 
cases except the return value of Dialog showAndWait. Wrapping the URL 
in an Optional is more self-documenting, but perhaps less convenient 
if you know that it is non-null (and basically the same if you don't 
know, since this doesn't seem like something you would do anything 
with other than asking "is it valid").


Another interesting question: how useful is this API? It was on the 
list of impl_* method that Jonathan and I felt would be worth making 
public API out of, but I don't know how prevalent its use is?


-- Kevin


Tom Schindl wrote:
As i see it the url is optional so wouldn't make sense to return 
Optional to make this more explicit?


Tom

Von meinem iPhone gesendet

Am 10.12.2015 um 21:54 schrieb Jonathan Giles 
:


Hi Chien, Kevin,

Please can you review the following JBS issue (and attached patch):

https://bugs.openjdk.java.net/browse/JDK-8145143

As the subject line states, this issue proposes to promote the 
Image.impl_getUrl() method to Image.getUrl(), so that it is public 
API.


--


-- Jonathan

Code Review Request For JDK-8091170: Compile-time warnings in prism-es2 code

[Chien Yang]

Hi Kevin,

Please review the proposed fix which was moved from JDK-8090866 as per 
our conversation:


JIRA: https://bugs.openjdk.java.net/browse/JDK-8091170
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8091170/webrev.00/

Thanks,
- Chien

Code Review Request For JDK-8090866: Mac GL APIs do not need to be looked up

[Chien Yang]

Hi Kevin,

Please review the proposed fix.
JIRA: https://bugs.openjdk.java.net/browse/JDK-8090866
webrev: http://cr.openjdk.java.net/~ckyang/JDK-8090866/webrev.00/

Thanks,
- Chien

Code Review Request For JDK-8144542: Remove an experimental stopgap fix (-Dprism.experimental.skipMeshNormalComputation) that is no longer needed

[Chien Yang]

Hi Kevin,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8144542
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8144542/webrev.00/

Thanks,
- Chien

Re: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions

[Chien Yang]

> The key in Pair could actually be null and in this case hashCode will 
throw NPE.


This might be a good enough reason to have this fix.

- Chien

On 11/3/15, 12:07 PM, Vadim Pakhnushev wrote:
Hmm, yeah, the actual difference is in the prime number only (that is 
changing the algorithm only doesn't improve anything), so the only 
remaining reason to fix this is that Objects.hash guards against null 
values (and I forgot to mention it in the review).
The key in Pair could actually be null and in this case hashCode will 
throw NPE.


Vadim

On 03.11.2015 23:01, Vadim Pakhnushev wrote:
Well, not exactly... Previously it was 13*hash(a) + hash(b) and now 
it's 31*(31 + hash(a)) + hash(b).
And apparently it improves the quality somehow. I did a test with 
100^4 combinations and collision probability dropped by the factor of 
3 from 0.065% to 0.022%.
Not really impressive, but still, and it uses well-defined utility 
method.
Yeah, I know it's not really a bug since you don't want to rely on 
the hashCode at all...


Thanks,
Vadim

On 03.11.2015 22:35, Jim Graham wrote:
All this does is change the prime constant used to produce the hash 
value.


Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the 
13*hash(a) + hash(b) that the embedded implementation uses.


I don't really think this is a bug.  The fact that Integer objects 
make it easy to reverse engineer and compute collisions of any 
reasonable hash combination computation don't mean that the 
technique has a bug, it just means that the submitter can read the 
code and think of a counter-example.


If there are practical problems being caused for some particular and 
popular use case by the use of this particular constant "13", then 
we need to understand those issues and come up with a more 
comprehensive solution than to simply hand off to another mechanism 
which uses the same procedure with a different prime constant...


...jim

On 11/3/15 3:06 AM, Vadim Pakhnushev wrote:

Hi Chien,

Could you please review the fix:
https://bugs.openjdk.java.net/browse/JDK-8140503
http://cr.openjdk.java.net/~vadim/8140503/webrev.00/

Thanks,
Vadim

Re: Feature request: DirectX Support for Java3D / JavaFX on Windows & "Take care that OpenGL1 and OpenGL2 are supported by Java3D / JavaFX in a way, that OpenGL1-only computers are not excluded from a

[Chien Yang]

And by default Java 3D uses D3D on Windows too.

- Chien

On 10/20/15, 6:12 AM, Tom Schindl wrote:

Hi,

I've to admit that I could not follow you completely but JavaFX on
Windows is based on DirectX (OpenGL is only provided for Linux/OS-X
where it is the defacto standard and far from dead).

Tom

On 16.10.15 13:54, Rolf Hemmerling wrote:

Hello Java3D / JavaFX core developers!

Feature request:
1. DirectX Support for Java3D / JavaFX on Windows
2. "Take care that OpenGL1 and OpenGL2 are supported by Java3D / JavaFX
in a way, that OpenGL1-only computers are not excluded from any
function, and OpenGL2 computers benefit from better look of the visual
view" ( but have no "exclusive" commands which don´t compile or generate
runtime errors with OpenGL1 systems ).
3. Let the end user ( not the Java application developer) select between
DirectX and OpenGL - similar to the choice available with the 3D engine
"Unity3d".

Reason:
1. The Past:
10-15 years ago, standard desktop PCs were used for gaming on Windows
too, so with state-of-the-art graphics cards ( with 64-256 MB RAM ) the
graphics card manufacurers provided state-of-the-art graphics drivers
(OpenGL1, DirectX).

2. Nowadays:
2.1 most PCs running Windows use standard graphics drivers supplied by
Microsoft ( especially for "legacy" computers, especially after upgrade
of the operating system, e.g. Vista ->  Win7 ->  Win8>  Win10, especially
for busines PCs which are not gamer PCs, e.g. notebooks with
non-dedicated graphics cards ), and not by the graphics card
manufacturers AMD&  NVidia.
2.2 Microsoft's standard drivers supplied win Win7 / Win8 support still
OpenGL1 and DirectX ( by installation of a DirectX runtime), but usually
not OpenGL2. There is no option to upgrade a PC by installing a (newer)
OpenGL1 or OpenGL2 driver.
2.3 Even with some Macintosh PCs, there is some lack of (advanced)
OpenGL2 support I was told by the team which develop "Processing" ( see
below )

3. My observations&  opinion:
3.1
Directx9 is standard on the Windows platform since 15 years ( works with
all AGP graphics cards and first generations of PCIExpress graphics
cards, and any non-dedicated graphics cards of notebooks ), while
DirectX 10 / 11 / 12 is just upgrade available for gamer PCs.

Request: So if there should be DirectX for Java3D / JavaFX on Windows,
then it should be full support of DirectX9, and optional use of DirectX
10 /11 /12.

3.2
OpenGL1 is outdated ( does not make use of advanced hardware graphics
functions,.. ) but supported by almost all PCs.
OpenGL 2.0 is not available with most PCs running Windows, while running
Ubuntu Linux on the same machine offers such support in some cases even
on the same hardware.
OpenGL 2.0 is even not available to some current Macintosh PCs

My case:
I installed
http://www.processing.org/
http://www.github.com/processing/
, a Java application with special OpenGL1 libraries ( Processing 1.5.1 )
and special OpenGL2 libraries ( Processign 2.2.1 and newer )

3.2.1
Processing 1.5.1, using OpenGL1:
The 3D demo applications works fine on all my Windows computers

3.2.2
Processing 2.2.1, using OpenGL2:
3.2.1.1
The demo applications of the folder “Camera”, “Demos” - and maybe some
others, but not all - crash by the Java error message

“Framebuffer objects are not supported by this hardware (or driver) Read
http://wiki.processing.org/w/OpenGL_Issues for help”

, on my
1. “Athlon XP2400” desktop computer with NVIDIA GeForce 6600 graphics
card and webcam, with Win7 .
2. Notebook “Dell Vostro 1000”, with Win8.1 .
3. Notebook “ASUS Eee PC T101MT”, with Win8.1 .

3.2.1.2
The demo applications work well on my
1. Notebook “Dell Vostro 1000”, with Ubuntu Linux 14 LTE .
See above, its the same hardware, just other operating system.

**
The Processing developers gives some explanations about the use of
OpenGL ..
https://github.com/processing/processing/wiki/OpenGL-Issues
and why / that OpenGL2 is not a standard for most PCs, both
Windows-hardware and even some Macintosh-hardware. And they point to the
fact, that OpenGL2 support for "older" PCs is not available with Linux
too...
**
So they just don´t support all my computers with their new Processing
2.2.1 version, and its successors Processing 3,..

My statement: Java3D / JavaFX is not for gamers, but also for business
graphics, so missing "state of the art 3D power" is no reason not to
provide full 3D support - usual Java applications are not counted by
"frames / second". And JavaFX is for business menu applications too!

4.
Feature request: Please let check your JavaFX / Java3D API, if it uses
the OpenGL Framebuffer feature in a way, so that Java error message
“Framebuffer objects are not supported by this hardware (or driver) Read
http://wiki.processing.org/w/OpenGL_Issues for help”
might happen too. If so, please fix that.

Find a way to support both:

4.1 OpenGl1 ( for legacy and business PCs, or PCs which were just
"upgraded" with a new Windows where the graphics 

Re: pisces, produceFillAlphas

[Chien Yang]

Hi Johan,

This optimization is buggy but to see whether it helps you can try setting

-Dprism.scrollcacheopt=true

Please see JDK-8093860 for reason why it was disabled:
https://bugs.openjdk.java.net/browse/JDK-8093860

- Chien

On 10/15/15, 12:30 PM, Johan Vos wrote:

Thanks Jim.
I tried with different optimization flags, but it doesn't make a big
difference. Tracing it down to system calls, somehow the gl implementation
seems be be slower (glDrawElements(GL_TRIANGLES, numQuads * 2 * 3,
GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) per
invocation. The number of invocations is comparable between iOS and Android.

If you can give me a direction on where to search for the disabled
scrolling optimization, I'll try to re-enable that and see how it improves
performance. It might be a huge and quick win...

Thanks again,

- Johan

On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham  wrote:


Perhaps optimization flags with the native compiler?  Also, was it called
a similar number of times on both?

Ideally we'd just be using copyArea for the scrolling, but at one point we
disabled the scrolling optimizations on retina MBP because they didn't work
with a scale factor and I don't think we reenabled them yet.  That would
kill scrolling performance on mobile as a result of having to rerender the
scene on each scroll regardless of how long produceAlphas takes...

 ...jim


On 10/15/15 4:27 AM, Johan Vos wrote:


After spending lots of time optimizing JavaFX on iOS, I am now at the
point
where scrolling is 10 times faster on iOS than on Android.
The scrolling in the iOS version of the Gluon JavaOne mobile schedule
builder is pretty good imho. On Android, it is much slower. I profiled and
compared both, and it turns out that on Android, we spend lots of time in
the native implementation of NativePiscesRasterizer.produceFillAlphas
(implemented in native-prism/NativePiscesRasterizer.c)

On average, calling this native function on an iPhone 6 takes 40,000ns
whereas on a Nexus 6, this takes about 800,000ns.

If anyone has a suggestion on how to improve or avoid this, I'm all ears.

Thanks,

- Johan

JDK-8137004: Memory leak caused by Parent#removed not being freed

[Chien Yang]

Hi Vadim,

Can you please review the proposed fix?

JIRA: https://bugs.openjdk.java.net/browse/JDK-8137004
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8137004/webrev.00/

Thanks,
- Chien

Code Review Request For JDK-8136495: On es2 pipe, SceneAntialiasing.BALANCED flips scene affecting Mac and Linux platforms

[Chien Yang]

Hi Jim and Kevin,

Please review the proposed fix:
JIRA: https://bugs.openjdk.java.net/browse/JDK-8136495
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8136495/webrev.00/

Thanks,
- Chien

Re: Bug: SceneAntialiasing.BALANCED flips the scene on Mac

[Chien Yang]

Here is the link to the JIRA if you would like to track its progress:

https://bugs.openjdk.java.net/browse/JDK-8136495

- Chien

On 9/14/15, 1:19 PM, Kevin Rushforth wrote:

Jose,

Since Chien can easily reproduce it, he can file the bug for this one.

If you do need to report a bug in the future, you do so here:

http://bugs.java.com/

Thanks.

-- Kevin


José Pereda wrote:

Hi Chien

I'm not allow to do it, so I was going to ask... Please go ahead.

Thank you,
Jose

On Mon, Sep 14, 2015 at 9:58 PM, Chien Yang <chien.y...@oracle.com 
<mailto:chien.y...@oracle.com>> wrote:


Hi Jose,

Thanks for the heads-up! I'm able to reproduce the bug on my
Macbook Pro (retina display). I will file a JIRA on this if you
haven't done it yet.

Thanks,
- Chien


On 9/12/15, 7:34 AM, Kevin Rushforth wrote:

> I haven't found any report of this at
http://bugs.openjdk.java.net.

Then may I suggest that you please file one? Please also
include your graphics chipset in the bug report in case that
is relevant.

Thanks.

-- Kevin


José Pereda wrote:

Hi all

Based on this question at StackOverflow:


http://stackoverflow.com/questions/32525086/javafx-rendering-issue-on-osx-after-java-upgrade


Running the test from the original question on my MacBook
Pro Retina, OS X
Yosemite, with JDK 8u60 and the default prism es2, the
scene was flipped
vertically, but the mouse events were at the expected top
position.

I was able to narrow down the issue with this simple test
case:

public void start(Stage primaryStage) {
Scene scene = new Scene(new StackPane(new
Label("Antialising\nBalanced")),
300, 300, true, SceneAntialiasing.BALANCED);
primaryStage.setScene(scene);
primaryStage.show();
}

Changing BALANCED to DISABLED solved the issue.

I haven't found any report of this at
http://bugs.openjdk.java.net.

Thanks,
Jose




--

Re: Bug: SceneAntialiasing.BALANCED flips the scene on Mac

[Chien Yang]

Hi Jose,

Thanks for the heads-up! I'm able to reproduce the bug on my Macbook Pro 
(retina display). I will file a JIRA on this if you haven't done it yet.


Thanks,
- Chien

On 9/12/15, 7:34 AM, Kevin Rushforth wrote:

> I haven't found any report of this at http://bugs.openjdk.java.net.

Then may I suggest that you please file one? Please also include your 
graphics chipset in the bug report in case that is relevant.


Thanks.

-- Kevin


José Pereda wrote:

Hi all

Based on this question at StackOverflow:

http://stackoverflow.com/questions/32525086/javafx-rendering-issue-on-osx-after-java-upgrade 



Running the test from the original question on my MacBook Pro Retina, 
OS X

Yosemite, with JDK 8u60 and the default prism es2, the scene was flipped
vertically, but the mouse events were at the expected top position.

I was able to narrow down the issue with this simple test case:

public void start(Stage primaryStage) {
Scene scene = new Scene(new StackPane(new
Label("Antialising\nBalanced")),
300, 300, true, SceneAntialiasing.BALANCED);
primaryStage.setScene(scene);
primaryStage.show();
}

Changing BALANCED to DISABLED solved the issue.

I haven't found any report of this at http://bugs.openjdk.java.net.

Thanks,
Jose

Code Review Request For JDK-8088670: Remove use of internal classes methods from toys

[Chien Yang]

Hi Dave, Jonathan and Kevin,

Please review the proposed fix mentioned in the JIRA:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8088670

Thanks,
- Chien

Code Review Request For JDK-8087624: BoxBounds.is2D() method needs to take into account of its Z dimension in it return value

[Chien Yang]

Hi Kevin,

Please review the proposed as described in the bug report:

JBS: https://bugs.openjdk.java.net/browse/JDK-8087624
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8087624/webrev.00/

Thanks,
- Chien

Re: Status of 3D blending when diffuse component has alpha

[Chien Yang]

In 8u60, we made 3D Node to use the same default blendMode property 
setting of Node; i.e. SRC_OVER:


https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Node.html#blendModeProperty

This default blend mode should address most of the transparency 
rendering requested in [1] and [2]. Our tentative plan is to add a 
proper blending equation support for 3D in 9.


[1] https://bugs.openjdk.java.net/browse/JDK-8090548
[2] https://bugs.openjdk.java.net/browse/JDK-8097241

- Chien


On 7/8/15 2:37 PM, Herve Girod wrote:

Hello,

I just remarked that there was lot of activity recently (May 2015) on this
feature. What's the current state, and when will it be completely handled
in JDK 9?

We are currently adding 3D to a Java ARINC 661 Server, and ideally we would
like to have part of 3D alpha blending working before the end of this year.
I knwo that there is a workaround using superposed scenes, but maybe there
will be a simpler way to handle this before long?

Regards,

Hervé

[8u60] Code Review Request For JDK-8130122: Horizontal ListView incorrectly displays long data

[Chien Yang]

Hi Kevin,

Please review this proposed fix for a late-breaking regression found 
during this week's sanity testing:


JBS: https://bugs.openjdk.java.net/browse/JDK-8130122
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8130122/webrev.01/

Thanks,
- Chien

Code Review Request For RT-38179: [TabPane] TableView in TabPane has memory leak

[Chien Yang]

Hi Kevin,

Please the proposed fix with unit test included:

JIRA: https://javafx-jira.kenai.com/browse/RT-38179
Webrev: http://cr.openjdk.java.net/~ckyang/RT-38179/webrev.00/

Thanks,
- Chien

Code Review Request For RT-38370: [3D] PNT mesh only: Internally computed tangent vectors need to recomputed if its assocated texCoords or points have changed

[Chien Yang]

Hi Kevin,

Please review the proposed fix:

JIRA: https://javafx-jira.kenai.com/browse/RT-38370
Webrev: http://cr.openjdk.java.net/~ckyang/RT-38370/webrev.00/

Thanks,
- Chien

Code Review Request For RT-39418: [Mac,Retina,3D] Lighting is wrong (too dark, incorrect highlight) with pixel scaling

[Chien Yang]

Hi Kevin and Jim,

Please review the proposed fix, and detail information is in the JIRA:

JIRA: https://javafx-jira.kenai.com/browse/RT-39418
Webrev: http://cr.openjdk.java.net/~ckyang/RT-39418/webrev.00/

- Chien

Code Review For RT-39755: ScrollPane introduces distortions when scrolling up down

[Chien Yang]

Hi Kevin,

Please review the proposed fix:

JIRA: https://javafx-jira.kenai.com/browse/RT-39755
Webrev: http://cr.openjdk.java.net/~ckyang/RT-39755/webrev.00/

- Chien

Code Review Request For RT-39856: Layout Regression - bad row height

[Chien Yang]

Hi Kevin,

Please review the proposed fix.

JIRA: https://javafx-jira.kenai.com/browse/RT-39856

Thanks,
- Chien

Code Review Request For RT-37862: [ScenePulseListener] NPE in synchronizeSceneProperties

[Chien Yang]

Hi Kevin,

Please review the proposed fix.

JIRA: https://javafx-jira.kenai.com/browse/RT-37862

Thanks,
- Chien

Code Review Request For RT-40245: Regression: Mac (prism-sw) rendering is corrupted

[Chien Yang]

Hi Kevin and Jim,

Please review the proposed fix:

JIRA: https://javafx-jira.kenai.com/browse/RT-40245
Webrev: http://cr.openjdk.java.net/~ckyang/RT-40245/webrev.00/

Thanks,
- Chien

Code Review Request For RT-40099: GridPane percentage layout bug since JavaFx 8u40

[Chien Yang]

Hi Kevin,

Please review the proposed fix. Detail information is in the JIRA:

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

Thanks,
- Chien

Re: Using JavaFX on VMWare / Linux

[Chien Yang]

Hi Adam,

I would like to inform you that VMware is not a certified hypervisor for 
Oracle JDK 8 and JRE 8, and hardware rendering is not supported in guest 
systems on Oracle VM, VirtualBox and Hyper-V Server 2012. Please see 
this link for details information:


http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html

- Chien


On 2/26/15 10:43 PM, Adam Granger wrote:

The company I work at mandate Linux development is done on a Redhat 6.x
guest within VMPlayer/Workstation on top of a Windows XP host.

Previous debugging has led me to believe, correct me if I'm wrong, that
drivers in the guest used to support OpenGL via VMWare expose the guests
hardware/driver strings such as  vmware etc, not the hosts
hardware/driver. Sorry I've not got the details with me right now, they're
at work, will update later...

I'd like to know if

   1) acceleration is expected to work on the guest if the host has a
supported GPU configuration?
   2) how the whitelist / blacklist system in prism works in this case?
 - I believe it sees vmware and then assumes vmware isn't nvidia
etc. and gives up
 - how can it see the hosts physical GPU hardware/driver correctly to
make an informed choice?
   3) is it possible to disable/override the white/blacklist system albeit
at risk?

Kind regards,

Adam.

Re: Directional light in JavaFX 3D

[Chien Yang]

Hi Herve,

A JIRA for directional light has already been filed but there is no 
immediate plan to add this feature at the moment. Currently JavaFX 3D 
only supports point light and ambient light.


- Chien

On 2/6/15 3:10 PM, Herve Girod wrote:

Hello,

Are there plans to implement an API allowing directional lights ? it seems
that for now there exist only spot and ambiant light in JavaFX 3D.

Hervé

Re: Directional light in JavaFX 3D

[Chien Yang]

Sorry, I forgot to paste the JIRA link before hitting the send button.

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

- Chien

On 2/6/15 3:16 PM, Chien Yang wrote:

Hi Herve,

A JIRA for directional light has already been filed but there is no 
immediate plan to add this feature at the moment. Currently JavaFX 3D 
only supports point light and ambient light.


- Chien

On 2/6/15 3:10 PM, Herve Girod wrote:

Hello,

Are there plans to implement an API allowing directional lights ? it 
seems

that for now there exist only spot and ambiant light in JavaFX 3D.

Hervé

Code Review Request For RT-39921: With two or more application modal windows; windows deeper in the stack are receiving requestToFront when not enabled causes an NSBeep.

[Chien Yang]

Hi Kevin,

Please review this straightforward fix:

JIRA: https://javafx-jira.kenai.com/browse/RT-39921
webrev: http://cr.openjdk.java.net/~ckyang/RT-39921/webrev.00/

Thanks,
- Chien

Code Review Request For RT-39873: [Mac] Enable parallel execution of FX thread and Renderer thread for JFXPanel, FXCanvas

[Chien Yang]

Hi Kevin,

Please review the simple proposed fix:

JIRA: https://javafx-jira.kenai.com/browse/RT-39873
Webrev: http://cr.openjdk.java.net/~ckyang/RT-39873/webrev.00/

- Chien