Re: [API Review] RT-15314

[Kevin Rushforth]

That's my preference as well.

-- Kevin


Tom Schindl wrote:

I'd go for option 3 at this

Tom

Von meinem iPhone gesendet

Am 29.05.2013 um 23:51 schrieb David Hill :

  

We have a request  to allow non-sandboxed 
applications to disable the "ESC to exit full screen" overly (and the associated ESC 
action to exit Full Screen).

This is needed for "kiosk" style applications where Full Screen should only be 
under programmatic control.

I have several options to present, but all of them have an underlying change, 
which is the addition of a system property to disable the overlay behavior:
   -Djavafx.fullScreenWarning=false

API Option One: Add to Platform, providing for a system toggle that is static.
 public static void setFullScreenWarning(boolean warn)
 public static boolean getFullScreenWarning()

Note: I considered other options, like Application, but felt they were poor 
fits. I am willing to listen to reason though.

API Option Two: Add to Stage. This would be a per instance change, and not a 
global toggle:
 public void setFullScreenWarning(boolean warn)
 public boolean getFullScreenWarning()

API Option Three: don't change the API at this point, rely only on the system 
properly to disable the overlay.

Note: option three seems to be a reasonable solution for many of the users of this 
functionality, because in a "kiosk" style application you can control the 
launching anyway.

--
David Hill 
Java Embedded Development

"In the business world, the rearview mirror is always clearer than the 
windshield."
-- Warren Buffett (1930 - )

Re: Patches for packager tweaks

[Kevin Rushforth]

How long is it taking for community patches to get into a build these days?


Hi Danno,

There are two parts to the answer:

1) How long does it take for a proposed fix (patch) to be reviewed and 
accepted?


2) Once your patch is accepted and the changeset is pushed to the repo, 
how long before it shows up in an EA build?


#1 depends on what area it is, what is the scale of the proposed change: 
is it a simple bug fix, or a new feature with API or documentation 
implications, are there compatibility concerns, how risky is it, etc.


#2 is typically between 0.5 and 1.5 weeks depending when it is pushed.

As a reminder (Richard may have recently posted something about this, so 
my apologies if this is a duplicate reminder), anyone submitting a patch 
must first sign the Oracle Contributor Agreement (OCA) before we can 
consider taking it.


-- Kevin



Danno Ferrin wrote:

Just posted to bugs with patches for some tweaks I'de like to see to the
packager.

https://javafx-jira.kenai.com/browse/RT-30792
https://javafx-jira.kenai.com/browse/RT-30793

The first one is to allow for a comma separated list of enumerated
packagers, so it's not one or all.

The second one is more relevant, it moves the discovery of the bundlers
from being hard coded in the class file to loaded off of the
META-INF/services directory.  This allows a bunlder to be added at
"runtime" when the build is being done.  For example, a bundler that would
bundle RoboVM or APK files provided at runtime rather than having to
package it's reference into the source code itself.

How long is it taking for community patches to get into a build these days?
  

Re: Patches for packager tweaks

[Kevin Rushforth]

Right. I was answering the general question.

For the specific question, I will defer to Mark Howe, who is working on 
the packager.


-- Kevin


Daniel Zwolenski wrote:
I'm guessing Danno would like to know how long he should expect to 
wait for the patches he kindly contributed and linked to in that email 
to get included. Seems like a fair and reasonable question and one I'd 
also like to know the answer to. 

Perhaps a linked question that I'd also like to know: is anyone 
actually allocated to any work on the packager at the moment, and if 
not when are they next going to be?  



On Fri, May 31, 2013 at 11:44 AM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:



How long is it taking for community patches to get into a
build these days?


Hi Danno,

There are two parts to the answer:

1) How long does it take for a proposed fix (patch) to be reviewed
and accepted?

2) Once your patch is accepted and the changeset is pushed to the
repo, how long before it shows up in an EA build?

#1 depends on what area it is, what is the scale of the proposed
change: is it a simple bug fix, or a new feature with API or
documentation implications, are there compatibility concerns, how
risky is it, etc.

#2 is typically between 0.5 and 1.5 weeks depending when it is pushed.

As a reminder (Richard may have recently posted something about
this, so my apologies if this is a duplicate reminder), anyone
submitting a patch must first sign the Oracle Contributor
Agreement (OCA) before we can consider taking it.

-- Kevin




Danno Ferrin wrote:

Just posted to bugs with patches for some tweaks I'de like to
see to the
packager.

https://javafx-jira.kenai.com/browse/RT-30792
https://javafx-jira.kenai.com/browse/RT-30793

The first one is to allow for a comma separated list of enumerated
packagers, so it's not one or all.

The second one is more relevant, it moves the discovery of the
bundlers
from being hard coded in the class file to loaded off of the
META-INF/services directory.  This allows a bunlder to be added at
"runtime" when the build is being done.  For example, a
bundler that would
bundle RoboVM or APK files provided at runtime rather than
having to
package it's reference into the source code itself.

How long is it taking for community patches to get into a
build these days?
 

Re: JavaFX graphics performance and suitability for advanced animations

[Kevin Rushforth]

Btw, there is a JIRA issue filed against BrickBreaker specifically: 
https://javafx-jira.kenai.com/browse/RT-29801


Richard Bair wrote:

Have you tried to determine what the FPS is? My guess is that FPS is not 
anywhere near the limit and it is the occasional stutter that is the problem, 
but I'm not certain. Knowing that helps to point in which direction to go. The 
fact that it runs pretty well on a PI is indication that it isn't the framerate.

Richard

On May 31, 2013, at 4:26 AM, Scott Palmer  wrote:

  

Speaking of poor animation in Ensemble...

Is anyone able to run Brick Breaker without choppy animation or poor framerate performance on the ball?  


Now, I suspect the issue there is in the balls animation implementation in the 
application rather than the JavaFX framework, as the bat moves smoothly when I 
move the mouse, but the overall perception of JavaFX performance for this demo 
app is not good. I would go so far as to say that Brick Breaker has had the 
opposite effect it was intended too - simply because the animation of the ball 
is not smooth.  That's something that would run smoothly on a Commodore 64,yet 
the last time I tried it (5 minutes ago) with JavaFX 8.0-b91 on a quad-core 
3GHz Windows 7 box with a decent NVIDIA card, it didn't run as smoothly as I 
would expect.  Just a single ball with a shadow bouncing around the screen 
seemed to have a low framerate and the occasional skipped frame.  It just 
didn't look that great.

The fact that Brick Breaker ships as a sample app from Oracle and it's 
animation looks bad is harming JavaFX's reputation in my opinion.  I think  it 
could run much better on the existing JavaFX runtime.  The simple animations in 
the Ensemble app run much smoother for example.



Scott


On Thu, May 30, 2013 at 11:11 AM, Richard Bair  wrote:



Then you mention Halo 5.  I have to say the subtext here troubles me
greatly.  If I read you correctly then you are saying that JavaFX is not
really suitable for games (at least anything beyond the demands of something
like Solitaire).  As someone else pointed out, what is point of developing
3D support in JavaFX if it is not really suitable for games?  To say it is
not suitable for games implies that it is not really suitable for *any*
application that requires performant animations and visualisations.  What
use then is the 3D API?
  

That's not fair at all. There are a *lot* of enterprise use cases for 3D, and 
we get these requests all the time. Whether we're taking about 3D 
visualizations for medical or engineering applications or consumer applications 
(product display, etc), there is a requirement for 3D that are broader than 
real time first person shooters.

Game engines often have very specialized scene graphs (sometimes several of 
them) as well as very specialized tricks for getting the most out of their 
graphics cards. When we expose API that allows people to hammer the card 
directly, then it would be possible for somebody to build some of the UI in FX 
and let their game engine be hand written (in Unity or JOGL or whatever).

 


However, I am not sure that having me preparing "reproducible" test cases
will actually help.  In my experience, the Ensemble app already serves this
purpose.  The choppiness I describe is *always* prevalent when I run the
animations and transitions in Ensemble (including Ensemble 8).  The only
variation is in the degree of that choppiness.
  

Then start with that, something absolutely dead simple like a path animation or 
rotate transition and lets figure out how to measure the jitter and get it into 
our benchmark suite.

Richard




  

Re: System.err printSummary (D3D Vram Pool) lines

[Kevin Rushforth]

Yes, please do report these. They are effectively assertions indicating 
that something has gone wrong with the texture management code. Some 
have been fixed recently, but probably not all of them.


-- Kevin


John Hendrikx wrote:

Hi List,

In b90 and b92 I'm getting these kinds of prints (often continously) 
when I'm using my application, and I'm not sure if I'm supposed to 
report them:


@com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:134) 



D3D Vram Pool: 96,767,731 used (36.0%), 96,767,731 managed (36.0%), 
268,435,456 total

54 total resources being managed
4 permanent resources (7.4%)
2 resources locked (3.7%)
18 resources contain interesting data (33.3%)
1 resources disappeared (1.9%)

They are fairly easy to reproduce -- it usually involves scrolling 
through a list that updates a lot of images/texts being dynamically 
loaded.  I sometimes get partial blackouts of the Scene as well (Nodes 
not rendering, or nodes being obscured by a big black box).  This last 
one has been happening for ages already (since JavaFX 2.2 atleast) so 
that's nothing new.


--John

Re: ObservableValue Stacktrace

[Kevin Rushforth]

Perhaps using the logging system would be a better choice in the case 
than printing to stderr?


-- Kevin


Martin Sladecek wrote:

On 06/06/2013 10:53 AM, John Hendrikx wrote:
Hm, ok -- it is correct that it doesn't fail, the code runs without 
any problem and everything works as expected.


But, what would be the way to avoid these messages in my log then?  
Something like:


  Bindings.select( Bindings.when(dataProperty().isNull()).then( ??? 
).otherwise(dataProperty()), "castings") );


??

I'd prefer to just turn these warnings off unless there is a really 
good reason to have them (ie, they indicate a logic error or other 
bug, something I can resolve...)


This might indicate a logic error in many cases, esp. when the 
property you bind is a primitive type. When the select fails in the 
middle of computation, the only it can do is to set the property to 
default value (which is 0). If the developer
didn't expect this, it would be quite hard to find the actual cause of 
the zero. If you really expect nulls along the way, it's much cleaner 
to handle this explicitly as you do in the code above.




In my case the dataProperty() is often bound to the selection of a 
ListView -- if you have something valid selected, then a Detail Pane 
is filled in with information about the selected item.  When nothing 
is selected (ie, it is null), then the Detail Pane should remain 
empty... I donot want to have to remove/recreate these bindings every 
time some property becomes null.


Also, it seems rather wierd that JavaFX will complain about nulls in 
the first part of the Bindings.select(), but will happily traverse 
the graph (with or without nulls) for the other parts.
This is a bug then, it should print the warning in any part of the 
select expression.


-Martin

Re: NullPointer in BaseGraphics.drawTextureVO

[Kevin Rushforth]

Is this from FX 2.2.x or FX 8? The stack trace suggests an earlier 
version of FX. The only thing I can think of off hand is that the HW 
texture couldn't be created, probably because you ran out of resources. 
There are a few issues relating to this, which we believe are fixed in 
FX 8 with the implementation of RT-25323.


-- Kevin


Daniel Zwolenski wrote:

Can anyone tell me what might cause the exception below in Prism?

It's from an app that captures video via a native library (LTI-CIVIL) and
then converts that image to JFX display via:

BufferedImage buffImage = AWTImageConverter.toBufferedImage(image);
jfxImage = javafx.scene.image.Image.impl_fromExternalImage(buffImage);
previewView.setImage(jfxImage);


java.lang.NullPointerException
at com.sun.prism.impl.BaseGraphics.drawTextureVO(BaseGraphics.java:365)
at com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:334)
at
com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:103)
at com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:315)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139)
at com.sun.javafx.tk.quantum.PaintRunnable.doPaint(PaintRunnable.java:214)
at com.sun.javafx.tk.quantum.PaintRunnable.paintImpl(PaintRunnable.java:145)
at com.sun.javafx.tk.quantum.PaintRunnable.run(PaintRunnable.java:349)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at com.sun.prism.render.RenderJob.run(RenderJob.java:29)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:101)
at java.lang.Thread.run(Thread.java:722)
  

Re: NullPointer in BaseGraphics.drawTextureVO

[Kevin Rushforth]

I missed the fact that this is using the non-public 
impl_fromExternalImage() method. This was replaced in FX 2.2 by 
SwingFXUtils.toFXImage as Werner mentions and has been removed from FX 8 
entirely.


One more thing to check is that jfxImage is non-null, although it is 
still more likely than not that you are running out of resources.


-- Kevin


Werner Lehmann wrote:

Is this the same as SwingFXUtils.toFXImage?

On 11.06.2013 14:27, Daniel Zwolenski wrote:

 BufferedImage buffImage = AWTImageConverter.toBufferedImage(image);
 jfxImage = 
javafx.scene.image.Image.impl_fromExternalImage(buffImage);

 previewView.setImage(jfxImage);

Re: NullPointer in BaseGraphics.drawTextureVO

[Kevin Rushforth]

I take it there's no way to avoid the resources issue in the old JFX, 
it's just a plain and simple bug?


I don't know of a way to completely avoid it. As far as we know there 
aren't any actual leaks in the more recent FX 2.2.x texture code, but 
the resource disposal is not deterministic and if you hit the limit of 
texture memory it does not recover gracefully (or at all).


Jim might have more insight, since he implemented the new texture 
management system for FX 8.;


-- Kevin



Daniel Zwolenski wrote:
This is an older version, probably JFX from around jdk1.7.0_02. 

I'm running it now on jdk1.7.0_21 to see what happens (takes about an 
hour to get to the point of failure, which is why I didn't pick it up 
when I wrote the code originally).


Unfortunately chunks of the system are broken when it runs on this 
newer code. Lots of backwards compatibility breaks, especially visual 
ones with CSS that just make it screwy. This is an old project and I 
don't really want to be touching this code but they have this video 
capture bug which is killing everything. 

I take it there's no way to avoid the resources issue in the old JFX, 
it's just a plain and simple bug?




On Tue, Jun 11, 2013 at 11:10 PM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


Is this from FX 2.2.x or FX 8? The stack trace suggests an earlier
version of FX. The only thing I can think of off hand is that the
HW texture couldn't be created, probably because you ran out of
resources. There are a few issues relating to this, which we
believe are fixed in FX 8 with the implementation of RT-25323.

-- Kevin



Daniel Zwolenski wrote:

Can anyone tell me what might cause the exception below in Prism?

It's from an app that captures video via a native library
(LTI-CIVIL) and
then converts that image to JFX display via:

BufferedImage buffImage =
AWTImageConverter.toBufferedImage(image);
jfxImage =
javafx.scene.image.Image.impl_fromExternalImage(buffImage);
previewView.setImage(jfxImage);


java.lang.NullPointerException
at
com.sun.prism.impl.BaseGraphics.drawTextureVO(BaseGraphics.java:365)
at
com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:334)
at
com.sun.prism.impl.ps

<http://com.sun.prism.impl.ps>.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:103)
at
com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:315)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205)
at
com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205)
at
com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205)
at
com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205)
at
com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139)
at
com.sun.javafx.tk.quantum.PaintRunnable.doPaint(PaintRunnable.java:214)
at

com.sun.javafx.tk.quantum.PaintRunnable.paintImpl(PaintRunnable.java:145)
at
com.sun.javafx.tk.quantum.PaintRunnable.run(PaintRunnable.java:349)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at

java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at com.sun.prism.render.RenderJob.run(RenderJob.java:29)
at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   

Re: FX 8 3D sample FXTuxCube : several issues detected

[Kevin Rushforth]

Hi August,

Can you file JIRA issues for these problems? None of these sound exactly 
like any known issues.


-- Kevin


August Lammersdorf, InteractiveMesh wrote:
FXTuxCube is a SubScene-based interactive 3D application to meassure 
the 3D system performance.


Are following issues known or under development or should they be 
reported? Haven't found any corresponding JIRA issues.


 - SubScene.setFill(Color.TRANSPARENT) required, otherwise SubScene 
doesn't receive mouse events
 - Hierarchical RotateTransitions (cube and tuxes) result in a more 
(cube size 2) or less (cube size 12) uneven rotation
 - A BackgroundFill with a Color object creates a weird blending 
result, LinearGradient and RadialGradient work fine (Windows only)
 - ComboBox.setPromptText("Select") results in an empty label, see 
Viewpoint's ComboBox

 - Resizing the window crashes the application (Linux only)

FXTuxCube is available here : 
http://www.interactivemesh.org/models/jfx3dtuxcube.html


August

Re: Moving to Gradle (finally)

[Kevin Rushforth]

You cannot run "gradle" in the rt repo just yet.

For now (i.e., until the switch to gradle with the accompanying repo 
reorg), you must run the generator.gradle script which reorganizes the 
repo to its new layout, and puts it, by default, in ../javafx


Among other things it copies gradleBuildSrc to buildSrc but also copies 
the multiple "mini" projects (javafx-ui-common, javafx-ui-controls, 
prism-*, etc) to their new locations under modules/**


-- Kevin


Mario Torre wrote:

On Tue, 2013-06-25 at 13:10 -0400, steve.x.northo...@oracle.com wrote:
  

Hello OpenJFX,



  
We are hoping that the workspace reorganization and the new gradle build 
will make it much easier for everybody to be able to build & test with 
JavaFX. 



Hello Steve,

Speaking of gradle, I have:

[org.gradle.BuildExceptionReporter] A problem occurred evaluating root
project 'rt'.
[org.gradle.BuildExceptionReporter] > Could not read script
'/home/neugens/work_space/jdk/openjfx/master/rt/buildSrc/linux.gradle'
as it does not exist.

There is actually a linux.gradle, but it's in gradleBuildSrc:

./gradleBuildSrc/linux.gradle


If I change all the occurrences of buildSrc to be gradleBuildSrc in the
build file, I can get to this:

[org.gradle.BuildExceptionReporter] * What went wrong:
[org.gradle.BuildExceptionReporter] A problem occurred evaluating root
project 'rt'.
[org.gradle.BuildExceptionReporter] > Could not find property
'JavaHeaderTask' on root project 'rt'.

Any idea of what I may do wrong?

Cheers,
Mario


  

Re: Native font rendering in JFX8 b96?

[Kevin Rushforth]

I can confirm that yes, the native font code is turned on for b96 on 
Windows (it was turned on for Mac in b94).


-- Kevin


John C. Turnbull wrote:

So Phil, is that now in b96?

On 29/06/2013, at 14:30, Phil Race  wrote:

  

For most Windows users and use cases the main differences are that
1) Previously GDI produced the LCD glyphs, now its DW.
2) Previously T2K produced the grayscale glyphs, now its DW.

T2K doesn't do layout. It just does rasterisation.
Most users won't hit the layout path (for complex text).

-phil.

On 6/28/13 8:52 PM, Richard Bair wrote:


Fonts do look good but I thought they always looked pretty good on Windows!


With the old code we were using Windows to create the glyphs, so the rendering 
should look just as good for each glyph. T2K was doing the layout of glyphs, 
now it should be using DirectWrite on Windows. Not sure if it is b96 -- Felipe?

Richard
  

Re: [API Review]: Node validation

[Kevin Rushforth]

+1

This would allow apps to dispense with the following workaround when 
taking a snapshot:


   // create a dummy scene so layout and CSS will work
   new Scene(new Group(node));

   node.shapshot(...)

-- Kevin


David Grieve wrote:

Hi Martin,

With regard to having this work without a Scene…

I think having a method that would layout a node without the node actually having to be part of the scene-graph would be _very_ useful.  Often times, developers will do the show-hide trick or add-remove trick to get a node's bounds before the node is shown for real. SceneBuilder has to do tricks like these to deal with popup controls, like tooltip. 

What styles are applied from CSS depends on where the node is in the scene-graph, so the method would need to be 'if I add this node to this parent, what will be the node's bounds?'. To make this work on the CSS side would require decoupling the 'css graph' from the scene-graph. RT-30894 touches on that. 


On Jul 3, 2013, at 8:33 AM, Martin Sladecek  wrote:

  

Hi,

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

I propose a single method "public final void validate()" to be added to Node class. 
The validate method would ensure that the metrics (layout bounds) of the Node are valid with 
regards to the current scenegraph (CSS & layout).

Together with this change, Parent.layout() will be deprecated.

In my current implementation, validate() method works only if the Node is in a 
Scene. To make it work without a Scene, we'd need to do do some small 
adjustments to CSS (doesn't work with getScene() == null). But I'm not sure if 
such feature would be useful.

Regards,
-Martin



  

Re: MSAA and Scene anti aliasing

[Kevin Rushforth]

I don't really like the single enum approach. I would prefer to keep the 
existing MSAA boolean, and then, if needed, add a separate attribute for 
requesting the number of samples; if desired there could be a read-only 
attribute that returns the actual number of samples used. Most chipsets 
give limited (or no) control over the number of samples anyway so an 
enum doesn't seem like a good fit.


-- Kevin


Gerrit Grunwald wrote:

+1 for the enum approach...will make it easier to enhance for future options...

Gerrit 


Am 12.07.2013 um 19:55 schrieb Richard Bair :

  

Thor recently pushed an implementation for MSAA for those cases when the feature is 
supported by the card and where a Scene (or SubScene) is created with the antiAliasing 
flag set to true. MSAA is "Multi-sampled Anti Aliasing", which means that the 
graphics card, when configured in this mode, will sample each fragment multiple times. 
The upshot is that 3D doesn't look as jaggy.

However this has an impact on performance (usually an extra buffer copy or at 
the very least you will be sampling each pixel multiple times so if you are 
doing something graphically intense then that might push you over the edge 
where you start to see performance degradation). Now multi-sampling can be 2x, 
4x, etc. The higher the multi-sampling value, the better the quality, and the 
lower the performance.

I'm also bothered but the name "antiAliasing" because there are many forms of 
anti-aliasing in the world and it isn't clear which this is. I think perhaps we should 
instead have an enum. The idea is that we can add to the enum over time with greater 
options for how to perform the scene antialiasing.

public enum SceneAntiAliasing {
   DISABLED,
   DEFAULT,
   MSAA_2X,
   MSAA_4X
}

And then grow it over time to include potentially other techniques. My thought 
here is that the implementation is going to matter to folks. They're going to 
want to be able to make the performance / quality tradeoff, and perhaps even 
the implementation tradeoff (since different implementations may provide 
somewhat different results). DISABLED turns it off, obviously. DEFAULT allows 
us to pick what we think is the best (might be different on different 
platforms. Desktop might go with MSAA_16x or equivalent while iOS might be 
MSAA_2X). Then some standard options.

Thoughts?
Richard

Re: Making Color Final (and Paint too, for all intents and purposes)

[Kevin Rushforth]

+1

In practice I agree with Richard that this should not cause any issues 
for applications.


-- Kevin


David Ray wrote:

+1

David

Sent from my iPhone

On Jul 12, 2013, at 3:15 PM, Richard Bair  wrote:

  
I have two different changes I might want to make, both of which are definitely incompatible for subclasses, but are otherwise source compatible. 


public abstract class Paint {
   Paint() { } // <--- Add this package constructor. Anybody who subclassed 
Paint will die
}

public final class Color extends Paint { … } // < Added final

Nobody can do anything useful today by subclassing Paint. Each Paint subclass 
has hardcoded support in the graphics pipeline. If you were to subclass Paint 
with WackyPaint and use it in the scene graph, it would do absolutely nothing 
(except maybe explode in the graphics pipeline someplace). Likewise, if you 
extend Color with WackyColor, it will only be used as a Color object.

Color however does have non-final methods (blast!) which somebody could 
override. Now, they could do nefarious things with it (as far as the graphics 
pipeline is concerned), but other than logging when somebody called a method, 
there is nothing else they could do by overriding (since Color is immutable), 
except for the deriveColor method which could be reimplemented in a reasonable 
manner, although the platform will never call your method so it doesn't do you 
much good.

Both of these *should* have been final / effectively final when defined in the 
first place, and we've made subclassing these classes sufficiently worthless by 
other methods (other final methods plus the way the pipeline works) that nobody 
should really be broken but such a change. Besides which, we added a new 
abstract method in the last release which essentially breaks any subclasses in 
a binary manner (they would have to update their code), and I'm about to do it 
again while fixing https://javafx-jira.kenai.com/browse/RT-31565.

Anybody with major heartburn let me know now, 'cause its going down!

Richard

Re: MSAA and Scene anti aliasing

[Kevin Rushforth]

I am fine with an enum that represents the style of AA requested: NONE, 
MSAA, SOME_OTHER_AA, ...


It is the combining of number of samples into the enum that seems 
undesirable to me. I would prefer that be a separate Integer attribute.


-- Kevin


Mario Torre wrote:


At first I was about to reply a +1 to Kevin, but then I realised:

1. This is indeed an area where people want to know the implementation 
details.


2. An enum can be extended with different implementations, for example 
add a non MSAA to the mix.


The drawback is that the enum may grow just for the need to add a new 
property to the AA algorithm. I'm not sure how likely this is, but I 
didn't see that many actual implementations to consider that an issue.


If this is the case, one may have a descriptor object passed rather 
than an enum, so that external implementations may easily 
extend/replace the default code.


The descriptor could be an opaque type so that the code that needs to 
handle knows about it, but for users it still behaves like if it was 
an enum. In fact, the defaults may even be collected in an enum again.


Cheers,
Mario

Il giorno 15/lug/2013 01:24, "Richard Bair" <mailto:richard.b...@oracle.com>> ha scritto:


I know iOS gives at least two or three options. A single enum
seems cleaner than two properties (and yet another constructor!
Speaking of which it would be better if this were a mutable property).

Is it that you don't like that some options can't be honored?

    On Jul 13, 2013, at 12:00 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>
wrote:

> I don't really like the single enum approach. I would prefer to
keep the existing MSAA boolean, and then, if needed, add a
separate attribute for requesting the number of samples; if
desired there could be a read-only attribute that returns the
actual number of samples used. Most chipsets give limited (or no)
control over the number of samples anyway so an enum doesn't seem
like a good fit.
>
> -- Kevin
>
>
> Gerrit Grunwald wrote:
>> +1 for the enum approach...will make it easier to enhance for
future options...
>>
>> Gerrit
>> Am 12.07.2013 um 19:55 schrieb Richard Bair
mailto:richard.b...@oracle.com>>:
>>
>>
>>> Thor recently pushed an implementation for MSAA for those
cases when the feature is supported by the card and where a Scene
(or SubScene) is created with the antiAliasing flag set to true.
MSAA is "Multi-sampled Anti Aliasing", which means that the
graphics card, when configured in this mode, will sample each
fragment multiple times. The upshot is that 3D doesn't look as jaggy.
>>>
>>> However this has an impact on performance (usually an extra
buffer copy or at the very least you will be sampling each pixel
multiple times so if you are doing something graphically intense
then that might push you over the edge where you start to see
performance degradation). Now multi-sampling can be 2x, 4x, etc.
The higher the multi-sampling value, the better the quality, and
the lower the performance.
>>>
>>> I'm also bothered but the name "antiAliasing" because there
are many forms of anti-aliasing in the world and it isn't clear
which this is. I think perhaps we should instead have an enum. The
idea is that we can add to the enum over time with greater options
for how to perform the scene antialiasing.
>>>
>>> public enum SceneAntiAliasing {
>>>   DISABLED,
>>>   DEFAULT,
>>>   MSAA_2X,
>>>   MSAA_4X
>>> }
>>>
>>> And then grow it over time to include potentially other
techniques. My thought here is that the implementation is going to
matter to folks. They're going to want to be able to make the
performance / quality tradeoff, and perhaps even the
implementation tradeoff (since different implementations may
provide somewhat different results). DISABLED turns it off,
obviously. DEFAULT allows us to pick what we think is the best
(might be different on different platforms. Desktop might go with
MSAA_16x or equivalent while iOS might be MSAA_2X). Then some
standard options.
>>>
>>> Thoughts?
>>> Richard
>>>

Re: Building sources for jfxrt.jar and missing packages

[Kevin Rushforth]

I´m trying to build a jar containing all sources for jfxrt.jar, so I can attach 
it in Eclipse. For this I´ve added the following lines to the root build.gradle:
...
Is this the correct way to go about it?
  


This looks like the right approach, yes (although rather than excluding 
a list of files, I would just include *.java). Btw, there is a JIRA on 
my plate to produce this for the production build -- RT-21415 
  -- but it was put on 
hold, due to the work on the gradle build among other things.



I also noticed that the jfxrt.jar from the latest JDK1.8 snapshot includes 
com.sun.media.* packages which are not yet part of OpenJFX (at least I don´t 
think so, as my modules/media directory is empty). Is there a reason for this?
  


Media has not yet been open-sourced, but that work is in progress.

-- Kevin


Robert Fisher wrote:

Hi everyone,
 
I´m trying to build a jar containing all sources for jfxrt.jar, so I can attach it in Eclipse. For this I´ve added the following lines to the root build.gradle:
 



build.gradle:
 
task jfxrtSources()
 
compileTargets{
 
...
 
def jfxrtSourcesTask = task("jfxrtSources$t.capital", type: Jar) {

 group = "Basic";
 description = "Creates the jfxrt-sources.jar for the $t.name target";
 archiveName = "build/${t.name}-sdk/rt/lib/ext/jfxrt-sources.jar";
 includeEmptyDirs = false;
 from("modules/base/src/main/java",
  "modules/builders/src/main/java",
  "modules/controls/src/main/java",
  "modules/designTime/src/main/java",
  "modules/fxml/src/main/java",
  "modules/fxpackager/src/main/java",
  "modules/graphics/src/main/java",
  "modules/web/src/main/java");
 
 if (COMPILE_SWING) from ("modules/swing/src/main/java");

 if (COMPILE_SWT) from ("modules/swt/src/main/java");
 
 exclude(targetProperties.jfxrtJarExcludes);

}
jfxrtSources.dependsOn(jfxrtSourcesTask);
 
...
 
}



 
Is this the correct way to go about it?
 
I also noticed that the jfxrt.jar from the latest JDK1.8 snapshot includes com.sun.media.* packages which are not yet part of OpenJFX (at least I don´t think so, as my modules/media directory is empty). Is there a reason for this?
 
Thanks in advance,

Rob
 
 
Mit freundlichen Grüßen

Best Regards

Dr. Robert Fisher


TESIS DYNAware
Technische Simulation Dynamischer Systeme GmbH
Baierbrunner Str. 15
D-81379 München
Tel: +49-89-747377-7440
Fax: +49-89-747377-99

http://www.tesis-dynaware.com
robert.fis...@tesis.de

Geschäftsführung / Board of Directors
Dr.-Ing. Cornelius Chucholowski - Dipl. Ing. Christian Zahn
Amtsgericht München, HRB 115649


TESIS DYNAware simulation software is in use at Audi, BMW, Ford, MAGNA, MAN, VW 
and elsewhere.

Read more: http://www.tesis-dynaware.com/customers

Re: Building sources for jfxrt.jar and missing packages

[Kevin Rushforth]

No, it will not be part of src.zip for JDK 8, but a parallel 
"javafx-src.zip" file in the same directory as src.zip.


-- Kevin

Tom Schindl wrote:

Do you already have an idea of the nameing & location? Or will it be
part of src.zip?

Tom

On 16.07.13 13:35, Kevin Rushforth wrote:
  

I´m trying to build a jar containing all sources for jfxrt.jar, so I
can attach it in Eclipse. For this I´ve added the following lines to
the root build.gradle:
...
Is this the correct way to go about it?
  
  

This looks like the right approach, yes (although rather than excluding
a list of files, I would just include *.java). Btw, there is a JIRA on
my plate to produce this for the production build -- RT-21415
<https://javafx-jira.kenai.com/browse/RT-21415>  -- but it was put on
hold, due to the work on the gradle build among other things.



I also noticed that the jfxrt.jar from the latest JDK1.8 snapshot
includes com.sun.media.* packages which are not yet part of OpenJFX
(at least I don´t think so, as my modules/media directory is empty).
Is there a reason for this?
  
  

Media has not yet been open-sourced, but that work is in progress.

-- Kevin


Robert Fisher wrote:


Hi everyone,
 
I´m trying to build a jar containing all sources for jfxrt.jar, so I

can attach it in Eclipse. For this I´ve added the following lines to
the root build.gradle:
 



build.gradle:
 
task jfxrtSources()
 
compileTargets{
 
...
 
def jfxrtSourcesTask = task("jfxrtSources$t.capital", type: Jar) {

 group = "Basic";
 description = "Creates the jfxrt-sources.jar for the $t.name
target";
 archiveName = "build/${t.name}-sdk/rt/lib/ext/jfxrt-sources.jar";
 includeEmptyDirs = false;
 from("modules/base/src/main/java",
  "modules/builders/src/main/java",
  "modules/controls/src/main/java",
  "modules/designTime/src/main/java",
  "modules/fxml/src/main/java",
  "modules/fxpackager/src/main/java",
  "modules/graphics/src/main/java",
  "modules/web/src/main/java");
 
 if (COMPILE_SWING) from ("modules/swing/src/main/java");

 if (COMPILE_SWT) from ("modules/swt/src/main/java");
 
 exclude(targetProperties.jfxrtJarExcludes);

}
jfxrtSources.dependsOn(jfxrtSourcesTask);
 
...
 
}



 
Is this the correct way to go about it?
 
I also noticed that the jfxrt.jar from the latest JDK1.8 snapshot

includes com.sun.media.* packages which are not yet part of OpenJFX
(at least I don´t think so, as my modules/media directory is empty).
Is there a reason for this?
 
Thanks in advance,

Rob
 
 
Mit freundlichen Grüßen

Best Regards

Dr. Robert Fisher


TESIS DYNAware
Technische Simulation Dynamischer Systeme GmbH
Baierbrunner Str. 15
D-81379 München
Tel: +49-89-747377-7440
Fax: +49-89-747377-99

http://www.tesis-dynaware.com
robert.fis...@tesis.de

Geschäftsführung / Board of Directors
Dr.-Ing. Cornelius Chucholowski - Dipl. Ing. Christian Zahn
Amtsgericht München, HRB 115649


TESIS DYNAware simulation software is in use at Audi, BMW, Ford,
MAGNA, MAN, VW and elsewhere.

Read more: http://www.tesis-dynaware.com/customers
  


  

Re: ConcurrentModificationException during controls test runs

[Kevin Rushforth]

Yes, Jennifer and I both saw this during integration testing. Jennifer 
also saw this when running the toys. She will file a bug.


-- Kevin


Richard Bair wrote:

Is anybody else seeing this?

javafx.scene.control.ComboBoxTest > test_rt31479 FAILED
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:2290)
at java.util.HashMap$EntryIterator.next(HashMap.java:2361)
at java.util.HashMap$EntryIterator.next(HashMap.java:2359)
at 
javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:280)
at 
javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:177)
at javafx.scene.Node.impl_processCSS(Node.java:8639)
at javafx.scene.Parent.impl_processCSS(Parent.java:1202)
at javafx.scene.control.Control.impl_processCSS(Control.java:863)
at javafx.scene.Parent.impl_processCSS(Parent.java:1217)
at 
javafx.scene.control.PopupControl$CSSBridge.impl_processCSS(PopupControl.java:1221)
at javafx.scene.Parent.impl_processCSS(Parent.java:1217)
at javafx.scene.Node.processCSS(Node.java:8571)
at javafx.scene.Scene.doCSSPass(Scene.java:538)
at javafx.scene.Scene.preferredSize(Scene.java:1562)
at javafx.scene.Scene.impl_preferredSize(Scene.java:1571)
at javafx.stage.Window$9.invalidated(Window.java:726)
at 
javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
at 
javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:141)
at javafx.stage.Window.setShowing(Window.java:800)
at javafx.stage.Window.show(Window.java:815)
at javafx.stage.PopupWindow.showImpl(PopupWindow.java:394)
at javafx.stage.PopupWindow.show(PopupWindow.java:368)
at 
com.sun.javafx.scene.control.skin.ComboBoxPopupControl.positionAndShowPopup(ComboBoxPopupControl.java:99)
at 
com.sun.javafx.scene.control.skin.ComboBoxPopupControl.show(ComboBoxPopupControl.java:79)
at 
com.sun.javafx.scene.control.skin.ComboBoxBaseSkin.handleControlPropertyChanged(ComboBoxBaseSkin.java:123)
at 
com.sun.javafx.scene.control.skin.ComboBoxListViewSkin.handleControlPropertyChanged(ComboBoxListViewSkin.java:219)
at 
com.sun.javafx.scene.control.skin.BehaviorSkinBase$2.call(BehaviorSkinBase.java:180)
at 
com.sun.javafx.scene.control.skin.BehaviorSkinBase$2.call(BehaviorSkinBase.java:177)
at 
com.sun.javafx.scene.control.MultiplePropertyChangeListenerHandler$1.changed(MultiplePropertyChangeListenerHandler.java:56)
at 
javafx.beans.value.WeakChangeListener.changed(WeakChangeListener.java:88)
at 
com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:176)
at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
at 
javafx.beans.property.ReadOnlyBooleanWrapper$ReadOnlyPropertyImpl.fireValueChangedEvent(ReadOnlyBooleanWrapper.java:179)
at 
javafx.beans.property.ReadOnlyBooleanWrapper$ReadOnlyPropertyImpl.access$100(ReadOnlyBooleanWrapper.java:148)
at 
javafx.beans.property.ReadOnlyBooleanWrapper.fireValueChangedEvent(ReadOnlyBooleanWrapper.java:144)
at 
javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
at 
javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:141)
at javafx.scene.control.ComboBoxBase.setShowing(ComboBoxBase.java:191)
at javafx.scene.control.ComboBoxBase.show(ComboBoxBase.java:393)
at 
javafx.scene.control.ComboBoxTest.test_rt31479(ComboBoxTest.java:1059)

  

Re: Java 8 b99 still missing samples

[Kevin Rushforth]

This is an issue for Debbie not for Nicolas, since the apps are not 
included in the release bundles that are being produced by the build.


RT-31410  was recently 
marked as fixed, but seems not to have completely fixed the problem. I 
filed a new issue for this, RT-31815 
.


As for 3DViewer, Debbie or Jasper could respond as to whether it is 
ready for release.


-- Kevin


Richard Bair wrote:

Nicolas, do you know what the issue is?

On Jul 19, 2013, at 7:02 PM, "John C. Turnbull"  wrote:

  

The JavaFX samples for Java 8 b99 still do not contain Ensemble8 or the 3D
Viewer.



When do you expect to include them in a build?



-jct

Re: glass.dll depends issue in windows8 at b97-b99

[Kevin Rushforth]

Are you sure you tried b99? This issue should be fixed now, and we have 
seen no other reports that it is still broken.


-- Kevin


向雅 wrote:

Hi,

3 builds both got this in notebook:
java.lang.UnsatisfiedLinkError: X:\JDK8\jre\bin\glass.dll: Can't find
dependent libraries

but in my pc, b96 seems works.

seems the world dead, only my case in here?:)

realy?
  

Re: API Change Proposal - Re: MSAA and Scene anti aliasing

[Kevin Rushforth]

+1 on having DISABLED be first.

-- Kevin


Richard Bair wrote:

Just to be picky, I would put DISABLED first in the list. It seems more consistent 
to have the only OFF mode to be first and then all the rest of the options (which 
happen to then have ordinals > 0) will be some form of ON mode.

Richard

On Jul 24, 2013, at 2:37 PM, Chien Yang  wrote:

  

Thank you for the feedback! We decided to drop DEFAULT in favor of BALANCED. So 
here is the revised SceneAntiAliasing enum entries:

public enum SceneAntiAliasing {
   BALANCED, // enables anti-aliasing using optimal system setting available 
that balances speed and quality
   DISABLED, // disables anti-aliasing
   FASTEST, // enables anti-aliasing using minimum system setting available 
that results in better frame rate
   NICEST // enables anti-aliasing using maximum system setting available that 
results in best visual quality
}

Thanks,
- Chien

On 7/23/2013 1:29 PM, Chien Yang wrote:


Hi all,

   We appreciate all the feedback you have contributed to this topic. After 
listening to the feedback and an internal discussion, we would like to propose 
a minor change to the API for supporting scene anti-aliasing. We intentionally 
choose not to expose the number of samples and techniques used in this release, 
but this doesn't preclude future addition when the time is right for more 
options. This change will be tracked by RT-31878 
(https://javafx-jira.kenai.com/browse/RT-31878):

Anti-aliasing API Change Proposal:

Constructors remove:
public Scene(Parent root, double width, double height, boolean depthBuffer, 
boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer, 
boolean antiAliasing)

Constructor add:
public Scene(Parent root, double width, double height, boolean depthBuffer, 
SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer, 
SceneAntiAliasing antiAliasing)

Note:The antiAliasing argument will be used if the underlying graphics driver 
has anti-aliasing support.

Where SceneAntiAliasing is an enum with the following entries at the moment:

public enum SceneAntiAliasing {
   DISABLED, // disables anti-aliasing
   DEFAULT, // enables anti-aliasing using a default system setting available 
that balances speed and quality
   FASTEST, // enables anti-aliasing using minimum system setting available 
that results in better frame rate
   NICEST // enables anti-aliasing using maximum system setting available that 
results in best visual quality
}

Thanks,
- Chien
  


  

Re: jfxrt.jar - is it platform specific?

[Kevin Rushforth]

Yes, jfxrt.jar is platform-specific. On the desktop there are 
platform-specific glass and Prism classes (not sure about the WebKit 
classes). On embedded platforms (Linux-arm, IOS, Android) there are many 
differences.


-- Kevin


Daniel Zwolenski wrote:

Obviously there are native libs (dlls, etc) that JFX uses that are outside
of the jfxrt.jar.

But is the actual jfxrt.jar produced by the build generic and able to be
used on any platform (so long as the natives are also present) or is it
platform specific itself?

We are getting close to the ios/backport stuff working (as well as it can
at this stage) and are aiming to start putting stuff in Maven soon. Just
want to make sure I get the separations as clean as possible because once
it's in Central it doesn't ever leave.

Cheers.
  

Re: Java 8 release plan

[Kevin Rushforth]

We release JavaFX 8 EA as part of the weekly JDK builds posted on 
java.net. We use the same build numbering scheme as does the JDK, so JDK 
8-b99 contains FX 8-b99.


-- Kevin


Peter Penzov wrote:

Hi,
   I started to develop Java 8 application using JVM 8. I saw that many new
bugs related to JavaFX are fixed and added to OpenJDK 8.
   Do you include these new fixes into the latest Java 8 beta releases
which are published every week? It's very important for me to know because
my application depends on JVM 8.

Regards
  

Re: JavaFX 2 memory leaks in StyleManager (making FX2 completely unusable for application development)

[Kevin Rushforth]

What version of JDK 7u/FX 2.2.x is this reproduced in? Have you tried 
this with a recent build of JDK 7u40? There is a vanishingly small 
window to get changes into 7u40 / FX 2.2.40 which is scheduled for 
release in the first half of September. The next opportunity would be 
January.


-- Kevin


Tom Schindl wrote:

[resending because mail was blocked yesterday because of included images]
Hi,

I've been debugging a JavaFX application with a customer and we've found
a tremendous memory leak in StyleManager when using icons.

This bug makes JavaFX 2.x completely unusable because the application is
using up to 1.5GB and more within a few mintues! Has anyone seen this
and if I file a bug could I expect a bugfix in FX2?

The screenshots from the Memory Analyzer can be seen at:
http://www.efxclipse.org/image001.png
http://www.efxclipse.org/image002.png

Tom
  

Re: API Change Proposal - Re: MSAA and Scene anti aliasing

[Kevin Rushforth]

This seems cleaner in terms of extensibility. I think we can wait on 
adding anything other than the public static finals for this release, 
but plan to extend it using something like what Jim suggests.


-- Kevin


Richard Bair wrote:

Personally I liked this approach. It was like an enum in ease of use but much 
more extensible in the future when we add more anti-aliasing types and twiddles.

Richard

On Jul 31, 2013, at 1:36 PM, Jim Graham  wrote:

  

D'oh!  I knew I should have been checking this list a bit.  I hope this isn't 
too late to have any impact...

As an intermediate solution this is fine, but when we want to get into 
providing settings for MSAA and FSAA and other algorithms I think classes are 
more flexible than enums.  How about this solution:

package javafx.?

public class SceneAntialiasing {
   public static final SceneAntialiasing DISABLED;
   public static final SceneAntialiasing BALANCED;
   public static final SceneAntialiasing FASTEST;
   public static final SceneAntialiasing NICEST;

   public static SceneAntialiasing[] getAvailableTechniques() { }

   SceneAntialiasing() { /* package private constructor! */ }
}

public class MsaaAntialiasing extends SceneAntialiasing {
   MSaaAntialiasing(int numsamp) { /* package private */ }
   public int getNumSamples();
}

public class FsaaAntialiasing extends SceneAntialiasing {
   FsaaAntialiasing(int numsamp) { /* package private */ }
   public int getNumSamples();
}

Note that there are ways for the system to construct these objects without 
providing public constructors so that these become statically defined by the 
system.

What about Anisotropic filtering?  Is that considered a form of AA, or an 
option on top of AA?

...jim

On 7/24/2013 3:07 PM, Chien Yang wrote:


Thanks for the help! I was of 2 minds about it; alphabetical or logical.

public enum SceneAntiAliasing {
   DISABLED, // disables anti-aliasing
   BALANCED, // enables anti-aliasing using optimal system setting available 
that balances speed and quality
   FASTEST, // enables anti-aliasing using minimum system setting available 
that results in better frame rate
   NICEST // enables anti-aliasing using maximum system setting available that 
results in best visual quality
}

- Chien

On 7/24/2013 2:49 PM, Richard Bair wrote:
  

Just to be picky, I would put DISABLED first in the list. It seems more consistent 
to have the only OFF mode to be first and then all the rest of the options (which 
happen to then have ordinals > 0) will be some form of ON mode.

Richard

On Jul 24, 2013, at 2:37 PM, Chien Yang  wrote:



Thank you for the feedback! We decided to drop DEFAULT in favor of BALANCED. So 
here is the revised SceneAntiAliasing enum entries:

public enum SceneAntiAliasing {
   BALANCED, // enables anti-aliasing using optimal system setting available 
that balances speed and quality
   DISABLED, // disables anti-aliasing
   FASTEST, // enables anti-aliasing using minimum system setting available 
that results in better frame rate
   NICEST // enables anti-aliasing using maximum system setting available that 
results in best visual quality
}

Thanks,
- Chien

On 7/23/2013 1:29 PM, Chien Yang wrote:
  

Hi all,

   We appreciate all the feedback you have contributed to this topic. After 
listening to the feedback and an internal discussion, we would like to propose 
a minor change to the API for supporting scene anti-aliasing. We intentionally 
choose not to expose the number of samples and techniques used in this release, 
but this doesn't preclude future addition when the time is right for more 
options. This change will be tracked by RT-31878 
(https://javafx-jira.kenai.com/browse/RT-31878):

Anti-aliasing API Change Proposal:

Constructors remove:
public Scene(Parent root, double width, double height, boolean depthBuffer, 
boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer, 
boolean antiAliasing)

Constructor add:
public Scene(Parent root, double width, double height, boolean depthBuffer, 
SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer, 
SceneAntiAliasing antiAliasing)

Note:The antiAliasing argument will be used if the underlying graphics driver 
has anti-aliasing support.

Where SceneAntiAliasing is an enum with the following entries at the moment:

public enum SceneAntiAliasing {
   DISABLED, // disables anti-aliasing
   DEFAULT, // enables anti-aliasing using a default system setting available 
that balances speed and quality
   FASTEST, // enables anti-aliasing using minimum system setting available 
that results in better frame rate
   NICEST // enables anti-aliasing using maximum system setting available that 
results in best visual quality
}

Thanks,
- Chien



  

Re: JavaFX 2 memory leaks in StyleManager (making FX2 completely unusable for application development)

[Kevin Rushforth]

Hi Tom,

I have raised the priority to P2 and assigned it to Jonathan to evaluate.

-- Kevin


Tom Schindl wrote:

Hi Kevin,

I have created a sample application and filed
https://javafx-jira.kenai.com/browse/RT-32087

I've uploaded the sources, memory dumps, ... to
http://downloads.efxclipse.org/memoryleak/.

There are 2 remarkable things if you look at the memory screenshots.

memory2.png: Runs the application without the CSS-Images so one can see
 that the application after sometime holds > 9.000
 Cell-Objects who naturally holds other node objects

memory1.png: Shows that the CSS is loading image instance for each and
 every ImageView although we are only one image-url!

So after this test I think the CSSEngine is not really leaking images
but is loading too many of them although it could reuse them. The really
leaking component is ListView which leaks all its list cells.

The good thing is that FX8 does not show this problems (no image
duplication, no leaked cells) but FX8 is more than 6 months away and
those two problems above make FX2.2 completely unusable (one can
workaround the CSS-Bug by simply *not* useing Images in CSS) but for
ListCell one there's no work-around at all available (beside not using
ListView)!

Tom

On 30.07.13 16:28, Kevin Rushforth wrote:
  

What version of JDK 7u/FX 2.2.x is this reproduced in? Have you tried
this with a recent build of JDK 7u40? There is a vanishingly small
window to get changes into 7u40 / FX 2.2.40 which is scheduled for
release in the first half of September. The next opportunity would be
January.

-- Kevin


Tom Schindl wrote:


[resending because mail was blocked yesterday because of included images]
Hi,

I've been debugging a JavaFX application with a customer and we've found
a tremendous memory leak in StyleManager when using icons.

This bug makes JavaFX 2.x completely unusable because the application is
using up to 1.5GB and more within a few mintues! Has anyone seen this
and if I file a bug could I expect a bugfix in FX2?

The screenshots from the Memory Analyzer can be seen at:
http://www.efxclipse.org/image001.png
http://www.efxclipse.org/image002.png

Tom
  
  


  

Re: exception

[Kevin Rushforth]

This suggests a threading problem, as also commented in 
https://javafx-jira.kenai.com/browse/RT-27655 (to which you added your 
stack trace). Can you double-check that you never touch a live node 
(that is, a node attached to a Scene) from any thread other than the FX 
Application thread?


-- Kevin


Peter Mathia wrote:

Hi everyone,
is anybody able to tell me something about this error without posting my
code? I use javaFX 2.2 to develop Gantt chart visualizer. Sometimes I get
this exceptions when I want to update GUI in Platform.runLater thread.
The chart has Canvas as a background and every Task in chart is represented
by a Rectangle (drag/resize)...
Thank you!

Peter

java.lang.NullPointerException
at com.sun.javafx.sg.prism.NGCanvas$RenderBuf.validate(NGCanvas.java:76)
at com.sun.javafx.sg.prism.NGCanvas.initCanvas(NGCanvas.java:336)
at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:316)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at
com.sun.javafx.sg.prism.NGNode$CacheFilter.impl_renderNodeToScreen(NGNode.java:712)
at com.sun.javafx.sg.BaseCacheFilter.render(BaseCacheFilter.java:168)
at com.sun.javafx.sg.prism.NGNode$CacheFilter.render(NGNode.java:660)
at com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:487)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:183)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:429)
at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:320)
at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:346)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:179)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:429)
at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:320)
at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:346)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:179)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39)
at com.sun.javafx.sg.BaseNode.render(BaseNo

Re: CFV: New OpenJFX Committer: Seeon Birger

[Kevin Rushforth]

Vote: yes


David Hill wrote:

I hereby nominate Seeon Birger to OpenJFX Committer.
Seeon is a member of the Embedded Device team, which means he works 
across various aspects of the platform, but in particular, Lens and 
Virtual Keyboard.


His recent work can be seen here:

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

Votes are due by Aug 21, 2013.

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


For Lazy Consensus voting instructions, see [2].

Thanks,
Dave

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

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

Re: CFV: New OpenJFX Committer:Daniel Blaukopf

[Kevin Rushforth]

Vote: yes


David Hill wrote:

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


His recent work can be seen here:

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

Votes are due by Aug 21, 2013.

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


For Lazy Consensus voting instructions, see [2].

Thanks,
David

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

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

Re: JavaFX Media issues

[Kevin Rushforth]

There is already bug filed to restore the FX Media APIs to the FX 8 API 
docs:


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

-- Kevin



Joe McGlynn wrote:

I don't know why FX Media isn't in the FX 8 API docs, but that's clearly an 
error.  Please file a bug on that.

In the meantime, you should look at the FX 2 media docs, there isn't a lot of 
change from FX2 media in FX8.  Buffering and streaming (HTTP Live Streaming) 
are both supported, as is playback from a URL.


On Aug 8, 2013, at 1:31 PM, Felix Bembrick  wrote:

  

I am having a look at JavaFX media support and have a couple of questions:

1. It seems that the only way to load media files is by specifying a source
such as a file path etc.  This is not going to work well for me as all of
my application's content (which includes data, digital assets, media etc.)
is stored in a database on the server and is loaded through an IO stream.
Why doesn't Media support loading of files through a stream?  That would
seem like a common use case to me!

2. I am unable to locate any reference to JavaFX Media in the JavaDocs for
JDK 8 which I found here:

http://download.java.net/jdk8/jfxdocs/index.html

Is this just a glitch?

3. Is buffering of media something planned for the future in JavaFX?

4. What about live streaming of media content?

Thanks,

Felix



  

Re: CFV: New OpenJFX Committer: Chien Yang

[Kevin Rushforth]

Vote: Yes


Artem Ananiev wrote:


I hereby nominate Chien Yang to OpenJFX Committer.

Chien is a member of JavaFX graphics group at Oracle. Here is the list 
of his fixes and reviews:


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

Votes are due by Aug 29, 2013.

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


For Lazy Consensus voting instructions, see [2].

Thanks,

Artem

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

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

Re: CFV: New OpenJFX Committer: Alexander Zvegintsev

[Kevin Rushforth]

Vote: Yes


Artem Ananiev wrote:


I hereby nominate Alexander Zvegintsev (OpenJDK user name: alexz) to 
OpenJFX Committer.


Alexander is a primary maintainer of Gtk port of Glass (windowing 
toolkit for JavaFX), and also an active contributor to other Glass 
platforms. Here is the list of Alexander's changes so far:


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

Votes are due by Aug 29, 2013.

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


For Lazy Consensus voting instructions, see [2].

Thanks,

Artem

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

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

Re: CFV: New OpenJFX Committer: Felipe Heidrich

[Kevin Rushforth]

Vote: Yes

Artem Ananiev wrote:


I hereby nominate Felipe Heidrich (OpenJDK user name: felipe) to 
OpenJFX Committer.


Felipe is a member of JavaFX graphics group at Oracle. He is mostly 
responsible for JavaFX text and fonts, but not only for that. Here is 
the list of changesets he has committed last month:


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

Total number of fixes that can be found in mercurial history:

  hg log -u felipe

is far more than 32, which is sufficient for Reviewer nomination, but 
OpenJFX project doesn't have this role.


Votes are due by Aug 29, 2013.

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


For Lazy Consensus voting instructions, see [2].

Thanks,

Artem

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

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

Re: CFV: New OpenJFX Committer: Mick Fleming

[Kevin Rushforth]

Vote: Yes

Artem Ananiev wrote:


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


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


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

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


  hg log -u mickf

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


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


For Lazy Consensus voting instructions, see [2].

Thanks,

Artem

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

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

Re: Summary of new features in JavaFX 8?

[Kevin Rushforth]

https://javafx-jira.kenai.com/browse/RT-23908 (Video capture support), which is 
resolved.
If you read the comments, audio capturing is supported as well.


That JIRA refers to a test being implemented, which may not be accurate 
anyway since there is no product feature to "test".


You will probably want to filter out the "Tests" and "Docs" components 
(and maybe Samples, too, depending on what you are looking for) in your 
JIRA query.


-- Kevin



Christian Schudt wrote:

Thanks for the list! Very interesting.

One thing that got my attention is this issue:

https://javafx-jira.kenai.com/browse/RT-23908 (Video capture support), which is 
resolved.
If you read the comments, audio capturing is supported as well.

Does that mean, that the second highest voted feature for Lombard is resolved 
as well?
https://javafx-jira.kenai.com/browse/RT-3458 (Camera and Microphone)

Thanks for clarification!


Am 17.08.2013 um 20:52 schrieb John Smith:

  

Here is a link to the current jira generated release notes for JavaFX 8 (it's a 
humongous list).

https://javafx-jira.kenai.com/secure/ReleaseNote.jspa?projectId=10040&version=10380

The majority of stuff in the jira generated release notes is implemented, but 
some is not and will probably be moved to a future release.

In terms of the terminology used, I think a feature is major new functionality 
usually called out on a product requirements document somewhere and a tweak (of 
which there are hundreds) is a minor feature (though I don't think it's a hard 
and fast rule and a little arbitrary - some features are pretty minor and some 
tweaks are pretty important).

Some major features missing from your list Felix:
 multi-threaded performance improvements 
 right -> left language support

 HiDPI display support (though that might also be in some upcoming Java 2.2 
release)
 swing components in JavaFX
 increased support for new w3c standards in WebView (e.g. websockets)
 @font-face support in css (I guess this one might be termed a tweak)
 ATI/AMD GPU acceleration on Linux

I think there is also an intention for an official embedded release for Java 8 
that will include JavaFX in the new compact profile setup.

From a developer point of view, I think the big news is open sourcing (except 
for the media and browser plugin components) along with the new repository 
layout and relatively simple gradle build process - so potentially JavaFX can 
now be included in OpenJDK and custom JDK builds, not just Oracle JDK builds.

My favorite feature of all time is that with Java 8, JavaFX is properly bundled 
into Oracle Java and on the default class path.   So I don't have to keep 
explaining to people how to get JavaFX to run in their environment.  Hopefully, 
all of the standard OpenJDK 8 builds and distributions will follow Oracle's 
lead here and correctly bundle JavaFX into their distributions.

--

Here is a result of a jira query on fixed features for JavaFX 8.

RT-30831
Unsorted mode in the SortedList
RT-30236
Open WebView sources
RT-29848
Add a static GridPane.setFillWidth(Node, boolean) method
RT-29834
Move JSObject into javafx-ui-common
RT-28817
Add explicit dispose() method to MediaPlayer
RT-28499
WebView doesnot support HTML5 
RT-25759
ObjectExpression does not have asString() method
RT-25644
Implement WebSocket traffic tunneling through HTTP(S) proxies that require 
authentication
RT-25606
Port 3D features from demo/experimental repository to FX 8 3D sandbox
RT-25559
In FXML, Allow event handlers to come from the namespace
RT-24712
Support ATI/AMD GPU on the Linux platform
RT-24655
Need to support movable Camera
RT-24654
Need to include lighting and material support for 3D primitives rendering
RT-24651
Need clean semantic for 2D/3D scenes mixing
RT-24648
Define supported Linux configurations
RT-24644
Support Mesh and Predefined 3D Shapes
RT-24506
Public API for Region backgrounds and borders
RT-24041
SQE: Hi-DPI display support
RT-24014
FX needs to support a subset of the JRE supported systems
RT-24013
Multi-Core scalability
RT-24012
Text performance of the hardware pipeline must be equal or better than the 
software pipeline
RT-24009
Support for Hi-DPI displays
RT-24008
3D attributes
RT-23911
SQE: Allow 3D shapes
RT-23909
SQE: 3D attributes
RT-23908
SQE: Video capture support
RT-23907
SQE: Improve HTML 5 API and tags support
RT-23904
SQE: Tree table control
RT-23903
SQE: Public API for CSS Structure
RT-23901
SQE: Enable component orientation
RT-23898
SQE: Printing support
RT-23897
SQE: Support bi-directional text
RT-23896
SQE:Provide support for complex characters
RT-23895
SQE: i10N: Java FX must be localized in all the different languages as 
supported by the JRE.
RT-23894
SQE:

Re: JavaFX 2.2.40 FCS?

[Kevin Rushforth]

Correct. There might be a respin in case of a release stopper, but it's 
otherwise done.


-- Kevin


Scott Palmer wrote:

I see the latest jdk7 "EA" build is now labelled "FCS".. I guess that means
it's a done deal and is just soaking a bit before being put up on oracle.com?

Scott
  

Re: JavaFX 3D Material

[Kevin Rushforth]

Depending on circumstances, both REPEAT and CLAMP_TO_EDGE are needed.


We do not plan to add this control in FX 8, but will consider doing so 
in a future release.


-- Kevin


Kensuke Matsuzaki wrote:

Hi Chien,

Thank you.

IMPOV, the patch attached RT-29527 isn't enough.
Depending on circumstances, both REPEAT and CLAMP_TO_EDGE are needed.

Kensuke

2013/8/28 Chien Yang :
  

Hi Kensuke,

Both are known issues that we have tentative plan to address in FX 8.
Here are the links for you to track their status:

https://javafx-jira.kenai.com/browse/RT-29527
https://javafx-jira.kenai.com/browse/RT-28874

BTW, please note the limitation of applying opacity on Group node with 3D
transform children or 3D shapes:

 * There is a known limitation of mixing opacity < 1.0 with a 3D
Transform.
 * Opacity/Blending is essentially a 2D image operation. The result of
 * an opacity < 1.0 set on a {@link Group} node with 3D transformed
children
 * will cause its children to be rendered in order without Z-buffering
 * applied between those children.

Thanks,
- Chien


On 8/27/2013 1:10 AM, Kensuke Matsuzaki wrote:


Hi,

- Is there any way to set a texture WrapMode?
Default settings are hard-coded to WrapMode.CLAMP_TO_EDGE
in com.sun.prism.d3d.D3DResourceFactory. Can I set this to another mode?

- How to add transparent TriangleMesh?
When a scere is below
* Scene
   * Group
 * MeshView
 * MeshView
 * MeshView

"MeshView.setOpacity(0.5)" and
"PhongMaterial.setSpecularColor(Color.rgb(30, 30, 30, 0.5))" do not
affect,
and "Group.setOpacity(0.5)" seems broken.

Thanks in advance.

Kensuke
  

Re: FW: Media classes still missing from JavaDoc

[Kevin Rushforth]

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

I pushed a fix earlier today. It will be in b107.

-- Kevin


John C. Turnbull wrote:

Sorry to harp on about this but the media classes are missing from b106
JavaDoc as well in case Oracle is not aware of this.

 

From: John C. Turnbull [mailto:ozem...@ozemail.com.au] 
Sent: Monday, 9 September 2013 20:31

To: 'openjfx-dev@openjdk.java.net'
Subject: Media classes still missing from JavaDoc

 


Just FYI, media classes are still missing from the JavaDoc for JavaFX in JDK
8 b105.

 


-jct

  

Re: JavaFX applications turning to "black screen" after some time

[Kevin Rushforth]

Did the system go into screen lock during that time? If so, then this is:

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

Otherwise it sounds like a new bug.

-- Kevin


John C. Turnbull wrote:

I am not sure if it is a known issue but any JavaFX application I run and
then leave minimised for some time (say 15mins+) and then restore will have
an entirely black window with nothing actually visible.  This is on Windows
7 and Scene Builder curiously seems to be immune to this problem.

 


Any ideas why this is happening?  It looks like an off-screen buffer being
lost (as it resembles the behaviour I used to see with Swing VolatileImage
when the contents were lost)?

 


Is there any way to programmatically avoid this?

 


Thanks,

 


-jct

  

Re: JavaFX applications turning to "black screen" after some time

[Kevin Rushforth]

What build are you using? There were several dirty region optimization 
(dirtyopts) bugs in b104 that have since been fixed. To see whether this 
is the case, you can try:


   java -Dprism.dirtyopts=false ...

-- Kevin


John C. Turnbull wrote:

Hmm, I am not sure that is the same issue.  That issue seems to be related
to artefacts appearing after screen lock but what I am seeing is a totally
black window and it doesn't need a locked screen to make it happen.

And at least for me, I have never seen this with Scene Builder although I
note that you have observed this.

-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Jerome Cambon
Sent: Tuesday, 10 September 2013 17:18
To: openjfx-dev@openjdk.java.net
Subject: Re: JavaFX applications turning to "black screen" after some time


Seems to be related to this issue:
https://javafx-jira.kenai.com/browse/RT-30362

And no, unfortunately Scene Builder is not always immune to this, I got it
with SB regularly

HTH,
Jerome


On 9/10/13 7:55 AM, John C. Turnbull wrote:
  
I am not sure if it is a known issue but any JavaFX application I run 
and then leave minimised for some time (say 15mins+) and then restore 
will have an entirely black window with nothing actually visible.  
This is on Windows

7 and Scene Builder curiously seems to be immune to this problem.

  

Any ideas why this is happening?  It looks like an off-screen buffer 
being lost (as it resembles the behaviour I used to see with Swing 
VolatileImage when the contents were lost)?


  


Is there any way to programmatically avoid this?

  


Thanks,

  


-jct




  

Re: JavaFX applications turning to "black screen" after some time

[Kevin Rushforth]

(I guess I should read the whole thread before replying...please ignore 
my already-answered questions in earlier messages)


Can you file a JIRA for this issue? Also, can you comment as to whether 
disabling prism.dirtyopts helps?


Thanks.

-- Kevin


John C. Turnbull wrote:

I notice this issue even with FX 8 applications and b106.  And when the
issue occurs it doesn't matter how long I wait, the window stays black
permanently.

Again though I have never seen this with Scene Builder so it seems
individual results vary.

-Original Message-
From: Jerome Cambon [mailto:jerome.cam...@oracle.com] 
Sent: Tuesday, 10 September 2013 18:01

To: John C. Turnbull
Cc: openjfx-dev@openjdk.java.net
Subject: Re: JavaFX applications turning to "black screen" after some time

And I realize you are certainly on Fx 2.2, since although we are working
hard on it, SB on Fx 8 is not yet avalaible :-)
RT-30362 is specific to Fx 8.0

Using SB 1.1 (so Fx 2.2), I also notice your issue (entirely black
window) on Win 7 when SB is minimized for a while, then restored.
Generally the window  come back to a normal state after few seconds,
sometimes more (around 1mn).

I think this deserve a new Jira (for reference), I don't think there is one
related to that for Fx 2.2.

Thanks
Jerome


On 9/10/13 9:22 AM, John C. Turnbull wrote:
  
Hmm, I am not sure that is the same issue.  That issue seems to be 
related to artefacts appearing after screen lock but what I am seeing 
is a totally black window and it doesn't need a locked screen to make it


happen.
  
And at least for me, I have never seen this with Scene Builder 
although I note that you have observed this.


-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Jerome 
Cambon

Sent: Tuesday, 10 September 2013 17:18
To: openjfx-dev@openjdk.java.net
Subject: Re: JavaFX applications turning to "black screen" after some 
time



Seems to be related to this issue:
https://javafx-jira.kenai.com/browse/RT-30362

And no, unfortunately Scene Builder is not always immune to this, I 
got it with SB regularly


HTH,
Jerome


On 9/10/13 7:55 AM, John C. Turnbull wrote:

I am not sure if it is a known issue but any JavaFX application I run 
and then leave minimised for some time (say 15mins+) and then restore 
will have an entirely black window with nothing actually visible.

This is on Windows
7 and Scene Builder curiously seems to be immune to this problem.

   

Any ideas why this is happening?  It looks like an off-screen buffer 
being lost (as it resembles the behaviour I used to see with Swing 
VolatileImage when the contents were lost)?


   


Is there any way to programmatically avoid this?

   


Thanks,

   


-jct

  


  

Re: 3D scene antialiasing

[Kevin Rushforth]

Yes, it should be working for both D3D (as of b105) and OpenGL (earlier 
than that).


-- Kevin


John C. Turnbull wrote:

Could someone please let me know if support for 3D scene antialiasing is
supposed to be working in JDK8 b106?

 


If not, when is this feature expected to be implemented?

 


Thanks,

 


-jct

  

Re: Make SubScene Resizable (RT-31377)

[Kevin Rushforth]

I like #2 for the ease of use.

-- Kevin


Pavel Safrata wrote:

Hello,
we want to make SubScene resizable (reporting min/pref/max sizes 
according to its root) for it to behave nicely when placed in layout ( 
https://javafx-jira.kenai.com/browse/RT-31377 ). For the main driver 
of SubScene's existence - 2D overlays over 3D content - this makes 
perfect sense. However, there are use-cases where the fixed size is 
needed. Mainly, every SubScene with 3D content probably wants the 
fixed size as the content bounds are not really meaningful after the 
perspective projection. So, we need to support both resizable and 
non-resizable SubScene.


There are two basic options:

1. Follow the pattern used in layouts. As SubScene is not a layout 
class (doesn't inherit from Region), this would mean adding the six 
methods ( set{Min|Pref|Max}{Width|Height} ) and duplicating the 
Region's USE_COMPUTED_SIZE constant.


+ consistent with layouts
- duplicated API
- user needs six calls to make sure the SubScene has fixed size

2. Add an isResizable constructor argument, then just make the 
SubScene report root's min/pref/max sizes in the resizable case.


+ easy to use the SubScene in the fixed-size manner (and resizable, too)
+ small API change
- probably an unfamiliar pattern we don't have elsewhere (but, 
SubScene is a pretty unique node)


What do you think?

Thanks,
Pavel

Re: Make SubScene Resizable (RT-31377)

[Kevin Rushforth]

Btw, making ImageView and MediaView resizable is filed as 
https://javafx-jira.kenai.com/browse/RT-10610


-- Kevin


John Hendrikx wrote:
+1 on the ImageView case... getting ImageViews to resize properly, 
like a Button or other node would, is tricky and often gives 
unexpected results or doesn't behave the same in all cases.  A custom 
Wrapper class mitigates the problem somewhat, but I can't help 
thinking, why isn't there a proper resizable Image node that I can 
dump in any layout I want?


On 17/09/2013 16:59, Richard Bair wrote:
Personally I wish that it were possible to use pattern #2 with 
Rectangle, ImageView, and a bunch of others as well. Anything that 
*could* be resizable should have an option to be resizable. Heck, I 
wish it were possible to turn resizable on/off dynamically for 
SubScene or the others, not just an immutable property.


But an immutable property with a constructor to set it is a good 
first step (especially since we don't have time in this release to do 
anything more comprehensive or radical).


Richard

On Sep 17, 2013, at 1:15 AM, Pavel Safrata  
wrote:



Hello,
we want to make SubScene resizable (reporting min/pref/max sizes 
according to its root) for it to behave nicely when placed in layout 
( https://javafx-jira.kenai.com/browse/RT-31377 ). For the main 
driver of SubScene's existence - 2D overlays over 3D content - this 
makes perfect sense. However, there are use-cases where the fixed 
size is needed. Mainly, every SubScene with 3D content probably 
wants the fixed size as the content bounds are not really meaningful 
after the perspective projection. So, we need to support both 
resizable and non-resizable SubScene.


There are two basic options:

1. Follow the pattern used in layouts. As SubScene is not a layout 
class (doesn't inherit from Region), this would mean adding the six 
methods ( set{Min|Pref|Max}{Width|Height} ) and duplicating the 
Region's USE_COMPUTED_SIZE constant.


+ consistent with layouts
- duplicated API
- user needs six calls to make sure the SubScene has fixed size

2. Add an isResizable constructor argument, then just make the 
SubScene report root's min/pref/max sizes in the resizable case.


+ easy to use the SubScene in the fixed-size manner (and resizable, 
too)

+ small API change
- probably an unfamiliar pattern we don't have elsewhere (but, 
SubScene is a pretty unique node)


What do you think?

Thanks,
Pavel

Re: JavaFX 3D Issues reported in April

[Kevin Rushforth]

Yes.

User-defined normals: RT-29012 


More than 3 lights: RT-26462 

-- Kevin


Richard Bair wrote:

Do we have feature requests filed for overcoming these limitations?

On Sep 26, 2013, at 2:18 PM, Joseph Andresen  wrote:

  
The max number of lights on a node can only be 3, that is a limitation. Not having normals is also a limitation, not a bug. 


Chien can comment on the rest.

On Sep 26, 2013, at 12:54 PM, Richard Bair  wrote:



Hi guys,

I was just going through old email after JavaOne, and noticed one about bugs 
found with JavaFX 3D:

http://www.spanglefish.com/dmsconsulting/index.asp?pageid=469276

Chien, can you go through this list of issues and make sure everything is 
accounted for (either fixed or entered into JIRA)?

Thanks
Richard
  


  

Re: Seeing test failures in graphics scrum for ListViewKeyInputTest on Mac

[Kevin Rushforth]

Yes, this is a known issue:  https://javafx-jira.kenai.com/browse/RT-33015

-- Kevin


Richard Bair wrote:

Is anybody else seeing these? Have we seen them on hudson?

javafx.scene.control.ListViewKeyInputTest > test_rt21375_scenario_2_down FAILED
java.lang.AssertionError: expected:<3> but was:<5>
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:126)
at org.junit.Assert.assertEquals(Assert.java:470)
at org.junit.Assert.assertEquals(Assert.java:454)
at 
javafx.scene.control.ListViewKeyInputTest.test_rt21375_scenario_2_down(ListViewKeyInputTest.java:1425)

javafx.scene.control.ListViewKeyInputTest > test_rt21375_scenario_3_down FAILED
java.lang.AssertionError: expected:<4> but was:<5>
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:126)
at org.junit.Assert.assertEquals(Assert.java:470)
at org.junit.Assert.assertEquals(Assert.java:454)
at 
javafx.scene.control.ListViewKeyInputTest.test_rt21375_scenario_3_down(ListViewKeyInputTest.java:1446)

(16 failures in total)

Richard

Re: Seeing test failures in graphics scrum for ListViewKeyInputTest on Mac

[Kevin Rushforth]

And I see I'm a bit too late with this information. Thanks for fixing 
it, Richard!


-- Kevin


Kevin Rushforth wrote:
Yes, this is a known issue:  
https://javafx-jira.kenai.com/browse/RT-33015


-- Kevin


Richard Bair wrote:

Is anybody else seeing these? Have we seen them on hudson?

javafx.scene.control.ListViewKeyInputTest > 
test_rt21375_scenario_2_down FAILED

java.lang.AssertionError: expected:<3> but was:<5>
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:126)
at org.junit.Assert.assertEquals(Assert.java:470)
at org.junit.Assert.assertEquals(Assert.java:454)
at 
javafx.scene.control.ListViewKeyInputTest.test_rt21375_scenario_2_down(ListViewKeyInputTest.java:1425) 



javafx.scene.control.ListViewKeyInputTest > 
test_rt21375_scenario_3_down FAILED

java.lang.AssertionError: expected:<4> but was:<5>
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:126)
at org.junit.Assert.assertEquals(Assert.java:470)
at org.junit.Assert.assertEquals(Assert.java:454)
at 
javafx.scene.control.ListViewKeyInputTest.test_rt21375_scenario_3_down(ListViewKeyInputTest.java:1446) 



(16 failures in total)

Richard

Re: How do non-authors report bugs?

[Kevin Rushforth]

FX does not use JBS -- we have a separate JIRA instance. Your question 
is probably best asked on an OpenJDK alias.


-- Kevin


Pete Brunet wrote:

For those without JBS accounts what is the right web site to use to
report bugs?
  

Re: CFV: New OpenJDK Committer: Lisa Selle

[Kevin Rushforth]

Vote: yes

Artem Ananiev wrote:


I hereby nominate Lisa Selle to OpenJFX Committer.

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


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

Incomplete list is also available by the following link:

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

Votes are due to Oct 09, 2013.

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


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


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

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

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

Thanks,

Artem

Re: CFV: New OpenJFX Committer: Yao Wang

[Kevin Rushforth]

Vote: yes


Artem Ananiev wrote:


I hereby nominate Yao Wang to OpenJFX Committer.

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


  hg log -u "Yao Wang"

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


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

Votes are due by Oct 09, 2013.

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


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


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

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

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

Thanks,

Artem

Re: CFV: New OpenJFX Committer: Joseph Andresen

[Kevin Rushforth]

Vote: yes

Artem Ananiev wrote:


I hereby nominate Joe Andresen to OpenJFX Committer.

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


hg log -u "Joseph Andresen"

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


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


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

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

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

Thanks,

Artem

Compile error building FX with latest JDK

[Kevin Rushforth]

All,

There is a bug in JDK 8, introduced in b108, that will cause a clean 
build of FX to fail.


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

It is expected that this will be fixed in b110.

Until then, you can either stick with an older JDK, or use the following 
workaround, to compile the buildSrc part of the project with an older JDK:


   # point to older JDK
   gradle clean
   # point to latest JDK
   gradle

-- Kevin

Re: Bounds constructor validation

[Kevin Rushforth]

Note that a negative width or height is considered empty (see 
Bounds.isEmpty()) so it might break something if you couldn't constuct 
such a bounds.


-- Kevin


Richard Bair wrote:

Hi,

I'm looking at https://javafx-jira.kenai.com/browse/RT-23446, where the 
argument is made that the width / height of a node (specifically, a Region's 
prefWidth, minWidth, maxWidth, prefHeight, minHeight, maxHeight) should never 
be negative. While looking at this, I noticed that in Node, the prefWidth 
method relies on the layoutBounds.getWidth(). However, the Bounds class itself 
does not appear to do any validation of the parameters passed to the Bounds. 
There are no checks for NaN, and no checks for negative width, height, depth.

Is there any reason why we should allow NaN, or negative width / height / depth 
for Bounds?

Richard

Re: Cannot compile following the OpenJFX instructions at https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX

[Kevin Rushforth]

There is a known bug introduced in JDK 8 b108. See:

http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-October/010592.html

It is fixed in b110.

-- Kevin


Oscar Vargas Torres wrote:

This is the error I keep getting:

http://pastie.org/8377161
I am using Ubuntu Linux 13.04 64 bits. I have installed jdk8 b109 in my
machine. I have tried for several hours now. I need some guidance!!

What I understand is that I need antlr but the gradle build is not able to
find it.

Thanks
  

Re: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable

[Kevin Rushforth]

Yes, that pretty much captures the thinking behind it.

My thought is that there is no real reason that subdivisions need to be 
immutable, although I wouldn't want to change it at this late date for 
FX 8 unless it is needed for FXML support.


The fixedEyeAtCameraZero mode is not something I think should be 
mutable, since the camera behaves fairly differently in each mode. 
Having said that, there is no reason it couldn't be made mutable in a 
subsequent release if there was a good reason to do so.


-- Kevin


Chien Yang wrote:
We did discuss making divisions in the predefined 3D shapes mutable in 
earlier meeting. However we decided against it since it is a heavy 
weight operation as the supporting mesh will has to be regenerated. I 
believe the constructor with the divisions argument will not have much 
use in the future when we move away from mesh implementation of our 
predefined 3D shapes.


The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to 
the camera and once set it shouldn't be changed. The perspective 
projection matrix is constructed differently depending on the flag. In 
the default mode, JavaFX controls the eye to achieve a projection 
plane at Z=0 so that simple adding of 3D shapes into a 2D scene looks 
intuitive. The other mode, where eye is fixed a camera zero, is well 
suitable for movable camera in the 3d space.


- Chien

On 10/4/2013 9:28 AM, Richard Bair wrote:
Why are they not? It isn't immediately obvious to me why these are 
not mutable? I was reading 
https://javafx-jira.kenai.com/browse/RT-29577 and this struck me as odd.


Richard

Re: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable

[Kevin Rushforth]

Certainly for divisions there is no reason to keep them immutable. For 
fixedEyeAtCameraZero, I don't think the reasons for keeping it immutable 
are compelling.


Making either change in FX 8 is a different matter, though, given how 
late we are. The implementation assumes immutability and we would need 
to change it, implement it, test it, and then fix any bugs as a result. 
Seems like we could add mutability in a subsequent release.


-- Kevin


Richard Bair wrote:

I would turn that around and say that unless there is a compelling reason for 
something to be immutable, it should be mutable. Mutability is important for 
tools as well as for FXML as well as for developers.

Immutable state is awesome for thread-safety or any type of concurrency. But these types 
of classes are not of that nature, they're UI only classes, and as such their state 
should be mutable (and like all mutable state in FX, the range of possible values should 
not be hindered by the evil "unbind" pattern).

Richard

On Oct 4, 2013, at 12:46 PM, Kevin Rushforth  wrote:

  

Yes, that pretty much captures the thinking behind it.

My thought is that there is no real reason that subdivisions need to be 
immutable, although I wouldn't want to change it at this late date for FX 8 
unless it is needed for FXML support.

The fixedEyeAtCameraZero mode is not something I think should be mutable, since 
the camera behaves fairly differently in each mode. Having said that, there is 
no reason it couldn't be made mutable in a subsequent release if there was a 
good reason to do so.

-- Kevin


Chien Yang wrote:


We did discuss making divisions in the predefined 3D shapes mutable in earlier 
meeting. However we decided against it since it is a heavy weight operation as 
the supporting mesh will has to be regenerated. I believe the constructor with 
the divisions argument will not have much use in the future when we move away 
from mesh implementation of our predefined 3D shapes.

The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the 
camera and once set it shouldn't be changed. The perspective projection matrix 
is constructed differently depending on the flag. In the default mode, JavaFX 
controls the eye to achieve a projection plane at Z=0 so that simple adding of 
3D shapes into a 2D scene looks intuitive. The other mode, where eye is fixed a 
camera zero, is well suitable for movable camera in the 3d space.

- Chien

On 10/4/2013 9:28 AM, Richard Bair wrote:
  

Why are they not? It isn't immediately obvious to me why these are not mutable? 
I was reading https://javafx-jira.kenai.com/browse/RT-29577 and this struck me 
as odd.

Richard



  

Re: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable

[Kevin Rushforth]

Sounds good.


Depends on whether it is usable from SceneBuilder and FXML, and the 
following:
   - We must *not* expose a ReadOnly property for these properties 
(and I don't think we do)


No, we don't.

   - The FXML changes must be backwards compatible (they should be but 
we need to verify)


I'll add a note to the JIRA and the FXML folks can reply.



   - The SceneBuilder can do something reasonable as is (not sure).


Chien or I can reach out to the SB team.

-- Kevin


Richard Bair wrote:
Depends on whether it is usable from SceneBuilder and FXML, and the 
following:
   - We must *not* expose a ReadOnly property for these properties 
(and I don't think we do)
   - The FXML changes must be backwards compatible (they should be but 
we need to verify)

   - The SceneBuilder can do something reasonable as is (not sure).

Richard

On Oct 4, 2013, at 1:08 PM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


Certainly for divisions there is no reason to keep them immutable. 
For fixedEyeAtCameraZero, I don't think the reasons for keeping it 
immutable are compelling.


Making either change in FX 8 is a different matter, though, given how 
late we are. The implementation assumes immutability and we would 
need to change it, implement it, test it, and then fix any bugs as a 
result. Seems like we could add mutability in a subsequent release.


-- Kevin


Richard Bair wrote:

I would turn that around and say that unless there is a compelling reason for 
something to be immutable, it should be mutable. Mutability is important for 
tools as well as for FXML as well as for developers.

Immutable state is awesome for thread-safety or any type of concurrency. But these types 
of classes are not of that nature, they're UI only classes, and as such their state 
should be mutable (and like all mutable state in FX, the range of possible values should 
not be hindered by the evil "unbind" pattern).

Richard

On Oct 4, 2013, at 12:46 PM, Kevin Rushforth  wrote:

  

Yes, that pretty much captures the thinking behind it.

My thought is that there is no real reason that subdivisions need to be 
immutable, although I wouldn't want to change it at this late date for FX 8 
unless it is needed for FXML support.

The fixedEyeAtCameraZero mode is not something I think should be mutable, since 
the camera behaves fairly differently in each mode. Having said that, there is 
no reason it couldn't be made mutable in a subsequent release if there was a 
good reason to do so.

-- Kevin


Chien Yang wrote:


We did discuss making divisions in the predefined 3D shapes mutable in earlier 
meeting. However we decided against it since it is a heavy weight operation as 
the supporting mesh will has to be regenerated. I believe the constructor with 
the divisions argument will not have much use in the future when we move away 
from mesh implementation of our predefined 3D shapes.

The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the 
camera and once set it shouldn't be changed. The perspective projection matrix 
is constructed differently depending on the flag. In the default mode, JavaFX 
controls the eye to achieve a projection plane at Z=0 so that simple adding of 
3D shapes into a 2D scene looks intuitive. The other mode, where eye is fixed a 
camera zero, is well suitable for movable camera in the 3d space.

- Chien

On 10/4/2013 9:28 AM, Richard Bair wrote:
  

Why are they not? It isn't immediately obvious to me why these are not mutable? 
I was reading https://javafx-jira.kenai.com/browse/RT-29577 and this struck me 
as odd.

Richard



  

Re: Lambdafication (was Re: Default methods in JFX-8)

[Kevin Rushforth]

5. Should we enable more -Xlint warnings in OpenJFX build?

6. Any chances anything of this can still go in 8 (e.g. get rid of warnings


We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and 
getting rid of warnings would be a P4 bug. I guess it depends on how 
intrusive the changes are and whether someone has time to review it in 
the next two weeks.


-- Kevin



Sven Reimers wrote:

Ok. So here are the results of trying to add lambda and diamond to the
controls module:

1. A lot of generics and typing to be fixed (esp. in tests). Seems you can
get  some anonymous inner classes type checked by the compiler, but not the
lambda equivalent.. very interesting.

2.  279 Files modified (including tests)

3. A lot of the automatic replacements could probably be nicer e.g.

ft.setOnFinished(new EventHandler() {
@Override public void handle(ActionEvent
actionEvent) {
  getChildren().remove(tm.textNode);
}
});

was replaced to:

ft.setOnFinished((ActionEvent actionEvent) -> {
getChildren().remove(tm.textNode);
});

most unobtrusive code probably:

ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode));

4. A lot of illegal forward reference errors - these were result of missing
this in the automatic transformation from anonymous inner to lambdas (seems
the rules are not identical - you have to add "this." as prefix if using
lambdas - not sure this is the expected way it should work)

5. Should we enable more -Xlint warnings in OpenJFX build?

6. Any chances anything of this can still go in 8 (e.g. get rid of warnings

7. Probably more things I just can't think of at the moment...

How to take this forward? If there is interest in the change I could make
available...

Comments? Ideas?

-Sven



On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers  wrote:

  

Oh and btw - would you go for lambda with or without additional type info
 before parameter name?

-Sven


On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers wrote:



Ok. Here you go...

I just did an inspection run for the controls module and my IDE came up
with  (drum roll) 888 possible lambda conversions..

Looking through them I discovered that usage of <> (aka diamond syntax)
is   not used (or at least not used a lot) in at least the controls
modules. My IDE showed me 1171 occurrences.

Is there a good reason not to use diamonds?

Will now try to apply all those changes and figure out if this still
builds... up next: go through the other modules...

-Sven


On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair wrote:

  

Brian was telling me at J1 that whether parallel gets you performance or
not depends on the size of the collection and the complexity of the work to
perform. There is definitely a point at which parallel helps -- and a point
at which it hurts.

Richard

On Oct 3, 2013, at 3:33 PM, Hervé Girod  wrote:



Here is a nice example, taking advantage of the ease of going
  

parallel. Apparently the performance without parallel will also further
improve.
http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/


Hervé

Sent from my iPad

  

On 4 oct. 2013, at 00:20, David Grieve 


wrote:


And what about Stream? I like the declarative code that comes from


using Stream and I can see places in the code where Stream could be used,
but I wonder about its performance relative to iterators and/or enhanced
for loops.


On Oct 3, 2013, at 4:45 PM, Richard Bair 


wrote:


Hello, OpenJFX Community.

There's a question about using Java 8 features in FX.

I've been working on the support for InputMethods in JFXPanel which


is an important feature for many users who speak hieroglyphic languages.


The issue is tracked under:


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


In order to have a high-quality support we need to change


javafx.scene.input.InputMethodRequests interface and introduce 3 new
methods. This is not needed for pure FX applications right now, but
absolutely required for InputMethods in the JFXPanel. However, the
interface is public and it was present since FX2.0, so changing it would
become a breaking change. So the only way to avoid the problem is using the
default methods. Those would return some stub values, the JDK is OK with
that, as it would not crash or throw exceptions, but text composition would
not work correctly.


I know that we want to avoid using the Java 8 features in the


JFX-8, so I wanted to ask - is it OK to use the default methods here?


If you are staying away from JDK8 features for the JFX78 backport,


don't worry.  There are more issues with new JDK8 APIs than with the new
language features.


For example there were default methods put into some collections

Re: Lambdafication (was Re: Default methods in JFX-8)

[Kevin Rushforth]

I was just speaking about removing the warnings. Richard and Jonathan 
should chime in as to whether they are OK doing the lambda-fication in 
FX 8 (and about how they want to see the review done).


Please base any change on 8/graphics/rt

Thanks!

-- Kevin


Sven Reimers wrote:
Ok. So I will file a P4 saying 



  Lambdafication for Controls

and send the diff to Richard/Kevin/Jonathan to be attached..

should I base the change on b110 (master)?

I could create a public bitbucket branch based on master and add my 
changes there - better idea?


What approach is most simple for review?

Should I split test and library code changes?

-Sven

P.S. Shall I try to get this done as well for other modules? Which 
would be preferred? (Just in case I have some more time to spend)




On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:



5. Should we enable more -Xlint warnings in OpenJFX build?

6. Any chances anything of this can still go in 8 (e.g. get rid of warnings


We have 2 weeks where we can still accept P4-P5 bugs into FX 8,
and getting rid of warnings would be a P4 bug. I guess it depends
on how intrusive the changes are and whether someone has time to
review it in the next two weeks.

-- Kevin




Sven Reimers wrote:

Ok. So here are the results of trying to add lambda and diamond to the
controls module:

1. A lot of generics and typing to be fixed (esp. in tests). Seems you can
get  some anonymous inner classes type checked by the compiler, but not the
lambda equivalent.. very interesting.

2.  279 Files modified (including tests)

3. A lot of the automatic replacements could probably be nicer e.g.

ft.setOnFinished(new EventHandler() {
@Override public void handle(ActionEvent
actionEvent) {
  getChildren().remove(tm.textNode);
}
});

was replaced to:

ft.setOnFinished((ActionEvent actionEvent) -> {
getChildren().remove(tm.textNode);
});

most unobtrusive code probably:

ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode));

4. A lot of illegal forward reference errors - these were result of missing
this in the automatic transformation from anonymous inner to lambdas (seems
the rules are not identical - you have to add "this." as prefix if using
lambdas - not sure this is the expected way it should work)

5. Should we enable more -Xlint warnings in OpenJFX build?

6. Any chances anything of this can still go in 8 (e.g. get rid of warnings

7. Probably more things I just can't think of at the moment...

How to take this forward? If there is interest in the change I could make
available...

Comments? Ideas?

-Sven



On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers  
<mailto:sven.reim...@gmail.com> wrote:

  

Oh and btw - would you go for lambda with or without additional type info
 before parameter name?

-Sven


On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers  
<mailto:sven.reim...@gmail.com>wrote:



Ok. Here you go...

I just did an inspection run for the controls module and my IDE came up
with  (drum roll) 888 possible lambda conversions..

Looking through them I discovered that usage of <> (aka diamond syntax)
is   not used (or at least not used a lot) in at least the controls
modules. My IDE showed me 1171 occurrences.

Is there a good reason not to use diamonds?

Will now try to apply all those changes and figure out if this still
builds... up next: go through the other modules...

-Sven


On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair  
<mailto:richard.b...@oracle.com>wrote:

  

Brian was telling me at J1 that whether parallel gets you performance or
not depends on the size of the collection and the complexity of the work to
perform. There is definitely a point at which parallel helps -- and a point
at which it hurts.

Richard

On Oct 3, 2013, at 3:33 PM, Hervé Girod  
<mailto:herve.gi...@gmail.com> wrote:



Here is a nice example, taking advantage of the ease of going
  

parallel. Apparently the performance without parallel will also further
improve.

http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/


Hervé

Sent from my iPad

  

On 4 oct. 2013, at 00:20, David Grieve  
<mailto:david.gri...@oracle.com>


wrote:


And what about Stream? I like the declarative code that comes from


using Stream and I can see places in the code where Stream could be used,
but I wonder about its performance relative to iterators and/or enhanced
for loops.


 

Re: Building on Mac with latest Xcode

[Kevin Rushforth]

I know that David DeHaven looked into this. Maybe he will have something 
to add?


For production, we need to use gcc (not clang) and the 10.7 SDK, but 
having a solution that makes it easy for developers to build with latest 
would be a good thing.


-- Kevin


Sven Reimers wrote:

Hi,

since I had to once more reinstall my Mac short before Java One I lost a
couple of updates, so I finally got the latest XCode installed, which does
not include MacOSX 10.7 SDK.

Fixing building is easy - just change minimum version in
buildSrc/mac.gradle to 10.8 does the trick.

So what is the "official" "correct" way to circumvent the problem?

Seems the latest XCode version that shipped 10.7 SDK is 4.4 (if I get this
correct from https://developer.apple.com/downloads/index.action?q=xcode

Should deinstall the actual version and get back to 4.4?

Any comments appreciated.

Thanks

-Sven

  

Re: hg: openjfx/8/graphics/rt: 3 new changesets

[Kevin Rushforth]

In the top-level JDK directory, next to src.zip, there will be a 
javafx-src.zip.


-- Kevin


Tom Schindl wrote:

So where the src.zip end up, so that k can adjust the tooling?

Tom

Von meinem iPhone gesendet

  

Am 08.10.2013 um 18:32 schrieb hang...@oracle.com:

Changeset: 61727bf6e832
Author:kcr
Date:  2013-10-08 09:26 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/61727bf6e832

[TEST-ONLY] RT-32950: Enable excluded tests in gradle build
Reviewed-by: Chien

! build.gradle
! 
modules/base/src/test/java/javafx/binding/expression/AbstractNumberExpressionTest.java

Changeset: 093ea25436c7
Author:kcr
Date:  2013-10-08 09:26 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/093ea25436c7

RT-21415: Need to add javafx-src.zip to JDK 8 distribution
Reviewed-by: David Hill, Felipe

! build.gradle
! gradle.properties.template

Changeset: ab9489903f7b
Author:Yao Wang 
Date:  2013-10-08 09:30 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ab9489903f7b

RT-26587: 3D Data validation AND RT-30451: FX 8 3D: Need to validate Mesh's 
data size
Summary: Validate input data during FX->NG sync stage. AND Need to validate the 
size and range of these arrays.
Reviewed-by: kcr and cyang

! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java
! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGTriangleMesh.java
! modules/graphics/src/main/java/com/sun/prism/impl/BaseMesh.java
! modules/graphics/src/main/java/javafx/scene/shape/Box.java
! modules/graphics/src/main/java/javafx/scene/shape/Cylinder.java
! modules/graphics/src/main/java/javafx/scene/shape/Sphere.java
! modules/graphics/src/main/java/javafx/scene/shape/TriangleMesh.java

FX 8 ramp down

[Kevin Rushforth]

In order to let community members know what is going on with the bugs, 
etc., targeted to Lombard (FX 8), here is the current status.


We are continuing to ramp-down the FX 8 release in conjunction with the 
ramp-down of JDK 8. Here are the key dates to be aware of for FX fixes 
that are going into FX 8:


10/24 - 12/4 : P1 - P3 bugs may be fixed, with code review, but no 
additional approval needed
12/5 - end of release : Only release-critical bugs may be fixed, release 
team approval needed


This means that any P4 - P5 bugs that are not fixed by 10/23 will be 
deferred out of FX 8. It also means that any enhancement requests (Tweak 
or Feature) regardless of priority will likely be deferred out of FX 8. 
Exceptions will require release team approval, and such approval is 
unlikely.


Note that we are currently using "Van Ness" as a placeholder for both 
JDK 9 and JDK 8u releases. We will soon be adopting the same release 
versions as used by the JDK.


-- Kevin

Changes for October 2013 CPU release synced into FX 8

[Kevin Rushforth]

Note: I have synced up the pending FX changes from the just-release 
October 2013 CPU release into FX 8. I also pulled them into the 
graphics/rt repo.


-- Kevin

Re: Half-baked API (Camera position)

[Kevin Rushforth]

Regarding #2, I'm OK with an exception being thrown.

Regarding #1, do you think moving the clip planes to PerspectiveCamera 
(rather than in the base class) be better for FX 8? We can compatibly 
move it up to a superclass in a future release. Or would this be too 
disruptive?


-- Kevin


Richard Bair wrote:
My quick vote would be throwing the exception, but is like to hear from Steve and Kevin. 

  

On Oct 16, 2013, at 1:04 AM, Pavel Safrata  wrote:

Hello,
it looks like we can't help releasing a not-fully-baked piece of API with FX8. 
We've added bunch of new APIs for 3D and did our best to make them work well. 
Unfortunately, there's been not enough time&priority to fine-tune their 
behavior in 2D world. Right now I'm concerned about camera position in scene. It is 
inherent in the 3D perspective camera that it has its specific position in world, 
but the 2D parallel camera as we have it projects everything to the XY plane 
basically by ignoring the Z coordinate, so the camera position doesn't matter all 
that much. However, some of the newly added APIs depend on it:

1. Near/far clip on camera. This obviously cannot work without knowing where the camera 
is. Right now the parallel camera does no clipping though, so I guess we are OK to go 
with it as a "known limitation".

2. PickResult on events which reports "intersectedDistance" between the camera and the picked 
point. This is worse because we can't just "not support" it - there will be some value and once 
somebody uses it we'll have a backward compatibility issue. The state right now is that the camera is 
(tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances from there (note that as the 
camera renders everything, for nodes "in front of Z=-1" it reports negative distances). This may 
change when the camera position is properly discussed and specified.

Note that this post is *not* meant to discuss the camera position. Even if we 
could find the answer quickly (which I doubt), it's most probably too late to 
apply the change for FX8.

So finally here is my question: do you think it's OK to solve this by keeping the current 
behavior and documenting the "intersectedDistance" in a way that for parallel 
camera the numbers are unspecified and subject to change in future versions? Or would you 
prefer something more drastic like throwing an UnsupportedOperationException (losing the 
possibility to compare the distances)?

Thanks,
Pavel

Re: Constructor annotation

[Kevin Rushforth]

Not to mention Tom's point that it can't be in the fxml module without 
created unwanted (and circular) module dependencies. Seems like it needs 
to be in the "base" module then, right?


-- Kevin


Richard Bair wrote:

+1 this is my preference. It is useful for things other than FXML, and should 
be considered part of our javafx.beans API.

  

On Oct 16, 2013, at 4:20 AM, Tom Schindl  wrote:



On 16.10.13 11:22, Eva Krejcirova wrote:
Hi All,

when we retired builders, we caused a problem for FXML which doesn't
have a way to create classes without default constructors. Back then we
decided to use an annotation for this but never actually got to
implement it and we need to fix this for FX8. I am in the process of
adding this functionality to FXMLLoader but we need to decide how the
annotation will look like and I could use some help with this.

We cannot use already existing ConstructorProperties for this, because
it's java.beans package and we don't want to create to dependency on
this package in JavaFX, so we need to introduce a new annotation.

We have two options:

1. Annotate the whole constructor:
e.g.
   @ConstructorArguments({"a", "b", "list"})
   public ImmutableClass(int a, int b, Integer... list)

2. Annotate the arguments:
e.g.
   public ImmutableClass(@FXMLArgument("a") int a,
@FXMLArgument("b")int b, @FXMLArgument("list")Integer... list)


Which option do you like more and how should the annotation be named?
  

Option 2, but does it really have to hold FXML in the annotation name?
Where would you put the annotation? I think it should NOT be in the
FXML-Package-Namespace because the core should NOT depend on FXML!

I'd go with @Argument or simply @NamedArgument (@Named is already used
by javax.inject)

Tom

Re: Half-baked API (Camera position)

[Kevin Rushforth]

Would IllegalStateException be better here? Usually UOE is for 
operations that are simply not supported by the class in question. In 
this case, the operation is only unsupported if the camera on the scene 
(i.e., the state of an object) is of a certain type which can change at 
runtime.


I'm OK either way, just want it to be a deliberate decision.

-- Kevin


Pavel Safrata wrote:
As I've said, we intend to fix it in the future, so the situation 
should not be impossible. It is mostly used that way in the existing 
code, but there definitely are precedents for throwing it just 
temporarily. For instance:


nodeOrientationProperty().getCssMetaData:
throw new UnsupportedOperationException("Not supported yet.");

or

MeshView.impl_computeContains():
throw new UnsupportedOperationException("Not supported yet.");
(internal but directly accessible to users via contains())

Pavel

On 16.10.2013 20:10, Stephen F Northover wrote:
I took a quick look through JavaFX to find how this exception is 
used. It is mostly used to indicate impossible situation.  Is that 
the situation we have here?


Personally, for me, if we throw the exception, then we will generally 
just leave it that way forever.


Steve

On 2013-10-16 11:22 AM, Pavel Safrata wrote:

On 16.10.2013 17:03, Stephen F Northover wrote:
Could do something useful with what was there now?  We can always 
fix this in future by adding another API to govern the 
interpretation of the value.


Not much useful. Anyway, any such stuff can be quite easily done by 
reading the intersectedPoint's Z coordinate.




Throwing the exception indicates that the call is unsupported, but 
application code can be written to catch the exception and when we 
implement the API, it can break (I realize that this is unlikely).


The exception can tell by the message that the operation will be 
supported in the future.


Pavel



Steve

On 2013-10-16 10:46 AM, Richard Bair wrote:
My quick vote would be throwing the exception, but is like to hear 
from Steve and Kevin.


On Oct 16, 2013, at 1:04 AM, Pavel Safrata 
 wrote:


Hello,
it looks like we can't help releasing a not-fully-baked piece of 
API with FX8. We've added bunch of new APIs for 3D and did our 
best to make them work well. Unfortunately, there's been not 
enough time&priority to fine-tune their behavior in 2D world. 
Right now I'm concerned about camera position in scene. It is 
inherent in the 3D perspective camera that it has its specific 
position in world, but the 2D parallel camera as we have it 
projects everything to the XY plane basically by ignoring the Z 
coordinate, so the camera position doesn't matter all that much. 
However, some of the newly added APIs depend on it:


1. Near/far clip on camera. This obviously cannot work without 
knowing where the camera is. Right now the parallel camera does 
no clipping though, so I guess we are OK to go with it as a 
"known limitation".


2. PickResult on events which reports "intersectedDistance" 
between the camera and the picked point. This is worse because we 
can't just "not support" it - there will be some value and once 
somebody uses it we'll have a backward compatibility issue. The 
state right now is that the camera is (tentatively, by my 
arbitrary decision) at [0, 0, -1] and reports distances from 
there (note that as the camera renders everything, for nodes "in 
front of Z=-1" it reports negative distances). This may change 
when the camera position is properly discussed and specified.


Note that this post is *not* meant to discuss the camera 
position. Even if we could find the answer quickly (which I 
doubt), it's most probably too late to apply the change for FX8.


So finally here is my question: do you think it's OK to solve 
this by keeping the current behavior and documenting the 
"intersectedDistance" in a way that for parallel camera the 
numbers are unspecified and subject to change in future versions? 
Or would you prefer something more drastic like throwing an 
UnsupportedOperationException (losing the possibility to compare 
the distances)?


Thanks,
Pavel

Re: Half-baked API (Camera position)

[Kevin Rushforth]

Steve: if Pavel throws IllegalStateException("not yet supported for 
parallel camera") or similar, do you think that would be OK or do you 
not want to see any exception?


-- Kevin


Kevin Rushforth wrote:
Would IllegalStateException be better here? Usually UOE is for 
operations that are simply not supported by the class in question. In 
this case, the operation is only unsupported if the camera on the 
scene (i.e., the state of an object) is of a certain type which can 
change at runtime.


I'm OK either way, just want it to be a deliberate decision.

-- Kevin


Pavel Safrata wrote:
As I've said, we intend to fix it in the future, so the situation 
should not be impossible. It is mostly used that way in the existing 
code, but there definitely are precedents for throwing it just 
temporarily. For instance:


nodeOrientationProperty().getCssMetaData:
throw new UnsupportedOperationException("Not supported yet.");

or

MeshView.impl_computeContains():
throw new UnsupportedOperationException("Not supported yet.");
(internal but directly accessible to users via contains())

Pavel

On 16.10.2013 20:10, Stephen F Northover wrote:
I took a quick look through JavaFX to find how this exception is 
used. It is mostly used to indicate impossible situation.  Is that 
the situation we have here?


Personally, for me, if we throw the exception, then we will 
generally just leave it that way forever.


Steve

On 2013-10-16 11:22 AM, Pavel Safrata wrote:

On 16.10.2013 17:03, Stephen F Northover wrote:
Could do something useful with what was there now?  We can always 
fix this in future by adding another API to govern the 
interpretation of the value.


Not much useful. Anyway, any such stuff can be quite easily done by 
reading the intersectedPoint's Z coordinate.




Throwing the exception indicates that the call is unsupported, but 
application code can be written to catch the exception and when we 
implement the API, it can break (I realize that this is unlikely).


The exception can tell by the message that the operation will be 
supported in the future.


Pavel



Steve

On 2013-10-16 10:46 AM, Richard Bair wrote:
My quick vote would be throwing the exception, but is like to 
hear from Steve and Kevin.


On Oct 16, 2013, at 1:04 AM, Pavel Safrata 
 wrote:


Hello,
it looks like we can't help releasing a not-fully-baked piece of 
API with FX8. We've added bunch of new APIs for 3D and did our 
best to make them work well. Unfortunately, there's been not 
enough time&priority to fine-tune their behavior in 2D world. 
Right now I'm concerned about camera position in scene. It is 
inherent in the 3D perspective camera that it has its specific 
position in world, but the 2D parallel camera as we have it 
projects everything to the XY plane basically by ignoring the Z 
coordinate, so the camera position doesn't matter all that much. 
However, some of the newly added APIs depend on it:


1. Near/far clip on camera. This obviously cannot work without 
knowing where the camera is. Right now the parallel camera does 
no clipping though, so I guess we are OK to go with it as a 
"known limitation".


2. PickResult on events which reports "intersectedDistance" 
between the camera and the picked point. This is worse because 
we can't just "not support" it - there will be some value and 
once somebody uses it we'll have a backward compatibility issue. 
The state right now is that the camera is (tentatively, by my 
arbitrary decision) at [0, 0, -1] and reports distances from 
there (note that as the camera renders everything, for nodes "in 
front of Z=-1" it reports negative distances). This may change 
when the camera position is properly discussed and specified.


Note that this post is *not* meant to discuss the camera 
position. Even if we could find the answer quickly (which I 
doubt), it's most probably too late to apply the change for FX8.


So finally here is my question: do you think it's OK to solve 
this by keeping the current behavior and documenting the 
"intersectedDistance" in a way that for parallel camera the 
numbers are unspecified and subject to change in future 
versions? Or would you prefer something more drastic like 
throwing an UnsupportedOperationException (losing the 
possibility to compare the distances)?


Thanks,
Pavel

Re: Half-baked API (Camera position)

[Kevin Rushforth]

I can see your point. There are cases where it can make sense to have a 
restriction now and relax it later, but this isn't exactly that case. 
It's really more of a case of not being currently implemented correctly 
in some modes.


I guess the other option (which Pavel also mentioned) is to continue to 
return something plausible, but not really correct, and file it as a bug 
against FX 8.


-- Kevin


Stephen F Northover wrote:

Initial position:

I don't really want to see any exception.  Throwing an exception is 
unexpected and should really be reserved for when something bad 
happens, not when we can't decide how an API works.  If the exception 
goes in, it's API and it stays forever.


Steve

On 2013-10-16 5:23 PM, Kevin Rushforth wrote:
Steve: if Pavel throws IllegalStateException("not yet supported for 
parallel camera") or similar, do you think that would be OK or do you 
not want to see any exception?


-- Kevin


Kevin Rushforth wrote:
Would IllegalStateException be better here? Usually UOE is for 
operations that are simply not supported by the class in question. 
In this case, the operation is only unsupported if the camera on the 
scene (i.e., the state of an object) is of a certain type which can 
change at runtime.


I'm OK either way, just want it to be a deliberate decision.

-- Kevin


Pavel Safrata wrote:
As I've said, we intend to fix it in the future, so the situation 
should not be impossible. It is mostly used that way in the 
existing code, but there definitely are precedents for throwing it 
just temporarily. For instance:


nodeOrientationProperty().getCssMetaData:
throw new UnsupportedOperationException("Not supported yet.");

or

MeshView.impl_computeContains():
throw new UnsupportedOperationException("Not supported yet.");
(internal but directly accessible to users via contains())

Pavel

On 16.10.2013 20:10, Stephen F Northover wrote:
I took a quick look through JavaFX to find how this exception is 
used. It is mostly used to indicate impossible situation.  Is that 
the situation we have here?


Personally, for me, if we throw the exception, then we will 
generally just leave it that way forever.


Steve

On 2013-10-16 11:22 AM, Pavel Safrata wrote:

On 16.10.2013 17:03, Stephen F Northover wrote:
Could do something useful with what was there now?  We can 
always fix this in future by adding another API to govern the 
interpretation of the value.


Not much useful. Anyway, any such stuff can be quite easily done 
by reading the intersectedPoint's Z coordinate.




Throwing the exception indicates that the call is unsupported, 
but application code can be written to catch the exception and 
when we implement the API, it can break (I realize that this is 
unlikely).


The exception can tell by the message that the operation will be 
supported in the future.


Pavel



Steve

On 2013-10-16 10:46 AM, Richard Bair wrote:
My quick vote would be throwing the exception, but is like to 
hear from Steve and Kevin.


On Oct 16, 2013, at 1:04 AM, Pavel Safrata 
 wrote:


Hello,
it looks like we can't help releasing a not-fully-baked piece 
of API with FX8. We've added bunch of new APIs for 3D and did 
our best to make them work well. Unfortunately, there's been 
not enough time&priority to fine-tune their behavior in 2D 
world. Right now I'm concerned about camera position in scene. 
It is inherent in the 3D perspective camera that it has its 
specific position in world, but the 2D parallel camera as we 
have it projects everything to the XY plane basically by 
ignoring the Z coordinate, so the camera position doesn't 
matter all that much. However, some of the newly added APIs 
depend on it:


1. Near/far clip on camera. This obviously cannot work without 
knowing where the camera is. Right now the parallel camera 
does no clipping though, so I guess we are OK to go with it as 
a "known limitation".


2. PickResult on events which reports "intersectedDistance" 
between the camera and the picked point. This is worse because 
we can't just "not support" it - there will be some value and 
once somebody uses it we'll have a backward compatibility 
issue. The state right now is that the camera is (tentatively, 
by my arbitrary decision) at [0, 0, -1] and reports distances 
from there (note that as the camera renders everything, for 
nodes "in front of Z=-1" it reports negative distances). This 
may change when the camera position is properly discussed and 
specified.


Note that this post is *not* meant to discuss the camera 
position. Even if we could find the answer quickly (which I 
doubt), it's most probably too late to apply the change for FX8.


So finally here is my question: do you think it's OK to solve 
this by keeping the current behavior and documenting the 
"intersectedDistance&quo

Re: Half-baked API (Camera position)

[Kevin Rushforth]

After chatting with Chien about this, and thinking about it a bit more, 
I agree with Steve that we shouldn't throw an exception unless we are 
certain that the concept of a distance just doesn't make sense in 
parallel mode. If we were so convinced, then an exception (UOE or ISE) 
would be fine. As it is, I think we can come up with something sensible, 
if a bit arbitrary, for the pure 2D case -- parallel camera, 2D objects, 
2D transforms -- so I don't think we want to throw an exception.


-- Kevin


Richard Bair wrote:

I don't see how returning something wrong is any different than throwing an 
exception from a compatibility perspective. Bugs are bugs.

On Oct 16, 2013, at 3:46 PM, Kevin Rushforth  wrote:

  

I can see your point. There are cases where it can make sense to have a 
restriction now and relax it later, but this isn't exactly that case. It's 
really more of a case of not being currently implemented correctly in some 
modes.

I guess the other option (which Pavel also mentioned) is to continue to return 
something plausible, but not really correct, and file it as a bug against FX 8.

-- Kevin


Stephen F Northover wrote:


Initial position:

I don't really want to see any exception.  Throwing an exception is unexpected 
and should really be reserved for when something bad happens, not when we can't 
decide how an API works.  If the exception goes in, it's API and it stays 
forever.

Steve

On 2013-10-16 5:23 PM, Kevin Rushforth wrote:
  

Steve: if Pavel throws IllegalStateException("not yet supported for parallel 
camera") or similar, do you think that would be OK or do you not want to see any 
exception?

-- Kevin


Kevin Rushforth wrote:


Would IllegalStateException be better here? Usually UOE is for operations that 
are simply not supported by the class in question. In this case, the operation 
is only unsupported if the camera on the scene (i.e., the state of an object) 
is of a certain type which can change at runtime.

I'm OK either way, just want it to be a deliberate decision.

-- Kevin


Pavel Safrata wrote:
  

As I've said, we intend to fix it in the future, so the situation should not be 
impossible. It is mostly used that way in the existing code, but there 
definitely are precedents for throwing it just temporarily. For instance:

nodeOrientationProperty().getCssMetaData:
   throw new UnsupportedOperationException("Not supported yet.");

or

MeshView.impl_computeContains():
   throw new UnsupportedOperationException("Not supported yet.");
(internal but directly accessible to users via contains())

Pavel

On 16.10.2013 20:10, Stephen F Northover wrote:


I took a quick look through JavaFX to find how this exception is used. It is 
mostly used to indicate impossible situation.  Is that the situation we have 
here?

Personally, for me, if we throw the exception, then we will generally just 
leave it that way forever.

Steve

On 2013-10-16 11:22 AM, Pavel Safrata wrote:
  

On 16.10.2013 17:03, Stephen F Northover wrote:


Could do something useful with what was there now?  We can always fix this in 
future by adding another API to govern the interpretation of the value.
  

Not much useful. Anyway, any such stuff can be quite easily done by reading the 
intersectedPoint's Z coordinate.



Throwing the exception indicates that the call is unsupported, but application 
code can be written to catch the exception and when we implement the API, it 
can break (I realize that this is unlikely).
  

The exception can tell by the message that the operation will be supported in 
the future.

Pavel



Steve

On 2013-10-16 10:46 AM, Richard Bair wrote:
  

My quick vote would be throwing the exception, but is like to hear from Steve 
and Kevin.



On Oct 16, 2013, at 1:04 AM, Pavel Safrata  wrote:

Hello,
it looks like we can't help releasing a not-fully-baked piece of API with FX8. 
We've added bunch of new APIs for 3D and did our best to make them work well. 
Unfortunately, there's been not enough time&priority to fine-tune their 
behavior in 2D world. Right now I'm concerned about camera position in scene. It is 
inherent in the 3D perspective camera that it has its specific position in world, 
but the 2D parallel camera as we have it projects everything to the XY plane 
basically by ignoring the Z coordinate, so the camera position doesn't matter all 
that much. However, some of the newly added APIs depend on it:

1. Near/far clip on camera. This obviously cannot work without knowing where the camera 
is. Right now the parallel camera does no clipping though, so I guess we are OK to go 
with it as a "known limitation".

2. PickResult on events which reports "intersectedDistan

Re: Media is now opensource

[Kevin Rushforth]

All of the JavaFX runtime is open source except for the third-party code 
that we cannot ship (e.g., the On2 codec that Kirill mentioned, and the 
T2K font library, for which we have an open replacement), and the FX 
deploy code, which depends on the JRE deploy code. Additionally, the JMX 
code, which is shipped as part of the JDK (not the JRE) as javafx-mx.jar 
has not been open-sourced, but it is only used for optional tooling (and 
currently lacks an owner).


Most (almost all) Jira issues are publicly visible (after sign-in), 
but some are not (maybe due to security or other concerns).  Will this 
continue to be the case going forward?


Yes.

In what ways (just in terms of things relevant to JavaFX) does the open source distribution you could build from the openjfx repository differ from what Oracle might include in the JDK? 
(e.g. VP6 won't be in open-jfx, Oracle provided browser plugin/webstart support won't be accessible, anything else?)
  


That's pretty much it.  VP6, T2K, deploy, FX JMX tooling.

-- Kevin


John Smith wrote:

Is the open sourcing of JavaFX now complete? (I think it might be)

If not, what is outstanding?

Are there auxiliary things like test frameworks or performance tools that are 
intended to be open sourced to support JavaFX development?

Most (almost all) Jira issues are publicly visible (after sign-in), but some 
are not (maybe due to security or other concerns).  Will this continue to be 
the case going forward?

In what ways (just in terms of things relevant to JavaFX) does the open source distribution you could build from the openjfx repository differ from what Oracle might include in the JDK? 
(e.g. VP6 won't be in open-jfx, Oracle provided browser plugin/webstart support won't be accessible, anything else?)


-Original Message-
From: openjfx-dev-boun...@openjdk.java.net 
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Kirill Kirichenko
Sent: Friday, October 18, 2013 9:35 AM
To: openjfx-dev@openjdk.java.net
Subject: Media is now opensource

Hello OpenJFXers !
We're happy to announce that Media part of JavaFX is now open source.
Opensourcing touched all Media component except ON2 FLV demuxer and VP6 
decoder. The decoder will remain closed.

You're all welcome to contribute.

Thanks,
K
  

Re: Media is now opensource

[Kevin Rushforth]

Regarding JMX:


Kevin, if it is easy to open it, lets just do it and use it as a starting point.
  


Should be pretty easy. I'll file a JIRA.

-- Kevin


Richard Bair wrote:

That's pretty much it.  VP6, T2K, deploy, FX JMX tooling.



VP6 won't ever be opened because it is licensed 3rd party code. However it 
isn't used that much anymore, most folks are using h.264. T2K I will come back 
to. Deploy code (meaning, Applets) is not planned to be open sourced, and I 
don't think it can be, unless JavaSE open sources all the applet / webstart 
code. The JMX tooling code really doesn't work well (last I tried it didn't 
work at all…). However I have big plans for JMX tooling in the 9 timeframe 
which might come to fruition (anybody out there interested in live-debugging 
JavaFX let me know, I've got a project for you!). I don't now that we should 
bother open sourcing the JMX tooling code vs. just replacing it.

Kevin, if it is easy to open it, lets just do it and use it as a starting point.

For T2K, I'm a little unclear and hope someone can help clear up for me under 
what circumstances we use T2K in the shipping product. My current understanding 
was that we use native fonts for every platform except maybe embedded, but that 
we want to switch from T2K to native fonts (Pango or HarfBuzz or whatnot) soon. 
Is that right?

The JDK uses an open source font library for OpenJDK, but T2K for the Oracle 
JDK. On FX we just wanted to have a single implementation that was used by 
both. The hope is that besides Applet code and VP6, everything in the Oracle 
JavaFX would be available in OpenJFX, so that JavaFX is truly an open source 
project built on open source code.

For you guys at RedHat, the answer is: everything is open source. Go forth, 
build, and prosper :-). I read on twitter Miho succeeded in a build of OpenJFX 
based on OpenJDK. I think the doors are open for business. Other than we still 
need the mercurial server moved from version .9 to something modern so that we 
can have outside committers commit to the repo directly, whereas right now it 
would require gate repos. Sadness. But if it takes a Gate repo we'll use a darn 
gate repo so that we can be a real open source project.

Richard

Re: Media is now opensource

[Kevin Rushforth]

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


Kevin Rushforth wrote:

Regarding JMX:


Kevin, if it is easy to open it, lets just do it and use it as a starting point.
  


Should be pretty easy. I'll file a JIRA.

-- Kevin


Richard Bair wrote:

That's pretty much it.  VP6, T2K, deploy, FX JMX tooling.



VP6 won't ever be opened because it is licensed 3rd party code. However it 
isn't used that much anymore, most folks are using h.264. T2K I will come back 
to. Deploy code (meaning, Applets) is not planned to be open sourced, and I 
don't think it can be, unless JavaSE open sources all the applet / webstart 
code. The JMX tooling code really doesn't work well (last I tried it didn't 
work at all…). However I have big plans for JMX tooling in the 9 timeframe 
which might come to fruition (anybody out there interested in live-debugging 
JavaFX let me know, I've got a project for you!). I don't now that we should 
bother open sourcing the JMX tooling code vs. just replacing it.

Kevin, if it is easy to open it, lets just do it and use it as a starting point.

For T2K, I'm a little unclear and hope someone can help clear up for me under 
what circumstances we use T2K in the shipping product. My current understanding 
was that we use native fonts for every platform except maybe embedded, but that 
we want to switch from T2K to native fonts (Pango or HarfBuzz or whatnot) soon. 
Is that right?

The JDK uses an open source font library for OpenJDK, but T2K for the Oracle 
JDK. On FX we just wanted to have a single implementation that was used by 
both. The hope is that besides Applet code and VP6, everything in the Oracle 
JavaFX would be available in OpenJFX, so that JavaFX is truly an open source 
project built on open source code.

For you guys at RedHat, the answer is: everything is open source. Go forth, 
build, and prosper :-). I read on twitter Miho succeeded in a build of OpenJFX 
based on OpenJDK. I think the doors are open for business. Other than we still 
need the mercurial server moved from version .9 to something modern so that we 
can have outside committers commit to the repo directly, whereas right now it 
would require gate repos. Sadness. But if it takes a Gate repo we'll use a darn 
gate repo so that we can be a real open source project.

Richard

Change requiring b112 just pushed [was: hg: openjfx/8/graphics/rt: 5 new changesets]

[Kevin Rushforth]

During integration testing, we just pushed a change that makes JDK 
8-b112 the minimum JDK needed. It really isn't need to build openjfx 
(there were some deploy UI interface changes that motivated this), you 
can just manually set this back to b111 and continue building.


I expected that b112 would have been uploaded to java.net by now. Sorry 
for the inconvenience


-- Kevin


hang...@oracle.com wrote:

Changeset: ceed8d426c0c
Author:mhowe
Date:  2013-10-20 19:27 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ceed8d426c0c

update build.properties

! build.properties

Changeset: 98accc42134c
Author:mhowe
Date:  2013-10-20 19:35 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98accc42134c

update build.properties

! build.properties

Changeset: b5b14c01d4d6
Author:mhowe
Date:  2013-10-21 12:37 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b5b14c01d4d6

RT-33666: [packager] javafxpackager loads AWT unconditionally [krushforth]

! modules/fxpackager/src/main/java/com/javafx/main/Main.java
! modules/fxpackager/src/main/java/com/javafx/main/NoJavaFXFallback.java

Changeset: 5e2ca3c5b155
Author:mhowe
Date:  2013-10-21 15:18 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5e2ca3c5b155

Merge


Changeset: 50cde3719e4d
Author:jgodinez
Date:  2013-10-22 09:41 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/50cde3719e4d

Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt

- 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PasswordFieldSkin.java
- modules/fxml/src/test/java/javafx/fxml/FXMLLoader_events.java
- modules/fxml/src/test/java/javafx/fxml/RT_18046Test.java
- modules/fxml/src/test/resources/javafx/fxml/rt_18046.fxml
- obsolete/apps/build-defs.xml
- obsolete/apps/build-tasks.xml
- obsolete/apps/build.xml
- obsolete/apps/experiments/3DViewer/3D Viewer.iml
- obsolete/apps/experiments/3DViewer/build.xml
- obsolete/apps/experiments/3DViewer/session.properties
- obsolete/apps/experiments/ConferenceScheduleApp/build.xml
- obsolete/apps/experiments/Modena/Modena.iml
- obsolete/apps/experiments/Modena/build.xml
- obsolete/apps/experiments/ModenaTest/build.xml
- obsolete/apps/experiments/build.xml
- obsolete/apps/samples/Ensemble8/Ensemble8.iml
- obsolete/apps/samples/Ensemble8/build.xml
- obsolete/apps/samples/build.xml
- obsolete/base.properties
- obsolete/build-decora.xml
- obsolete/build-defs.xml
- obsolete/build.xml
- obsolete/common.properties
- obsolete/decora-compiler/build-closed.xml
- obsolete/decora-compiler/build-common.xml
- obsolete/decora-compiler/build.xml
- obsolete/decora-compiler/nbproject/project.xml
- obsolete/decora-compiler/project.properties
- obsolete/decora-d3d/build-closed.xml
- obsolete/decora-d3d/build-common.xml
- obsolete/decora-d3d/build.xml
- obsolete/decora-d3d/decora-d3d.iml
- obsolete/decora-d3d/nbproject/project.xml
- obsolete/decora-d3d/project.properties
- obsolete/decora-es2/build-closed.xml
- obsolete/decora-es2/build-common.xml
- obsolete/decora-es2/build.xml
- obsolete/decora-es2/decora-es2.iml
- obsolete/decora-es2/nbproject/project.xml
- obsolete/decora-es2/project.properties
- obsolete/decora-jsw/build-closed.xml
- obsolete/decora-jsw/build-common.xml
- obsolete/decora-jsw/build.xml
- obsolete/decora-jsw/decora-jsw.iml
- obsolete/decora-jsw/nbproject/project.xml
- obsolete/decora-jsw/project.properties
- obsolete/decora-prism-ps/build-closed.xml
- obsolete/decora-prism-ps/build-common.xml
- obsolete/decora-prism-ps/build.xml
- obsolete/decora-prism-ps/decora-prism-ps.iml
- obsolete/decora-prism-ps/nbproject/project.xml
- obsolete/decora-prism-ps/project.properties
- obsolete/decora-prism-sw/build-closed.xml
- obsolete/decora-prism-sw/build-common.xml
- obsolete/decora-prism-sw/build.xml
- obsolete/decora-prism-sw/decora-prism-sw.iml
- obsolete/decora-prism-sw/nbproject/project.xml
- obsolete/decora-prism-sw/project.properties
- obsolete/decora-prism/build-closed.xml
- obsolete/decora-prism/build-common.xml
- obsolete/decora-prism/build.xml
- obsolete/decora-prism/decora-prism.iml
- obsolete/decora-prism/nbproject/project.xml
- obsolete/decora-prism/project.properties
- obsolete/decora-runtime/build-closed.xml
- obsolete/decora-runtime/build-common.xml
- obsolete/decora-runtime/build.xml
- obsolete/decora-runtime/decora-runtime.iml
- obsolete/decora-runtime/nbproject/project.xml
- obsolete/decora-runtime/project.properties
- obsolete/decora-sse-native/Makefile
- obsolete/decora-sse-native/nbproject/Makefile-Debug.mk
- obsolete/decora-sse-native/nbproject/Makefile-Release.mk
- obsolete/decora-sse-native/nbproject/Makefile-impl.mk
- obsolete/decora-sse-native/nbproject/configurations.xml
- obsolete/decora-sse-native/nbproject/project.xml
- obsolete/decora-sse/build-closed.xml
- obsolete/decora-sse/build-common.xml
- obsolete/decora-sse/build-macosx.xml
- obsolete/decora-sse/build-windo

Re: Change requiring b112 just pushed [was: hg: openjfx/8/graphics/rt: 5 new changesets]

[Kevin Rushforth]

Btw, the file you will need to edit is "build.properties", making the 
following change until b112 is available on java.net:


diff --git a/build.properties b/build.properties
--- a/build.properties
+++ b/build.properties
@@ -53,4 +53,4 @@

jfx.build.jdk.version=1.8.0
jfx.build.jdk.buildnum=112
-jfx.build.jdk.buildnum.min=112
+jfx.build.jdk.buildnum.min=111


-- Kevin


Kevin Rushforth wrote:
During integration testing, we just pushed a change that makes JDK 
8-b112 the minimum JDK needed. It really isn't need to build openjfx 
(there were some deploy UI interface changes that motivated this), you 
can just manually set this back to b111 and continue building.


I expected that b112 would have been uploaded to java.net by now. 
Sorry for the inconvenience


-- Kevin


hang...@oracle.com wrote:

Changeset: ceed8d426c0c
Author:mhowe
Date:  2013-10-20 19:27 -0700
URL:   
http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ceed8d426c0c


update build.properties

! build.properties

Changeset: 98accc42134c
Author:mhowe
Date:  2013-10-20 19:35 -0700
URL:   
http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98accc42134c


update build.properties

! build.properties

Changeset: b5b14c01d4d6
Author:mhowe
Date:  2013-10-21 12:37 -0700
URL:   
http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b5b14c01d4d6


RT-33666: [packager] javafxpackager loads AWT unconditionally 
[krushforth]


! modules/fxpackager/src/main/java/com/javafx/main/Main.java
! modules/fxpackager/src/main/java/com/javafx/main/NoJavaFXFallback.java

Changeset: 5e2ca3c5b155
Author:mhowe
Date:  2013-10-21 15:18 -0700
URL:   
http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5e2ca3c5b155


Merge


Changeset: 50cde3719e4d
Author:jgodinez
Date:  2013-10-22 09:41 -0700
URL:   
http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/50cde3719e4d


Automated merge with 
ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt


- 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PasswordFieldSkin.java 


- modules/fxml/src/test/java/javafx/fxml/FXMLLoader_events.java
- modules/fxml/src/test/java/javafx/fxml/RT_18046Test.java
- modules/fxml/src/test/resources/javafx/fxml/rt_18046.fxml
- obsolete/apps/build-defs.xml
- obsolete/apps/build-tasks.xml
- obsolete/apps/build.xml
- obsolete/apps/experiments/3DViewer/3D Viewer.iml
- obsolete/apps/experiments/3DViewer/build.xml
- obsolete/apps/experiments/3DViewer/session.properties
- obsolete/apps/experiments/ConferenceScheduleApp/build.xml
- obsolete/apps/experiments/Modena/Modena.iml
- obsolete/apps/experiments/Modena/build.xml
- obsolete/apps/experiments/ModenaTest/build.xml
- obsolete/apps/experiments/build.xml
- obsolete/apps/samples/Ensemble8/Ensemble8.iml
- obsolete/apps/samples/Ensemble8/build.xml
- obsolete/apps/samples/build.xml
- obsolete/base.properties
- obsolete/build-decora.xml
- obsolete/build-defs.xml
- obsolete/build.xml
- obsolete/common.properties
- obsolete/decora-compiler/build-closed.xml
- obsolete/decora-compiler/build-common.xml
- obsolete/decora-compiler/build.xml
- obsolete/decora-compiler/nbproject/project.xml
- obsolete/decora-compiler/project.properties
- obsolete/decora-d3d/build-closed.xml
- obsolete/decora-d3d/build-common.xml
- obsolete/decora-d3d/build.xml
- obsolete/decora-d3d/decora-d3d.iml
- obsolete/decora-d3d/nbproject/project.xml
- obsolete/decora-d3d/project.properties
- obsolete/decora-es2/build-closed.xml
- obsolete/decora-es2/build-common.xml
- obsolete/decora-es2/build.xml
- obsolete/decora-es2/decora-es2.iml
- obsolete/decora-es2/nbproject/project.xml
- obsolete/decora-es2/project.properties
- obsolete/decora-jsw/build-closed.xml
- obsolete/decora-jsw/build-common.xml
- obsolete/decora-jsw/build.xml
- obsolete/decora-jsw/decora-jsw.iml
- obsolete/decora-jsw/nbproject/project.xml
- obsolete/decora-jsw/project.properties
- obsolete/decora-prism-ps/build-closed.xml
- obsolete/decora-prism-ps/build-common.xml
- obsolete/decora-prism-ps/build.xml
- obsolete/decora-prism-ps/decora-prism-ps.iml
- obsolete/decora-prism-ps/nbproject/project.xml
- obsolete/decora-prism-ps/project.properties
- obsolete/decora-prism-sw/build-closed.xml
- obsolete/decora-prism-sw/build-common.xml
- obsolete/decora-prism-sw/build.xml
- obsolete/decora-prism-sw/decora-prism-sw.iml
- obsolete/decora-prism-sw/nbproject/project.xml
- obsolete/decora-prism-sw/project.properties
- obsolete/decora-prism/build-closed.xml
- obsolete/decora-prism/build-common.xml
- obsolete/decora-prism/build.xml
- obsolete/decora-prism/decora-prism.iml
- obsolete/decora-prism/nbproject/project.xml
- obsolete/decora-prism/project.properties
- obsolete/decora-runtime/build-closed.xml
- obsolete/decora-runtime/build-common.xml
- obsolete/decora-runtime/build.xml
- obsolete/decora-runtime/decora-runtime.iml
- obsolete/decora-runtime/nbproject/project.xml
- obsolete/decora-runtime/project.properties
- obsolete/decora-sse-native/Makefile
- 

Re: CFV: New OpenJFX Committer: Oleg Barbashov

[Kevin Rushforth]

Vote: YES

Btw, the correct repo is:

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

-- Kevin


Artem Ananiev wrote:


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


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


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

Votes are due by Nov 07, 2013.

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


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


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

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

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

Thanks,

Artem

Re: CFV: New OpenJFX Committer: Victor Shubov

[Kevin Rushforth]

Vote: YES

-- Kevin


Artem Ananiev wrote:


I hereby nominate Victor Shubov to OpenJFX Committer.

Victor is a member of JavaFX SQE team at Oracle. He has already 
contributed enough changesets into the "tests" repository:


$ hg log -M -u "Victor Shubov" --template '{author}\n' |wc -l
29

Votes are due by Nov 07, 2013.

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


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


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

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

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

Thanks,

Artem

Re: CFV: New OpenJFX Committer: Assaf Yavani

[Kevin Rushforth]

Vote: YES


David Hill wrote:


I hereby nominate Assaf Yavnai to OpenJFX Committer.

Assaf is a member of JavaFX Embedded team at Oracle. Most of Assaf's 
changes are in Glass/Lens support code:


  hg log -u "Assaf Yavani"

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


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

Votes are due by Nov 13, 2013.

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


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


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

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

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

Thanks,

Dave

JMX is now open source

[Kevin Rushforth]

The JMX tooling code is now open-source in modules/jmx. This means that 
we really are down to just the following optional pieces that will 
remain closed: VP6, T2K, and deploy.


-- Kevin

Re: CFV: New OpenJFX Committer: Rafi Tayar

[Kevin Rushforth]

Vote: Yes

David Hill wrote:


[ resending it with a corrected subject line. The dangers of reusing a 
form]


I hereby nominate Rafi Tayar to OpenJFX Committer.

Rafi is a member of JavaFX Embedded team at Oracle. Rafi's changes are 
in Glass/Lens support code:


  hg log -M -u "Rafi Tayar"

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


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

Votes are due by Nov 19, 2013.

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


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


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

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

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

Thanks,

Dave

Re: JFXPanel with WebView in JDK8

[Kevin Rushforth]

Please file a JIRA at:  https://javafx-jira.kenai.com/

Thanks.

-- Kevin


Lidierth Malcolm wrote:


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

public class NewFXMain1 {

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


EventQueue.invokeAndWait(new Runnable() {

// Create the Swing components on the EDT
@Override
public void run() {
JFrame f = new JFrame();
f.getContentPane().setPreferredSize(new Dimension(500, 
500));

f.pack();
f.setVisible(true);
final JFXPanel jfx = new JFXPanel();
f.getContentPane().add(jfx);

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


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

}
});
}
}


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

Executing 
C:\Users\malcolm\Documents\waterloo\Sources\Java\kcl-waterloo-jfx\dist\run1852659813\kcl-waterloo-jfx.jar 
using platform C:\Program Files\Java\jdk1.8.0/bin/java

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at 
javafx.embed.swing.JFXPanel.getInputMethodRequests(JFXPanel.java:744)
at 
sun.awt.im.InputMethodAdapter.haveActiveClient(InputMethodAdapter.java:61) 


at sun.awt.windows.WInputMethod.activate(WInputMethod.java:285)
at sun.awt.im.InputContext.activateInputMethod(InputContext.java:396)
at sun.awt.im.InputContext.focusGained(InputContext.java:338)
at sun.awt.im.InputContext.dispatchEvent(InputContext.java:245)
at 
sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:196)

at java.awt.Component.dispatchEventImpl(Component.java:4817)
at java.awt.Container.dispatchEventImpl(Container.java:2293)
at java.awt.Component.dispatchEvent(Component.java:4707)
at 
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1954) 

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

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


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

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


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


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

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

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

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

at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)

Heads-up: Bumping minimum build number to b113

[Kevin Rushforth]

As a heads-up, I need to bump the minimum JDK 8 version number required 
for building FX to b113 (is currently b112) to fix a problem building 
one of our closed files that uses a java.net class in the JDK which has 
changed.


FX JIRA:  https://javafx-jira.kenai.com/browse/RT-34085
JDK issue which broke us:  https://bugs.openjdk.java.net/browse/JDK-8014719

I will push this change shortly.

-- Kevin

Re: did anyone encountered this?

[Kevin Rushforth]

I see this from time to time. This is a bug in the version of ant that 
is used by gradle for dependencies. It has been reported that gradle 1.8 
may have a newer version of ant that fixes this bug.


In the mean time, a less intrusive workaround is:

   gradle -PUSE_DEPEND=false ...

If enough people are getting bitten by this, should we consider making 
USE_DEPEND=false the default?


-- Kevin


Artem Ananiev wrote:


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


Thanks,

Artem

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

:apps:experiments:3DViewer:compileJava FAILED

FAILURE: Build failed with an exception.

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

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

BUILD FAILED

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

Thanks,
Assaf

[Fwd: Review request for RT-34111: Scaling problem when printing using Canon Inkjet iP100]

[Kevin Rushforth]

--- Begin Message ---

Hi Phil, Kevin,

Please review RT-34111.
Bug Description and Webrev : https://javafx-jira.kenai.com/browse/RT-34111
Bug summary:   Printout shows a scaled down version of the screen output.

Thank you.

Jennifer
--- End Message ---

hg: openjfx/8/master: RT-32156: Cleanup top-level openjfx repo for FX 8

[kevin . rushforth]

Changeset: b80799b32c69
Author:kcr
Date:  2013-11-06 16:41 -0800
URL:   http://hg.openjdk.java.net/openjfx/8/master/rev/b80799b32c69

RT-32156: Cleanup top-level openjfx repo for FX 8

- .hgignore
! README
- build-defs.xml
- build-src/build-cache.xml
- build-src/build-component-template.xml
- build-src/build-components.xml
- build-src/build-copy.xml
- build-src/build-cross.xml
- build-src/build-environment.xml
- build-src/build-importer.xml
- build-src/build-inventory.xml
- build-src/build-invoice.xml
- build-src/build-ios-defs.xml
- build-src/build-jar-importer.xml
- build-src/build-linux-defs.xml
- build-src/build-macosx-defs.xml
- build-src/build-os-arch.xml
- build-src/build-perf.xml
- build-src/build-sdk-rt.xml
- build-src/build-solaris-defs.xml
- build-src/build-windows-defs.xml
- build-src/build-zips.xml
- build-src/genVSproperties.bat
- build-src/platform/on-raspberry-pi.properties
- build-src/platform/raspberry-pi.properties
- build-src/startup2_template.html
- build.xml
- project.properties

hg: openjfx/8/graphics: RT-32156: Cleanup top-level openjfx repo for FX 8

[kevin . rushforth]

Changeset: b80799b32c69
Author:kcr
Date:  2013-11-06 16:41 -0800
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rev/b80799b32c69

RT-32156: Cleanup top-level openjfx repo for FX 8

- .hgignore
! README
- build-defs.xml
- build-src/build-cache.xml
- build-src/build-component-template.xml
- build-src/build-components.xml
- build-src/build-copy.xml
- build-src/build-cross.xml
- build-src/build-environment.xml
- build-src/build-importer.xml
- build-src/build-inventory.xml
- build-src/build-invoice.xml
- build-src/build-ios-defs.xml
- build-src/build-jar-importer.xml
- build-src/build-linux-defs.xml
- build-src/build-macosx-defs.xml
- build-src/build-os-arch.xml
- build-src/build-perf.xml
- build-src/build-sdk-rt.xml
- build-src/build-solaris-defs.xml
- build-src/build-windows-defs.xml
- build-src/build-zips.xml
- build-src/genVSproperties.bat
- build-src/platform/on-raspberry-pi.properties
- build-src/platform/raspberry-pi.properties
- build-src/startup2_template.html
- build.xml
- project.properties

Re: Code Review Policies

[Kevin Rushforth]

Yes, several of us have "kicked the tires" of Crucible for internal 
reviews. Many of us, including me, like it quite a bit. I am hopeful 
that OpenJDK will move to a modern tool than webrev + JIRA comments, and 
Crucible seems a good choice given that we already use JIRA.


-- Kevin


Richard Bair wrote:

Yes, we've been looking at it. But until OpenJDK manages to get some code 
review tool hosted externally, we want something everybody can use.

Richard

On Nov 7, 2013, at 3:53 PM, Mark Fortner  wrote:

  

Did you guys ever take a look at Crucible (part of the Atlassian suite)?  It 
makes diff's easier to read, and lets you provide feedback in the context of 
the code.

Cheers,

Mark



On Thu, Nov 7, 2013 at 3:21 PM, Richard Bair  wrote:
Awesome! Thanks guys. I hope everybody else sees what I see here -- a constant 
continually effort to improve OpenJFX and make it a real Open Source project in 
every sense of the word. Major thanks to Steve for pushing on this so hard.

Richard

On Nov 7, 2013, at 6:36 AM, Stephen F Northover  
wrote:



Hello Committers,

Let me summarize how to initiate a code review, since this changed recently.

All information about how a bug was fixed needs to be in the JIRA. This means 
that all patches, webrevs, discussions and who is doing the review needs to be 
captured there.  The email to openjfx-dev is intended to inform the community 
that a review is happening so others can join in, but it doesn't need to 
contain detailed information about the fix.  People can get all that from the 
JIRA.

This about it this way:  What we are trying to avoid is having any interesting 
information about the fix appear only in the mailing list.  The bottom line is 
that the comment section of JIRA should contains the contents of the email that 
previously you would have sent to the list.  If you want the information to be 
in two places, that is fine, but it must be in the JIRA.  However, the 
discussion and any subsequent action is in the JIRA.

https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews

Thanks,
Steve and Daniel

  



  

Re: did anyone encountered this?

[Kevin Rushforth]

As a follow-up to this, yes it has been fixed in gradle 1.8:

http://issues.gradle.org/browse/GRADLE-2831

We won't be switching our builds to gradle 1.8 for FX 8, but if 
developers want to give it a try on their own systems, that would be fine.


-- Kevin

Kevin Rushforth wrote:
I see this from time to time. This is a bug in the version of ant that 
is used by gradle for dependencies. It has been reported that gradle 
1.8 may have a newer version of ant that fixes this bug.


In the mean time, a less intrusive workaround is:

   gradle -PUSE_DEPEND=false ...

If enough people are getting bitten by this, should we consider making 
USE_DEPEND=false the default?


-- Kevin


Artem Ananiev wrote:


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


Thanks,

Artem

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

:apps:experiments:3DViewer:compileJava FAILED

FAILURE: Build failed with an exception.

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

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

BUILD FAILED

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

Thanks,
Assaf

Re: Generating and cleaning up our JavaDoc

[Kevin Rushforth]

Thanks, Jonathan, I think this is a worthy effort. I usually use the 
latter (... clean sdk) to build the javadoc at the same time I build the 
SDK when I want to look at the javadoc-generated API docs, but either 
should work.


-- Kevin


Jonathan Giles wrote:

Hi all,

This email serves partly as a useful tip (assuming I'm correct), and
partly as a request for improving the current javadoc build situation.

Firstly, the presumed tip: to generate JavaDoc in our new gradle build
setup, it appears necessary to set BUILD_JAVADOC to true. It would seem
that to do this, you pass in the following to your preferred shell from
within the rt directory:

gradle -PBUILD_JAVADOC=true javadoc

Alternatively, you could do something like:

gradle -PBUILD_JAVADOC=true clean sdk

You can then find the generated documentation in /rt/build/javadoc

If I'm wrong, I look forward to being corrected, now that I'm trying to
clean up the javadoc output prior to 8.0 shipping.

On to the request: we have a lot of javadoc warnings. This is always the
case at this stage of the release, and I always start asking nicely (aka
nagging) so that we get things in order. I've dreamt for a long time
that we would fail the appropriate automated builds whenever a javadoc
warning or error was encountered, and whilst now is not the best time to
do this, perhaps we should look into this after 8.0 freezes.

Anywho, if anyone is keen to help improve the quality of our javadocs, I
am keen to work with you. Please drop me a note. What I really want to
do is get our warning / error count to zero (or as close to it as
possible). We have a lot of warnings like this (just to pick two):

rt\modules\controls\src\main\java\javafx\scene\control\ListView.java:854: 
warning
- Tag @link: can't find scrollTo(S) in javafx.scene.control.ListView
rt\modules\graphics\src\main\java\javafx\scene\input\DragEvent.java:434:
warning - @param argument "eventType" is not a parameter name.

Thanks,
-- Jonathan
  

Re: Exception trying to embedd SceneBuilder EA 2.0 into NetBeans

[Kevin Rushforth]

A NoSuchMethodError is almost always the result of running classes that 
were compiled against one version of the class files with a class 
library that has make incompatible changes.


In particular, there was an incompatible change in b114 that makes SB 
compiled with b113 not run.


-- Kevin


Sven Reimers wrote:

HI guys,

trying the above experiment I get the NoSuchMethodError pasted below.

Anyone can shed some light on it?

Seems SceneBuilder 2.0 ea b6 uses jdk8 b113 internally and I am running on
b114..

-Sven

java.lang.NoSuchMethodError: javafx.fxml.FXMLLoader.setStaticLoad(Z)V
at
com.oracle.javafx.scenebuilder.kit.util.Deprecation.setStaticLoad(Deprecation.java:131)
at
com.oracle.javafx.scenebuilder.kit.fxom.FXOMLoader.load(FXOMLoader.java:72)
at
com.oracle.javafx.scenebuilder.kit.fxom.FXOMDocument.(FXOMDocument.java:71)
at
com.oracle.javafx.scenebuilder.kit.editor.EditorController.updateFxomDocument(EditorController.java:1245)
at
com.oracle.javafx.scenebuilder.kit.editor.EditorController.setFxmlTextAndLocation(EditorController.java:428)


  

Re: Build fail: unresolved external symbol mainCRTStartup

[Kevin Rushforth]

Hi Leonid,

Building JavaFX on Windows requires Cygwin, so it doesn't surprise me 
that it fails with a DOS shell.


The error you are seeing on cygwin seems like a mismatch where part of 
the build is trying to use a 32-bit build and part trying to use 64-bit.


My recommendation is to try the following, from a cygwin shell:

1. Ensure that your JAVA_HOME and PATH point to the same version of Java 
(the 32-bit Java).


2. Completely clean your repo

cd rt
gradle clean
rm -rf buildSrc/build buildSrc/.gradle .gradle


3. Rebuild, making sure you compile both media and webkit (not sure if 
needed, but better to remove one more variable):


gradle -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true sdk


See if the above will work.

-- Kevin


Leonid Popov wrote:

Hi Steve,

Yes, I use 32-bit JDK for building. I tried to build it from both 
Windows and Cygwin command shells. The error I mentioned happens when 
building from Windows. If I try to build it from Cygwin, I get another 
error:


Building Webkit configuration /Release/ into 
C:\javafx\8my\jfx\rt\modules\web\build/win
Calling 'qmake -makefile 
C:/javafx/8my/jfx/rt/modules/web/src/main/native/Source/WebKitJava.pro 
CONFIG-=debug CONFIG+=release DEFINES+=IMAGEIO=1' in 
"C:/javafx/8my/jfx/rt/modules/web/build/win/Release" ...



Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

cd JavaScriptCore\ && C:\MsVS10\VC\BIN\nmake.exe -f 
Makefile.JavaScriptCoreJava


Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

lib /NOLOGO  /OUT:..\lib\JavaScriptCoreJava.lib @.\nm2BB0.tmp
obj\YarrInterpreter.obj : fatal error LNK1112: module machine type 
'X86' conflicts with target machine type 'x64'
NMAKE : fatal error U1077: 'C:\MsVS10\VC\BIN\lib.EXE' : return code 
'0x458'

Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.

My script for Cygwin is:

export DXSDK_DIR=/cygdrive/c/DXSDK/
export WMSDK_DIR=/cygdrive/c/WMSDK/WMFSDK11/
export QTSDK_DIR=/cygdrive/c/Qt/4.6.0/

export VSINSTALLDIR=/cygdrive/C/MsVS10
export WINDOWS_VS_PATH=/cygdrive/C/MsVS10/VC/bin

export GRADLE_DIR=/cygdrive/c/tools/gradle/

export JDK_HOME=/cygdrive/c/java/8b112/
export JAVA_HOME=$JDK_HOME

export ANT_HOME=/cygdrive/c/ant/

export 
PATH=$GRADLE_DIR/bin/:$JAVA_HOME/bin/:$DXSDK_DIR/Utilities/Bin/x86:$PATH


$GRADLE_DIR/bin/gradle -PCOMPILE_WEBKIT=true -PCONF=Debug sdk

I'm trying but I can't realize what changed after my last successfull 
build.


Leonid.


On 11/8/2013 9:10 PM, Stephen F Northover wrote:

Hi Leonid,

I have the same configuration as you I think.  I'm just making sure I 
can build.  First, do you have 32-bit JDK8?  Are you running under a 
cygwin shell?  What is your gradle command line?


Steve

On 2013-11-08 9:08 AM, Leonid Popov wrote:

Hi,

I've just cloned a new workspace from 
ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx and tried 
to build it. The following error encountered:


link /LIBPATH:"..\lib" /NOLOGO /MAP /INCREMENTAL:NO 
/SUBSYSTEM:CONSOLE /MANIFEST 
/MANIFESTFILE:"obj\DerivedSourcesJava.intermediate.manifest" 
/OUT:..\lib\DerivedSourcesJava.exe 
@C:\Users\lp154592\AppData\Local\Temp\nm9A16.tmp

LINK : error LNK2001: unresolved external symbol mainCRTStartup
..\lib\DerivedSourcesJava.exe : fatal error LNK1120: 1 unresolved 
externals


My box is Windows 7 64-bit with MSVS 10 installed; Gradle 1.4 is 
used for building.


Any suggestions?

Thanks,
Leonid

Re: Build failure: Unexpected element "{}HTML" {antlib:org.apache.tools.ant}HTML

[Kevin Rushforth]

Since this is in the "closed" part of the build, few people on the list 
would have seen it.



update-cached-sdk:
 [java] Buildfile: 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build.xml

 [java]
 [java] BUILD FAILED
 [java] 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build.xml:2: 
Unexpected element "{}HTML" {antlib:org.apache.tools.ant}HTML 


Makybe there is a problem using ant 1.9.2 (the official build version is 
1.8.2). Having said that, I think someone else must have done a closed 
build with ant 1.9.X at some point.


-- Kevin


Anthony Petrov wrote:

Has anyone seen this before?

I've just cloned a fresh repo. I'm on Linux x64 and using:
JAVA_HOME= 7u45 x64
JDK_HOME= 8b114 x64
ant 1.9.2 (from my Linux distro)
gradle 1.8


:antUpdateCacheIfNeeded
Buildfile: /export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build.xml
  [taskdef] Could not load definitions from resource 
net/sf/antcontrib/antcontrib.properties. It could not be found.
[mkdir] Created dir: 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
  [taskdef] Could not load definitions from resource 
net/sf/antcontrib/antlib.xml. It could not be found.


-check-hudson:

update-cached-sdk-if-needed:
  [taskdef] Could not load definitions from resource 
net/sf/antcontrib/antcontrib.properties. It could not be found.
  [taskdef] Could not load definitions from resource 
net/sf/antcontrib/antlib.xml. It could not be found.


clean-cached-sdk:

update-cached-sdk:
 [java] Buildfile: 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build.xml

 [java]
 [java] BUILD FAILED
 [java] 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build.xml:2: 
Unexpected element "{}HTML" {antlib:org.apache.tools.ant}HTML

 [java]
 [java] Total time: 0 seconds

BUILD FAILED
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build-src/build-cache.xml:141: 
The following error occurred while executing this line:
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build-src/build-cache.xml:75: 
The following error occurred while executing this line:
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build-defs.xml:326: 
The following error occurred while executing this line:
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build-defs.xml:221: 
Java returned: 1


Total time: 1 second
:antUpdateCacheIfNeeded FAILED



--
best regards,
Anthony

Re: Build failure: Unexpected element "{}HTML" {antlib:org.apache.tools.ant}HTML

[Kevin Rushforth]

Never mind. I see that you already resolved this by downgrading ant.

-- Kevin


Kevin Rushforth wrote:
Since this is in the "closed" part of the build, few people on the 
list would have seen it.



update-cached-sdk:
 [java] Buildfile: 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build.xml

 [java]
 [java] BUILD FAILED
 [java] 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build.xml:2: 
Unexpected element "{}HTML" {antlib:org.apache.tools.ant}HTML 


Makybe there is a problem using ant 1.9.2 (the official build version 
is 1.8.2). Having said that, I think someone else must have done a 
closed build with ant 1.9.X at some point.


-- Kevin


Anthony Petrov wrote:

Has anyone seen this before?

I've just cloned a fresh repo. I'm on Linux x64 and using:
JAVA_HOME= 7u45 x64
JDK_HOME= 8b114 x64
ant 1.9.2 (from my Linux distro)
gradle 1.8


:antUpdateCacheIfNeeded
Buildfile: /export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build.xml
  [taskdef] Could not load definitions from resource 
net/sf/antcontrib/antcontrib.properties. It could not be found.
[mkdir] Created dir: 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
 [copy] Copying 1 file to 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build/xml_generated
  [taskdef] Could not load definitions from resource 
net/sf/antcontrib/antlib.xml. It could not be found.


-check-hudson:

update-cached-sdk-if-needed:
  [taskdef] Could not load definitions from resource 
net/sf/antcontrib/antcontrib.properties. It could not be found.
  [taskdef] Could not load definitions from resource 
net/sf/antcontrib/antlib.xml. It could not be found.


clean-cached-sdk:

update-cached-sdk:
 [java] Buildfile: 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build.xml

 [java]
 [java] BUILD FAILED
 [java] 
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build.xml:2: 
Unexpected element "{}HTML" {antlib:org.apache.tools.ant}HTML

 [java]
 [java] Total time: 0 seconds

BUILD FAILED
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build-src/build-cache.xml:141: 
The following error occurred while executing this line:
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build-src/build-cache.xml:75: 
The following error occurred while executing this line:
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build-defs.xml:326: 
The following error occurred while executing this line:
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174/build-defs.xml:221: 
Java returned: 1


Total time: 1 second
:antUpdateCacheIfNeeded FAILED



--
best regards,
Anthony

CFV: New OpenJFX Committer: Mark Howe

[Kevin Rushforth]

I hereby nominate Mark Howe (OpenJDK user name: mhowe) to OpenJFX Committer.

Mark is a member of JavaFX deployment team at Oracle. Most of Mark's 
changes are in the JavaFX pacakager:


 hg log -u "mhowe"

A partial list of Mark's commits and reviews is also available by the 
following link:


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

Votes are due by Nov 28, 2013.

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


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


[1] http://openjdk.java.net/census#openjfx
[2] http://openjdk.java.net/bylaws#lazy-consensus
[3] http://openjdk.java.net/projects#project-committer

Thanks,

-- Kevin

jfxswt.jar missing from b115

[Kevin Rushforth]

As an FYI for anyone using FXCanvas for SWT interop, we introduced a bug 
in JDK 8 b115, RT-34169 , 
that caused jfxswt.jar to go missing. The bug is already fixed in the 
soon-to-be-released b116.


-- Kevin

Re: Review request for RT-34236 FXMLLoader throws " java.lang.InternalError: CallerSensitive annotation expected at frame 1 "

[Kevin Rushforth]

Thanks Mark. Can you please add this information to the JIRA (including 
the link to the new webrev) ?


-- Kevin


Mark Howe wrote:
This is a slightly dialed back version. Basically the same thing as 
the first webrev except left the API for setEmbeddedLauncher, because 
that is used by some app.s



Kevin and David please review
http://cr.openjdk.java.net/~kcr/RT-34236.1/ 




On Nov 14, 2013, at 7:08 PM, Mark Howe > wrote:



Jira: https://javafx-jira.kenai.com/browse/RT-34236
Webrev: http://cr.openjdk.java.net/~kcr/RT-34236/

Thanks
Mark

Re: Review request for RT-34236 FXMLLoader throws " java.lang.InternalError: CallerSensitive annotation expected at frame 1 "

[Kevin Rushforth]

Please add that to the JIRA, then. For FX, all discussion should happen 
there. See https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews


-- Kevin


David DeHaven wrote:

Looks fine to me.

-DrD-

  

Thanks Mark. Can you please add this information to the JIRA (including the 
link to the new webrev) ?

-- Kevin


Mark Howe wrote:


This is a slightly dialed back version. Basically the same thing as the first 
webrev except left the API for setEmbeddedLauncher, because that is used by 
some app.s


Kevin and David please review
http://cr.openjdk.java.net/~kcr/RT-34236.1/


On Nov 14, 2013, at 7:08 PM, Mark Howe  wrote:

  

Jira: https://javafx-jira.kenai.com/browse/RT-34236
Webrev: http://cr.openjdk.java.net/~kcr/RT-34236/

Thanks
Mark



  

FX 8 Dev Dashboard in JIRA

[Kevin Rushforth]

All,

As you know we are in the endgame of FX 8 (aka "Lombard") for JDK 8. 
Here is the Dashboard we are using on the engineering side to track our 
bugs:


https://javafx-jira.kenai.com/secure/Dashboard.jspa?selectPageId=11893

The main table is the one in the upper left of the dashboard which shows 
open bugs by priority assigned to each engineer. Also useful are the Pie 
charts that show untriaged (New) bugs and deferral requests.


We need to get the list of open bugs down to near zero (*) by ZBB, 
either by fixing them or deferring them. The only bugs that should be 
left when we hit ZBB are those bugs filed within the last 7 days, and 
javadoc/test bugs.


-- Kevin

Re: Proportional paint object behavior inconsistent and needs to change

[Kevin Rushforth]

I haven't thought through all of the implications, but my initial take 
is the same as Jim's. Namely, that using the fill bounds for 
proportional paints is the most consistent and will have the least 
degree of unpleasant surprises.


-- Kevin


Jim Graham wrote:
Felipe mentioned recently that we encountered some issues in fixing a 
bug with SVGPath.


The outcome of this fix could be a significant change in how your 
proportional gradient fills look and so we'd like to get feedback on 
the various ideas.  You can read about them in that Jira issue, but 
I'll also summarize below.  Discussion would probably be better on the 
mailing list, but we eventually need to work the salient points back 
into the Jira issue for future maintenance.


The basic issue is that we had a disagreement between the way that the 
shape caching code worked and the way that uncached shapes were filled 
with proportional paints.


First, there is the concept of tight and loose bounds.  Loose bounds 
are very cheap to calculate, but can contain area not strictly inside 
the shape.  Tight bounds are more careful to figure out exactly how 
far curved sections of the shape reach, but a fair number of 
calculations and recursions are needed to accurately calculate those 
extents.


Our current code will use loose bounds of the basic shape (i.e. the 
part that is filled) to calculate the bounds for proportional paints 
when you first paint a shape - whether you stroke it, fill it, or both.


But, if you ran with shape mask caching (the default mode) then after 
a rendering or 2 we would decide to cache the antialias coverage mask 
and we would then use the node's content bounds to figure the bounds 
for the proportional paint.  The content bounds are calculated more 
precisely as tight bounds, though, so they didn't always agree with 
the bounds used in those first few uncached renderings.


The net result is that the proportional paint would shift after the 
first couple of frames unless you animated the shape and then it would 
revert while you were animating and then shift back when it was stable.


There is also the Canvas object that can also render proportional 
paints, and it does so using the same code that the shape nodes use 
when they don't have their coverage mask cached (i.e. loose fill bounds).


We'd like to make all of this as consistent as possible.  Here are the 
various decisions and how they'd impact code:


- Loose bounds are faster to calculate for shapes that aren't likely 
to be reused.  The uncached shape rendering used them because the 
shapes may change before we need the bounds again.  Canvas uses it 
because it is an immediate mode API with no input on how often it may 
see a particular shape again.


- Tight bounds would likely be less suprising to developers and users, 
though.  They are better for hit testing and damage management because 
they generate fewer false positive hits.  They are also fairly fast to 
calculate for most shapes and it is a rare shape that we'd have to 
recurse much to get it right.  Also, for straight edges there is no 
difference in performance to calculate tight or loose bounds.


All in all, it would probably be better for the FX API to standardize 
on tight bounds and treat any cases where we noticeably affect 
performance (which should be very rare) as opportunities for tuning.  
This may not be compatible with the first rendering of current Shape 
nodes, but they would shift back and forth anyway so we aren't worried 
about incompatibility with an inconsistent system.


The other part of the decision is which bounds to use.

Currently uncached rendering uses fill bounds, and mask-cached 
rendering uses the content bounds which depends on whether you supply 
a stroke or a fill paint so it could be either fill bounds or stroke 
bounds.


- For filled-only shapes we obviously want to use the "fill bounds".

- For stroked and filled shapes, we have 3 choices:

- - use fill bounds for both paints so that the geometry used for 
proportional stroke and fill paints are similar for both parts of 
those nodes.  This helps line up any color discontinuities or 
highlights between the two.


- - use stroke bounds for both which also means the two are 
consistent, but Canvas can't really do this because it doesn't know if 
you are filling and stroking until it sees the latter operation


- - use fill bounds for fill and stroke bounds for stroke which means 
the geometries of the two are different and it makes it harder to line 
up the transitions of proportional stroke+fill shapes, but Canvas can 
do this so Canvas vs. Shape node remain consistent


I'm not sure which of the above is the best, but I lean towards "fill 
bounds for both" because it allows consistent geometry for stroke+fill 
and it allows consistent behavior between Canvas and Shape node, at 
the possible expense of "0% on a stroke isn't at the edge of the stroke".


Thoughts?

...jim

Re: Chances of open sourcing SceneBuilder

[Kevin Rushforth]

Hi Philipp,

There is a JIRA filed to track the open sourcing or SceneBuilder:

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

Someone from the SceneBuilder team can comment on the status of this.

-- Kevin


Philipp Dörfler wrote:

Hello list,

I can’t but acknowledge the work put into SceneBuilder especially when seeing 
SceneBuilder 2 who apparently underwent a serious and well done design overhaul 
(I still want to see a dark theme ;) ). Well done!

As much as I love the new design the Early Access 2.0 version feels very rough 
and makes clear that this tool needs a lot of love. I thought about 
contributing to OpenJFX for quite some time but would actually rather spend 
time on improving SceneBuilder than working on juicy API internals that are 
better left to guys that truly know what they do ;) Things like better IDE 
integration or making the keyframe based animation API accessible in the GUI 
already (To at least partially get to where JavaFX 1 Designer once was or 
wanted to be) come to my mind.

As far as I know there are currently no plans of open sourcing Scene Builder 
but I wondered if there’s even a chance for it and what would be required for 
that to happen? Seeing that the JFX team probably has a very tight schedule and 
spent a lot of time open sourcing the core components already I’m afraid that a 
OSS SceneBuilder would be kind of impossible. Am I too pessimistic?

Cheers,
~ Philipp