hg: openjfx/8/controls/rt: 6 new changesets
Changeset: bfafc21f18d2 Author:jgiles Date: 2013-07-25 15:40 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bfafc21f18d2 RT-31509: -fx-indent badly applied in TreeTableView ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableCellSkin.java Changeset: 3bc3e99f3e3e Author:jgiles Date: 2013-07-25 15:43 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3bc3e99f3e3e RT-31834: PopupControl.CSSBridge not properly documented ! modules/controls/src/main/java/javafx/scene/control/PopupControl.java Changeset: 84108e7351f3 Author:jgiles Date: 2013-07-25 16:38 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/84108e7351f3 RT-31252: Extra TableCells created when scrolling with MouseWheel RT-31286: TableCells display Spurious Values when Scrolling with Mousewheel ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: cd582dc16ee4 Author:jgiles Date: 2013-07-25 17:05 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/cd582dc16ee4 RT-30850: Missing documentation in controls ! modules/controls/src/main/java/javafx/scene/control/Tab.java ! modules/controls/src/main/java/javafx/scene/control/TableColumn.java Changeset: 8cdd7bd93393 Author:jgiles Date: 2013-07-25 17:06 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8cdd7bd93393 Fix javadoc error in TableColumn ! modules/controls/src/main/java/javafx/scene/control/TableColumn.java Changeset: 4b2f8100c18f Author:jgiles Date: 2013-07-25 17:10 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4b2f8100c18f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt
Pushing OpenJFX to Maven - licensing and other stuff (forked from Re: jfxrt.jar - is it platform specific?)
Including the list. Thanks Tom, good to double check the licensing issues. As I understand it all of the OpenJDK and OpenJFX is released under GPLv2 http://openjdk.java.net/legal/gplv2+ce.html I interpret this to mean that it can be redistributed, modified and generally used however we want so long as we distribute it with the same licence. I interpret that to mean we can both deploy any and all openjfx classes and libraries into OSS Maven and also modify the code (as done with the 78-backport) and distribute that via Maven too. If anyone from Oracle has a problem with that, let me know asap. In the absence of any objections I am pushing ahead with the deployment to Maven. On the same topic, my plan is to push only the iOS builds of the 78-backport at this stage. I intend to deploy the iOS jfxrt.jar using the following details: groupId: net.java.openjfx artifactId: openjfx-78-backport version: 1.8.0-ea-b96.1 classifier: ios Where the version is the OpenJFX version the backport was last merged with, plus an extra number for whatever release the backport is up to relative to that build (e.g. we might do several releases of the backport per build of OpenJFX). I also intend to zip up all the native files for the backport and deploy this zip as: groupId: net.java.openjfx artifactId: openjfx-78-backport-native version: 1.8.0-ea-b96.1 classifier: ios Note that both of the above assume that the jfxrt.jar is not architecture specific (the same jar is used on i386 and armv7) and the zip file will contain the native libs for both architectures. If anyone has any objections to any of that or better suggestions, shout out quickly. With some luck this will start to happen in the next day or two and once it's up it's up. You cannot remove or change a file once it is in Maven Central except in extreme cases like licence violation, in which case it is a pretty involved and messy procedure. For builds of OpenJFX other than the backport (including the jfx packaging tools) I have a very strong preference for the JavaFX team to provide me (or anyone willing to get involved with this) all the various built binaries for all the various OS's and architectures and then I will push these into Maven. I prefer this as I really don't like the idea of us out in the community building these in bits and pieces (you do Linux, I'll do windows, etc) with all the ways that can go wrong (accidental mistakes, viruses, malicious people doing bad stuff just for kicks, etc). It would obviously be ideal if Oracle just added a simple push to Maven at the end of their automated build system but they are not that way inclined. Getting the binaries from them would be at least half way there and reduce the scope for problems. From what I've been told, I wouldn't expect these binaries to be provided in a way that makes them easy to get at and upload anytime soon due to internal red tape, so if you are holding out for this stuff to end up in Maven, best to raise that issue with the JFX guys. On Thu, Jul 25, 2013 at 5:09 PM, Tom Schindl tom.schi...@bestsolution.atwrote: Hi, Before you push your stuff to maven-central make sure you are not running into license problems. I [line removed] was pointed then to the license agreement that apply to JSRs (not sure this also applies to javafx because it is NOT JSRed). In the agreement it reads: 2. Distribute implementations of the Specification to third parties for their testing and evaluation use, provided that any such implementation: (i) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; (ii) is clearly and prominently marked with the word UNTESTED or EARLY ACCESS or INCOMPATIBLE or UNSTABLE or BETA in any list of available builds and in proximity to every link initiating its download, where the list or link is under Licensee's control; and (iii) includes the following notice: This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. The grant set forth above concerning your distribution of implementations of the specification is contingent upon your agreement to terminate development and distribution of your early draft implementation as soon as feasible following final completion of the specification. If you fail to do so, the foregoing grant shall be considered null and void. Like I said this is from a JSRed spec but I wanted to make sure you double check the license of JavaFX because once you pushed to maven central it might be hard to remove it once JavaFX8 is released (iii)! Thanks for pushing
AW: FBX Importer for OpenJFX
Hi August, We've done a few tests with Autodesk's FBX converter. Unfortunately we've found no conversion process where our sample model survives 100% intact. Here are some examples (using Autodesk's FBX converter *and* viewer, and one of the sample files provided with it, Bird_Leg.fbx): FBX binary - FBX ASCII:part of the mesh is rotated, part of the animation is lost FBX binary - OBJ: part of the mesh is rotated ( animation is of course lost) FBX binary - DAE / Collada:the whole mesh disappears Since even FBX binary - ASCII conversion can break things, we are considering using Autodesk's FBX SDK (in C++) to import the binary file, then loading it into our Java code via the JNI. Cheers, Rob -Ursprüngliche Nachricht- Von: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] Im Auftrag von August Lammersdorf, InteractiveMesh Gesendet: Donnerstag, 25. Juli 2013 10:41 An: openjfx-dev@openjdk.java.net Betreff: FBX Importer for OpenJFX Hi Rob, I suppose rather COLLADA importers will be available than importers supporting Autodesk's FBX. Do you have any experiences with Autodesk's FBX Converter and the quality of its COLLADA exports? August Am Mittwoch, den 24.07.2013, 09:38 +0200 schrieb Robert Fisher rfis...@tesis.de: Hi all, We would like to be able to load FBX files into the 3DViewer app. Are there any plans to develop an FBX importer, or is this something we should implement ourselves? Thanks in advance. Rob
Re: WebView capabilities review
I have noticed something curious.
When I run the impact.js demo that Klaus posted a link to I see a very
smooth animation. The curious part is that on this same machine I see
noticeable flicker and jittering when I run even the most simple JavaFX
animation and have never seen one that performs as smoothly as the
impact.js demo within WebView. Also, the impact.js demo runs very smoothly
even when I run the WebView maximised.
OK, so now I know that it can't be the actual graphics hardware or driver
that cause JavaFX animations to flicker and clearly JavaFX *can* render
animated content without jittering so why then do simple animations (such
as those from Ensemble) perform so poorly?
On 25 July 2013 02:02, Artem Ananiev artem.anan...@oracle.com wrote:
On 7/24/2013 2:55 AM, Felix Bembrick wrote:
Windows 7 64-bit here.
On this platform, JavaFX web component is compiled without JIT support for
JavaScript:
https://javafx-jira.kenai.com/**browse/RT-24998https://javafx-jira.kenai.com/browse/RT-24998
It explains why it is slow, but it doesn't explain rendering artifacts.
Thanks,
Artem
On 24 July 2013 08:53, Richard Bair richard.b...@oracle.com wrote:
I've filed
https://javafx-jira.kenai.com/**browse/RT-31885https://javafx-jira.kenai.com/browse/RT-31885,
lets see how
that turns out.
Richard
On Jul 23, 2013, at 3:49 PM, Richard Bair richard.b...@oracle.com
wrote:
Doh, that's just what you said :-)
On Jul 23, 2013, at 3:49 PM, Richard Bair richard.b...@oracle.com
wrote:
I'm not seeing anything at all, beyond a fuzzy background image
(similar app to yours):
import javafx.application.**Application;
import javafx.scene.Scene;
import javafx.scene.web.WebView;
import javafx.stage.Stage;
public class HelloWebView extends Application {
@Override public void start(Stage stage) throws Exception {
WebView web = new WebView();
web.getEngine().load(http://**famo.us/ http://famo.us/);
Scene scene = new Scene(web);
stage.setScene(scene);
stage.setTitle(HelloWebView)**;
stage.show();
}
public static void main(String[] args) {
launch(args);
}
}
I'm on Mac. What OS are you running on?
Java 8 release plan
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: WebView capabilities review
Artem, I don't think you can blame the slowness of WebView and
famo.usentirely on the lack of JIT as the 64-bit Qt WebView is also
based on
WebKit and that site peforms extremely well with it.
On 25 July 2013 20:21, Felix Bembrick felix.bembr...@gmail.com wrote:
I have noticed something curious.
When I run the impact.js demo that Klaus posted a link to I see a very
smooth animation. The curious part is that on this same machine I see
noticeable flicker and jittering when I run even the most simple JavaFX
animation and have never seen one that performs as smoothly as the
impact.js demo within WebView. Also, the impact.js demo runs very smoothly
even when I run the WebView maximised.
OK, so now I know that it can't be the actual graphics hardware or driver
that cause JavaFX animations to flicker and clearly JavaFX *can* render
animated content without jittering so why then do simple animations (such
as those from Ensemble) perform so poorly?
On 25 July 2013 02:02, Artem Ananiev artem.anan...@oracle.com wrote:
On 7/24/2013 2:55 AM, Felix Bembrick wrote:
Windows 7 64-bit here.
On this platform, JavaFX web component is compiled without JIT support
for JavaScript:
https://javafx-jira.kenai.com/**browse/RT-24998https://javafx-jira.kenai.com/browse/RT-24998
It explains why it is slow, but it doesn't explain rendering artifacts.
Thanks,
Artem
On 24 July 2013 08:53, Richard Bair richard.b...@oracle.com wrote:
I've filed
https://javafx-jira.kenai.com/**browse/RT-31885https://javafx-jira.kenai.com/browse/RT-31885,
lets see how
that turns out.
Richard
On Jul 23, 2013, at 3:49 PM, Richard Bair richard.b...@oracle.com
wrote:
Doh, that's just what you said :-)
On Jul 23, 2013, at 3:49 PM, Richard Bair richard.b...@oracle.com
wrote:
I'm not seeing anything at all, beyond a fuzzy background image
(similar app to yours):
import javafx.application.**Application;
import javafx.scene.Scene;
import javafx.scene.web.WebView;
import javafx.stage.Stage;
public class HelloWebView extends Application {
@Override public void start(Stage stage) throws Exception {
WebView web = new WebView();
web.getEngine().load(http://**famo.us/ http://famo.us/);
Scene scene = new Scene(web);
stage.setScene(scene);
stage.setTitle(HelloWebView)**;
stage.show();
}
public static void main(String[] args) {
launch(args);
}
}
I'm on Mac. What OS are you running on?
Re: Can JavaFX do CAD?
On 25.07.13 13:44, Pavel Safrata wrote: Hi Richard, I have a comment to one of your questions: On 24.7.2013 21:06, Richard Bair wrote: - Would we benefit from a full lazy model for properties where we only instantiate them if somebody adds a listener We've done that in javafx.scene.transform.Affine. This is a class representing a general Affine transformation matrix, so it has twelve double properties. I'm probably not able to find the actual numbers we measured back then, but here is what I can remember. We used the 3D music chart JavaOne demo which operated with the matrices incredibly heavily. In this case the properties made a big difference in performance; with all the properties instantiated, even DoubleProperty.get() shone brightly in profiler results. So we introduced the full lazy properties which helped. Then we looked into it a bit more but were not able to create similar condition with any other use-case; the property getter is just a null check and a couple of calls in addition. It seemed that the transform matrices were a special case where some 3D algorithms call the matrix element getters too much, so we've left it at that. Regarding memory requirements of the full lazy properties, let me state the obvious: - if the property is not used at all, we have a reference and a double instead of just a reference (worse unless in bucket) - if getters/setters are called, we still have a reference and a double instead of full instantiated property (better) - if a listener is added, we have instantiated property and a double instead of just the property (slightly worse) So it looks like it would make best sense to introduce this for properties that are often get/set but usually don't have listeners on them. I'm not sure if such set exists and can be identified. If there are really a lot of properties of the same (primitive) type would it make sense to store their primitive values inside arrays instead of single fields? Not sure how arrays preform memory and access. If there are many booleans they could be store inside an short/int/long. Tom
Re: Can JavaFX do CAD?
Hi Richard, I have a comment to one of your questions: On 24.7.2013 21:06, Richard Bair wrote: - Would we benefit from a full lazy model for properties where we only instantiate them if somebody adds a listener We've done that in javafx.scene.transform.Affine. This is a class representing a general Affine transformation matrix, so it has twelve double properties. I'm probably not able to find the actual numbers we measured back then, but here is what I can remember. We used the 3D music chart JavaOne demo which operated with the matrices incredibly heavily. In this case the properties made a big difference in performance; with all the properties instantiated, even DoubleProperty.get() shone brightly in profiler results. So we introduced the full lazy properties which helped. Then we looked into it a bit more but were not able to create similar condition with any other use-case; the property getter is just a null check and a couple of calls in addition. It seemed that the transform matrices were a special case where some 3D algorithms call the matrix element getters too much, so we've left it at that. Regarding memory requirements of the full lazy properties, let me state the obvious: - if the property is not used at all, we have a reference and a double instead of just a reference (worse unless in bucket) - if getters/setters are called, we still have a reference and a double instead of full instantiated property (better) - if a listener is added, we have instantiated property and a double instead of just the property (slightly worse) So it looks like it would make best sense to introduce this for properties that are often get/set but usually don't have listeners on them. I'm not sure if such set exists and can be identified. It's still a good idea to investigate, I just thought this was worth mentioning. Cheers, Pavel
Re: WebView capabilities review
On 7/25/2013 3:06 PM, Felix Bembrick wrote:
Artem, I don't think you can blame the slowness of WebView and famo.us
http://famo.us entirely on the lack of JIT as the 64-bit Qt WebView is
also based on WebKit and that site peforms extremely well with it.
Sure, there may be other reasons of slowness than the lack of JIT
compilation on 64-bit Windows.
Thanks,
Artem
On 25 July 2013 20:21, Felix Bembrick felix.bembr...@gmail.com
mailto:felix.bembr...@gmail.com wrote:
I have noticed something curious.
When I run the impact.js demo that Klaus posted a link to I see a
very smooth animation. The curious part is that on this same
machine I see noticeable flicker and jittering when I run even the
most simple JavaFX animation and have never seen one that performs
as smoothly as the impact.js demo within WebView. Also, the
impact.js demo runs very smoothly even when I run the WebView maximised.
OK, so now I know that it can't be the actual graphics hardware or
driver that cause JavaFX animations to flicker and clearly JavaFX
*can* render animated content without jittering so why then do
simple animations (such as those from Ensemble) perform so poorly?
On 25 July 2013 02:02, Artem Ananiev artem.anan...@oracle.com
mailto:artem.anan...@oracle.com wrote:
On 7/24/2013 2:55 AM, Felix Bembrick wrote:
Windows 7 64-bit here.
On this platform, JavaFX web component is compiled without JIT
support for JavaScript:
https://javafx-jira.kenai.com/__browse/RT-24998
https://javafx-jira.kenai.com/browse/RT-24998
It explains why it is slow, but it doesn't explain rendering
artifacts.
Thanks,
Artem
On 24 July 2013 08:53, Richard Bair richard.b...@oracle.com
mailto:richard.b...@oracle.com wrote:
I've filed
https://javafx-jira.kenai.com/__browse/RT-31885
https://javafx-jira.kenai.com/browse/RT-31885, lets
see how
that turns out.
Richard
On Jul 23, 2013, at 3:49 PM, Richard Bair
richard.b...@oracle.com
mailto:richard.b...@oracle.com wrote:
Doh, that's just what you said :-)
On Jul 23, 2013, at 3:49 PM, Richard Bair
richard.b...@oracle.com
mailto:richard.b...@oracle.com
wrote:
I'm not seeing anything at all, beyond a fuzzy
background image
(similar app to yours):
import javafx.application.__Application;
import javafx.scene.Scene;
import javafx.scene.web.WebView;
import javafx.stage.Stage;
public class HelloWebView extends Application {
@Override public void start(Stage stage)
throws Exception {
WebView web = new WebView();
web.getEngine().load(http://__famo.us/
http://famo.us/);
Scene scene = new Scene(web);
stage.setScene(scene);
stage.setTitle(HelloWebView)__;
stage.show();
}
public static void main(String[] args) {
launch(args);
}
}
I'm on Mac. What OS are you running on?
Re: Nodes partial Mouse transparency
Hello Hervé, no, it's not possible to have a visible parent which is mouse transparent but its children are not. It is not really a common request. What about this: - Have the container invisible and not pickable. In the specific case of Pane it is enough to set pickOnBounds to false and fill to null, you don't have to use the collapsed size. Or just use Group which behaves like that by default. - Represent the visuals you want to have there by a child node (such as Rectangle or another Pane) which is visible, and has mouseTransparent set to true. This is reasonably clean but creates some extra nodes so its usefulness depends on the number of such instances in your app. Would it be usable in your case? Pavel On 25.7.2013 0:34, Herve Girod wrote: Hello, We have a Use Case when we want to have one container Node (for example basically a Pane, but it can be others containers) transparent to Mouse events, but not its children. We use it mainly to group children and control their positions, but we want to receive events on the children but not the parent Node. When using a Pane for example, there is a way to do it, by setting the pickOnBounds property to false, and one of the dimensions of the Pane to 0. That way the Pane is transparent to Mouse events, but not its children. However this is not straightforward, and it is not possible to do it while still having a non transparent Pane. Is there another (better) way to do this in JavaFX 8? Or did we miss something which allowed to do this in a more straightforward way even in JavaFX 2.2? If this is definitely the only way do do this (which work), wouldit be possible to add this kind of partial Mouse transparency in 8? Regards, Hervé
hg: openjfx/8/graphics/rt: RT-31449: Mac: Drag and drop works differently on MacOS
Changeset: 88aa49b29342 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-07-25 16:30 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/88aa49b29342 RT-31449: Mac: Drag and drop works differently on MacOS Reviewed-by: anthony, art ! modules/graphics/src/main/native-glass/mac/GlassDragSource.h ! modules/graphics/src/main/native-glass/mac/GlassDragSource.m ! modules/graphics/src/main/native-glass/mac/GlassPasteboard.m ! modules/graphics/src/main/native-glass/mac/GlassViewDelegate.m
Re: Can JavaFX do CAD?
If there are really a lot of properties of the same (primitive) type would it make sense to store their primitive values inside arrays instead of single fields? Not sure how arrays preform memory and access. If there are many booleans they could be store inside an short/int/long. My understanding is that JavaC does that for you to the extent that it can safely determine (compact booleans in to a single integer, etc). But I don't know for certain, it would be a worth experiment to just try it out. I would recommend trying to use jmh (http://impactjs.com/demos/physics/) to write a few micro benchmarks just to see what the differences are. Richard
Re: WebView capabilities review
I don't see his link to impact.js, can you send it again?
Usually the stutters that we see are the result of threading problems between
Glass Prism rather than a performance (fps) problem. You probably saw the
issue come by yesterday that smoothed this out on the mac. In order to get rid
of these, what we need to do is have a way to measure when they happen, and
have a reproducible example. I've seen them forever on the mac (but now that
*should* be fixed), but on windows I've never seen them (windows was always
exceptionally smooth for me), and that has been the primary challenge in
nailing it down.
It may be related to drift -- 1/60th of a second is 16.66… ms long, and the
timer used to get pulses may be running at 16ms for example, in which case
there is drift where eventually it takes 2 frames worth of time to draw a
single frame because we're waiting on the card.
I'm not sure how WebView's interaction with prism would be avoiding this, but
that's what it sounds like.
We also recently changed the way the FX thread and render thread interact so as
not to drop frames. I would expect that to have an impact in smoothing things
out as well.
Are you building locally or are you using one of the promoted builds? Do you
see the hiccups right now in Ensemble?
Richard
On Jul 25, 2013, at 3:21 AM, Felix Bembrick felix.bembr...@gmail.com wrote:
I have noticed something curious.
When I run the impact.js demo that Klaus posted a link to I see a very smooth
animation. The curious part is that on this same machine I see noticeable
flicker and jittering when I run even the most simple JavaFX animation and
have never seen one that performs as smoothly as the impact.js demo within
WebView. Also, the impact.js demo runs very smoothly even when I run the
WebView maximised.
OK, so now I know that it can't be the actual graphics hardware or driver
that cause JavaFX animations to flicker and clearly JavaFX *can* render
animated content without jittering so why then do simple animations (such as
those from Ensemble) perform so poorly?
On 25 July 2013 02:02, Artem Ananiev artem.anan...@oracle.com wrote:
On 7/24/2013 2:55 AM, Felix Bembrick wrote:
Windows 7 64-bit here.
On this platform, JavaFX web component is compiled without JIT support for
JavaScript:
https://javafx-jira.kenai.com/browse/RT-24998
It explains why it is slow, but it doesn't explain rendering artifacts.
Thanks,
Artem
On 24 July 2013 08:53, Richard Bair richard.b...@oracle.com wrote:
I've filed https://javafx-jira.kenai.com/browse/RT-31885, lets see how
that turns out.
Richard
On Jul 23, 2013, at 3:49 PM, Richard Bair richard.b...@oracle.com wrote:
Doh, that's just what you said :-)
On Jul 23, 2013, at 3:49 PM, Richard Bair richard.b...@oracle.com
wrote:
I'm not seeing anything at all, beyond a fuzzy background image
(similar app to yours):
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.web.WebView;
import javafx.stage.Stage;
public class HelloWebView extends Application {
@Override public void start(Stage stage) throws Exception {
WebView web = new WebView();
web.getEngine().load(http://famo.us/;);
Scene scene = new Scene(web);
stage.setScene(scene);
stage.setTitle(HelloWebView);
stage.show();
}
public static void main(String[] args) {
launch(args);
}
}
I'm on Mac. What OS are you running on?
Re: Can JavaFX do CAD?
Regarding memory requirements of the full lazy properties, let me state the
obvious:
- if the property is not used at all, we have a reference and a double
instead of just a reference (worse unless in bucket)
- if getters/setters are called, we still have a reference and a double
instead of full instantiated property (better)
- if a listener is added, we have instantiated property and a double instead
of just the property (slightly worse)
So it looks like it would make best sense to introduce this for properties
that are often get/set but usually don't have listeners on them. I'm not sure
if such set exists and can be identified.
Thanks Pavel, this is a good summary. Alex K. and I were looking at a pattern
for this once and he had another way to do it which was different than what I
had done in the past. The pattern I used to use was something like this:
private double _x;
private DoubleProperty x;
public final void setX(double value) {
if (x == null) {
_x = value;
} else {
x.set(value);
}
public final double getX() {
return x == null ? _x : x.get();
}
public final DoubleProperty xProperty() {
if (x == null) x = new DoubleProperty(this, x, _x);
return x;
}
instead it could be done like this which results in faster getters (because you
never have to delegate to another method), an almost immeasurably slower
setter, and slightly little less code:
private double _x;
private DoubleProperty x;
public final void setX(double value) {
_x = value;
if (x != null) x.set(value);
}
public final double getX() {
return x;
}
public final DoubleProperty xProperty() {
if (x == null) x = new DoubleProperty(this, x, _x);
return x;
}
The idea here is to always set the local field, so that we can always just
return the value immediately in the getter. Where I think this may make a
difference is on the smaller end systems (mobile / embedded) because from
previous analysis we saw that none of our getters were getting inlined -- we
actually paid the price of each method call overhead, because since we were
reading from the property objects and the property objects were a couple
methods worth of work for each getter call, the VM wouldn't inline the
generated code into the call sites. By using this pattern in places that are
commonly read, we would probably get these getters all inlined again and avoid
all the method call overhead entirely.
Richard
Re: WebView capabilities review
I just ran Ensemble on mac with the latest, with pulse logger turned on. Ran
the SequentialTransition demo and I agree it didn't look smooth, even though
the pulse logger reports that of over 3,000 pulses, not a single one crossed
the 16ms threshold. Is the grid background causing an optical illusion? (as the
shape passes a boundary it may temporarily looked wider and then shorter making
it look like it is changing size / speed??)
Richard
On Jul 25, 2013, at 9:28 AM, Richard Bair richard.b...@oracle.com wrote:
I don't see his link to impact.js, can you send it again?
Usually the stutters that we see are the result of threading problems between
Glass Prism rather than a performance (fps) problem. You probably saw the
issue come by yesterday that smoothed this out on the mac. In order to get
rid of these, what we need to do is have a way to measure when they happen,
and have a reproducible example. I've seen them forever on the mac (but now
that *should* be fixed), but on windows I've never seen them (windows was
always exceptionally smooth for me), and that has been the primary challenge
in nailing it down.
It may be related to drift -- 1/60th of a second is 16.66… ms long, and
the timer used to get pulses may be running at 16ms for example, in which
case there is drift where eventually it takes 2 frames worth of time to draw
a single frame because we're waiting on the card.
I'm not sure how WebView's interaction with prism would be avoiding this, but
that's what it sounds like.
We also recently changed the way the FX thread and render thread interact so
as not to drop frames. I would expect that to have an impact in smoothing
things out as well.
Are you building locally or are you using one of the promoted builds? Do you
see the hiccups right now in Ensemble?
Richard
On Jul 25, 2013, at 3:21 AM, Felix Bembrick felix.bembr...@gmail.com wrote:
I have noticed something curious.
When I run the impact.js demo that Klaus posted a link to I see a very
smooth animation. The curious part is that on this same machine I see
noticeable flicker and jittering when I run even the most simple JavaFX
animation and have never seen one that performs as smoothly as the impact.js
demo within WebView. Also, the impact.js demo runs very smoothly even when
I run the WebView maximised.
OK, so now I know that it can't be the actual graphics hardware or driver
that cause JavaFX animations to flicker and clearly JavaFX *can* render
animated content without jittering so why then do simple animations (such as
those from Ensemble) perform so poorly?
On 25 July 2013 02:02, Artem Ananiev artem.anan...@oracle.com wrote:
On 7/24/2013 2:55 AM, Felix Bembrick wrote:
Windows 7 64-bit here.
On this platform, JavaFX web component is compiled without JIT support for
JavaScript:
https://javafx-jira.kenai.com/browse/RT-24998
It explains why it is slow, but it doesn't explain rendering artifacts.
Thanks,
Artem
On 24 July 2013 08:53, Richard Bair richard.b...@oracle.com wrote:
I've filed https://javafx-jira.kenai.com/browse/RT-31885, lets see how
that turns out.
Richard
On Jul 23, 2013, at 3:49 PM, Richard Bair richard.b...@oracle.com wrote:
Doh, that's just what you said :-)
On Jul 23, 2013, at 3:49 PM, Richard Bair richard.b...@oracle.com
wrote:
I'm not seeing anything at all, beyond a fuzzy background image
(similar app to yours):
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.web.WebView;
import javafx.stage.Stage;
public class HelloWebView extends Application {
@Override public void start(Stage stage) throws Exception {
WebView web = new WebView();
web.getEngine().load(http://famo.us/;);
Scene scene = new Scene(web);
stage.setScene(scene);
stage.setTitle(HelloWebView);
stage.show();
}
public static void main(String[] args) {
launch(args);
}
}
I'm on Mac. What OS are you running on?
Re: WebView capabilities review
Try this:
public class HelloAnimatedRectangle extends Application {
@Override public void start(Stage stage) throws Exception {
final double sceneWidth = 1024;
final double sceneHeight = 768;
final double squareSize = 200;
final double halfStroke = 0;
Rectangle rect = new Rectangle(squareSize, squareSize, Color.ORANGE);
rect.setStroke(Color.WHITE);
rect.setStrokeWidth(halfStroke * 2);
Group root = new Group(rect);
Scene scene = new Scene(root, sceneWidth, sceneHeight);
scene.setFill(Color.BLACK);
stage.setScene(scene);
stage.setTitle(Animated Rectangle);
stage.show();
TranslateTransition translation = new
TranslateTransition(Duration.seconds(20), rect);
translation.setFromX(halfStroke);
translation.setFromY(halfStroke);
translation.setToX((sceneWidth - squareSize) / 2);
translation.setToY((sceneHeight - squareSize) / 2);
RotateTransition rotation = new RotateTransition(Duration.seconds(10),
rect);
rotation.setAutoReverse(true);
rotation.setCycleCount(2);
rotation.setToAngle(720);
TranslateTransition translation2 = new
TranslateTransition(Duration.seconds(20), rect);
translation2.setFromX((sceneWidth - squareSize) / 2);
translation2.setFromY((sceneHeight - squareSize) / 2);
translation2.setToX(sceneWidth - squareSize - halfStroke);
translation2.setToY(sceneHeight - squareSize - halfStroke);
SequentialTransition tx = new SequentialTransition(translation,
rotation, translation2);
tx.play();
}
public static void main(String[] args) {
launch(args);
}
}
You can mess with the halfStroke variable to stroke it white to get greater
contrast between the background and the shape. The translations looks smooth to
me, I don't see any dropped frames. The rotation looks alternately smooth and
chunky depending on the position of the rotation. I believe this is due to
anti-aliasing and pixel refresh speeds (as opposed to an actual performance
problem or timing problem).
What do you see?
Richard
On Jul 25, 2013, at 9:49 AM, Richard Bair richard.b...@oracle.com wrote:
I just ran Ensemble on mac with the latest, with pulse logger turned on. Ran
the SequentialTransition demo and I agree it didn't look smooth, even though
the pulse logger reports that of over 3,000 pulses, not a single one crossed
the 16ms threshold. Is the grid background causing an optical illusion? (as
the shape passes a boundary it may temporarily looked wider and then shorter
making it look like it is changing size / speed??)
Richard
On Jul 25, 2013, at 9:28 AM, Richard Bair richard.b...@oracle.com wrote:
I don't see his link to impact.js, can you send it again?
Usually the stutters that we see are the result of threading problems
between Glass Prism rather than a performance (fps) problem. You probably
saw the issue come by yesterday that smoothed this out on the mac. In order
to get rid of these, what we need to do is have a way to measure when they
happen, and have a reproducible example. I've seen them forever on the mac
(but now that *should* be fixed), but on windows I've never seen them
(windows was always exceptionally smooth for me), and that has been the
primary challenge in nailing it down.
It may be related to drift -- 1/60th of a second is 16.66… ms long, and
the timer used to get pulses may be running at 16ms for example, in which
case there is drift where eventually it takes 2 frames worth of time to draw
a single frame because we're waiting on the card.
I'm not sure how WebView's interaction with prism would be avoiding this,
but that's what it sounds like.
We also recently changed the way the FX thread and render thread interact so
as not to drop frames. I would expect that to have an impact in smoothing
things out as well.
Are you building locally or are you using one of the promoted builds? Do you
see the hiccups right now in Ensemble?
Richard
On Jul 25, 2013, at 3:21 AM, Felix Bembrick felix.bembr...@gmail.com wrote:
I have noticed something curious.
When I run the impact.js demo that Klaus posted a link to I see a very
smooth animation. The curious part is that on this same machine I see
noticeable flicker and jittering when I run even the most simple JavaFX
animation and have never seen one that performs as smoothly as the
impact.js demo within WebView. Also, the impact.js demo runs very smoothly
even when I run the WebView maximised.
OK, so now I know that it can't be the actual graphics hardware or driver
that cause JavaFX animations to flicker and clearly JavaFX *can* render
animated content without jittering so why then do simple animations (such
as those from Ensemble) perform so poorly?
On 25 July 2013 02:02, Artem Ananiev artem.anan...@oracle.com
Result: New OpenJFX Committer: Danno Ferrin
Voting for Danno Ferrin to OpenJFX Committer [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Richard [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008695.html
Result: New OpenJFX Committer: Oleg Mazurov
Voting for Oleg Mazurov to OpenJFX Committer [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Artem [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008699.html
Result: New OpenJFX Committer: Alexander Kouznetsov
Voting for Alexander Kouznetsov to OpenJFX Committer [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Artem [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008698.html
Result: New OpenJFX Committer: Debbie Masada
Voting for Debbie Masada to OpenJFX Committer [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Artem [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008696.html
Re: Mixing 2D and 3D
Hi August, I think we already do multiple active cameras? More precisely: simultaneous viewing from different points of view into a single 3D scene graph was meant, i.e. several cameras are attached to one scene graph. A SubScene has exactly one camera attached which renders the associated scene graph into the corresponding SubScene's rectangle. Implementing simultaneous viewing requires a cloned 3D scene graph for the second, third, and so on SubScene/Camera. Material, Mesh, and Image objects can be re-used because they are shareable. Animations of Nodes' Transforms seem to be shareable as well. But Transitions (Rotate, Scale, Translate) have to be cloned because they operate on a Node's methods directly. So, simultaneous viewing seems practicable. Jasper or Kevin will have to comment, but I know this scenario was talked about extensively in the design for the renderToImage and cameras, and I thought this was possible today. Key/ mouse / touch / etc should be there already? Scene navigation and model interaction are often the first stumbling blocks for developers with less 3D experience. A ready to go rotate, zoom, and drag support including setting of arbitrary pivot points and adjustment of the camera's clipping planes would overcome one's inhibitions. I see Node's properties and methods Before I agree with all of your appraisals I would like to gain more experiences with their 3D related implementations. For instance I wasn't successful so far assigning a cursor to a Shape3D or receiving response from any 'setOnMouseXXX' method. Yes, please do try it out, it should be working and if not please do file a bug. We use a pick-ray for determining which nodes to pick, and then deliver mouse events to 3D and 2D nodes the same way. Thanks! Richard
Code style guide lines
Hi, I'm once more doing a clean up pass to get out of the way warnings in the control codebase - RT-31907. Do you guys follow any coding guide lines? Wouldn't it be good if the JavaFX codebase would follow http://openjdk.java.net/guide/codeConventions.html Tom
Re: Antialiasing in 3D
John, did you feel this got answered by Chien's last comments? Richard On Jul 20, 2013, at 1:05 PM, John C. Turnbull ozem...@ozemail.com.au wrote: There has been recent discussion here regarding the 3D antialiasing options in JavaFX 8. For mine, there needs to be a way to specify both the *type* of AA (MSAA, FSAA etc.) and also the *magnitude* (2x, 4x etc.). There also needs to be a way for the application to determine the range of settings available on the GPU so that it can select the particular options it wants (perhaps via user input). Given this, I have some additional comments. First, there seems to be 2 main approaches to applying AA to 3D scenes. The first is what I am personally accustomed to in work I have done with OpenGL. With this approach you pretty much write directly to the primary buffer and thus allow the AA settings to be overridden by the driver configuration. For example, on my Windows 7 machine which sports a high-end NVIDIA GPU, I can go into the NVIDIA Control Panel and then fiddle with all manner of AA and other 3D settings. I can choose anything from 2x to 32x with various combinations of MS, SS and CS. The results of this tinkering are immediately obvious and range from high-performance chunky graphics to super-smooth graphics with very low frame rates. The point is that I the user have full control over how the graphics are rendered and I get to choose between performance and quality or a bit of both. The other approach is where the scene or sub-scene is rendered into an off-screen buffer. When the buffer is created, the AA settings (such as the number of samples) are specified and this/these buffer(s) can then be blasted onto the screen later. Here it is the developer who has full control over the AA settings as with this approach the end user is unable to override these settings in their GPU driver's control panel. Which of these approaches will be taken with JavaFX 8 3D? I am guessing it's the second approach or a combination of both approaches. I am especially curious because I have noticed some unusual things about 3D on some platforms. For example, on my iPhone I can play 3D games and they seem to perform very well. What's really interesting to me is that the quality of the 3D graphics is absolutely outstanding with barely a jaggie to be seen. I think someone mentioned in the previous thread on JavaFX 3D and AA that only levels of 2X MSAA were possible on most phones but if this is the case then how do they get the graphics to be rendered with such high quality? I doubt it's all about the retina display as I have seen equally smooth graphics on some Android phones which do not have such high resolution screens. Similarly, I find that the 3D graphics rendered via WebGL (on all platforms) are also of a very high quality with seemingly no negative impact on performance. In fact, on my Windows 7 machine I am unable to achieve the same level of quality in my own OpenGL applications even when the highest quality settings are configured in the NVIDIA Control Panel as is achieved in many WebGL games on the same machine. With both the iPhone and WebGL I find that tuning the settings in the Control Panel has absolutely no effect on the quality of the rendered graphics so I am very curious to know just how they can achieve the high quality rendering and also if JavaFX can somehow tap into these techniques as well. Could someone from the JavaFX 3D team please comment on these observations? Thanks, -jct
hg: openjfx/8/graphics/rt: fix for RT-31660
Changeset: 1362976b7edb Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-07-25 10:29 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1362976b7edb fix for RT-31660 ! modules/graphics/src/main/native-font/directwrite.cpp
Re: Run JavaFX application on IBM JVM
Hi Peter, Hi, I would like to ask you is it possible to run JavaFX application on IBM J9 JVM or other JVM? I suppose that I will need to copy some libraries from Oracle JVM. Can you give me some more information? I would imagine it might work. We use sun.misc.Unsafe and maybe a couple other APIs which I don't know if IBM's J9 also implement (probably). We've only ever tested with HotSpot so I can't say for certain. Richard
Re: Code style guide lines
I started a guide on our wiki a while ago: https://wiki.openjdk.java.net/display/OpenJFX/Policies+and+Processes But I only started it I never actually finished it or even asked anybody else what they thought of it :-). In general we follow the standard sun guidelines. We use spaces, not tabs. 4 spaces per indent, 8 for line continuation (usually). Comments should be the standard /* */ or //. We did go non-standard in our use of @Override by putting it on the same line as the method, although it is not consistent. I always do my for loops like: for (int i=0; i10; i++) (Notice the lack of spaces around = and ). This drives Kevin nuts who likes to have spaces around the = and . Probably the best way to go is, as you find things that are suspicious or look wrong, lets bring it up and add it to the wiki and grow the wiki to have all the standards (rather than build up a list ahead of time). The Java code conventions should be seen as the rule book, unless we've explicitly modified it and documented it. Richard On Jul 25, 2013, at 10:39 AM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I'm once more doing a clean up pass to get out of the way warnings in the control codebase - RT-31907. Do you guys follow any coding guide lines? Wouldn't it be good if the JavaFX codebase would follow http://openjdk.java.net/guide/codeConventions.html Tom
Re: Mixing 2D and 3D
err... two identical groups of nodes** On 7/25/2013 11:04 AM, Joseph Andresen wrote: On 7/25/2013 10:37 AM, Richard Bair wrote: Hi August, I think we already do multiple active cameras? More precisely: simultaneous viewing from different points of view into a single 3D scene graph was meant, i.e. several cameras are attached to one scene graph. A SubScene has exactly one camera attached which renders the associated scene graph into the corresponding SubScene's rectangle. Implementing simultaneous viewing requires a cloned 3D scene graph for the second, third, and so on SubScene/Camera. Material, Mesh, and Image objects can be re-used because they are shareable. Animations of Nodes' Transforms seem to be shareable as well. But Transitions (Rotate, Scale, Translate) have to be cloned because they operate on a Node's methods directly. So, simultaneous viewing seems practicable. Jasper or Kevin will have to comment, but I know this scenario was talked about extensively in the design for the renderToImage and cameras, and I thought this was possible today. I know that one way to do this is by rendering the same group of nodes twice, using two different cameras each time, and using render to image or whatever to get your RTT. I haven't tried it but i suspect it goes something like calling render to image on a group with one camera and then render to image on the same group with a different camera.
Re: Code style guide lines
Hi, Well what I'm interested more is things like: * Should a switch always have a default-case? - According to the Java guidelines this should be! * Why are so many things not generified but use the raw types? - It looks like you are all running with raw-type warnings off, which has the effect that you don't even spot APIs who are not generified (and can't even be fixed because it would be an API breakage). * What should be done with fields declared but never used? I think you should also write down the policy when a Simple*Property used? - we discussed that same months ago already Tom On 25.07.13 20:10, Richard Bair wrote: I started a guide on our wiki a while ago: https://wiki.openjdk.java.net/display/OpenJFX/Policies+and+Processes But I only started it I never actually finished it or even asked anybody else what they thought of it :-). In general we follow the standard sun guidelines. We use spaces, not tabs. 4 spaces per indent, 8 for line continuation (usually). Comments should be the standard /* */ or //. We did go non-standard in our use of @Override by putting it on the same line as the method, although it is not consistent. I always do my for loops like: for (int i=0; i10; i++) (Notice the lack of spaces around = and ). This drives Kevin nuts who likes to have spaces around the = and . Probably the best way to go is, as you find things that are suspicious or look wrong, lets bring it up and add it to the wiki and grow the wiki to have all the standards (rather than build up a list ahead of time). The Java code conventions should be seen as the rule book, unless we've explicitly modified it and documented it. Richard On Jul 25, 2013, at 10:39 AM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I'm once more doing a clean up pass to get out of the way warnings in the control codebase - RT-31907. Do you guys follow any coding guide lines? Wouldn't it be good if the JavaFX codebase would follow http://openjdk.java.net/guide/codeConventions.html Tom
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
Hello, Richard. Where did you instrument to measure which frames were actually rendered? Actually, I've made a bit of hacking to get this and my solution is not cross-platform. On Mac each time the [CALayer drawInGLContext] is called we are rendering a frame to the screen. And this is reliable - if we've exited this method the frame must be on the screen. So I've added a counter into this method which calculates the average number of method calls per second and logs it. In production this counter was removed. Of course external tools could be used, like OpenGL profiler, but I suppose that's not what you want. Also, on Mac we have a flag in native which represents if the frame was delivered or not. So, using that flag, it is quite easy to add a logger which would warn you that a frame was dropped. Nothing could be done in Java for this, because we have a complex processing in native code and frame drops happen there. I have no idea how it could be done on other platforms, because I am familiar with this area only on the Mac. With best regards. Petr. On Jul 25, 2013, at 9:24 PM, Richard Bair richard.b...@oracle.com wrote: Hi Petr, We are in a separate thread discussing jitter where being able to measure dropped frames is crucial. We have the PulseLogger class which keeps track of this kind of information (at least, it measures the amount of time spent in a particular pulse). There is a message that sometimes displays about dropping a frame, but I don't know if it captures the same cases as what you have captured here. Where did you instrument to measure which frames were actually rendered? I need a reliable mechanism for measuring jitter. We're not running full speed, so if I'm handling frames at less than 16ms per frame, then I should never see any jitter, unless we have a loss of synchronization between our pulse timer and the display. How can I measure this reliably? Right now we have to just stare at our monitors and see if something looks suspicious. I'd rather have a fool-proof method of determining whether we're hitting each frame right on target. Any ideas? Richard On Jul 24, 2013, at 11:31 AM, Petr Pchelko petr.pche...@oracle.com wrote: Hello, Richard. These changes fix the problem with dropping frames on Mac because of locking between the render thread and UI thread. I have made some measurements with Controls benchmark and GUIMark2. The numbers without braces is the FPS rendered by Prism and the braced numbers represent how many frames we are actually rendering on the screen. Test Fix No Fix bitmap-1000 76.1 (76.0) 75.3 (44.1) bitmap-3000 38.3 (38.1) 36.9 (31.2) bitmap-5000 23.4 (23.2) 22.6 (18.4) vector 31.6 (31.3) 31.8 (29.0) CheckBox 79(79)67(47) As you could see, with the fix we almost never drop frames, all of them are actually delivered to the screen. Prism performance is improved in some cases too. These are not all the results, just examples to feel the difference. With best regards. Petr. On Jul 24, 2013, at 8:23 PM, Richard Bair richard.b...@oracle.com wrote: The name of the issue is pretty ho-hum, but actually this was a huge amount of work to get finished. Petr, Artem, or Steve, can you give us a run-down of the performance impact of this change on Mac? Thanks Richard On Jul 24, 2013, at 12:32 AM, hang...@oracle.com wrote: Changeset: dd30604ab7d0 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-07-24 11:24 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd30604ab7d0 RT-26702 Poor DisplacementMap effect performance on Mac Reviewed-by: anthony, art, snorthov ! modules/graphics/src/main/native-glass/mac/GlassEmbeddedWindow+Overrides.m ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.h ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.m ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.h ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.h ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m
Re: Code style guide lines
* Should a switch always have a default-case? - According to the Java guidelines this should be! I would say definitely yes. The default clause should throw an AssertionError if it really is unexpected. This will catch cases where we add an enum type and don't add the right clause to a switch statement. * Why are so many things not generified but use the raw types? - It looks like you are all running with raw-type warnings off, which has the effect that you don't even spot APIs who are not generified (and can't even be fixed because it would be an API breakage). Could be! * What should be done with fields declared but never used? We ought to remove anything not being used. The only trick is making sure it isn't be used evilly through reflection (most of the time this is not the case). I think you should also write down the policy when a Simple*Property used? - we discussed that same months ago already I'd be happy to put it in the wiki if you give me some words. I'm overloaded and drowning :) Richard
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
Can you point me at the code? I'm in graphics, and I've done a search in the whole of rt and I don't see CALayer drawInGLContext anywhere in the code. (I did both an IDEA case insensitive recursive search and also a grep -r on the command line) Thanks Richard On Jul 25, 2013, at 11:26 AM, Petr Pchelko petr.pche...@oracle.com wrote: Hello, Richard. Where did you instrument to measure which frames were actually rendered? Actually, I've made a bit of hacking to get this and my solution is not cross-platform. On Mac each time the [CALayer drawInGLContext] is called we are rendering a frame to the screen. And this is reliable - if we've exited this method the frame must be on the screen. So I've added a counter into this method which calculates the average number of method calls per second and logs it. In production this counter was removed. Of course external tools could be used, like OpenGL profiler, but I suppose that's not what you want. Also, on Mac we have a flag in native which represents if the frame was delivered or not. So, using that flag, it is quite easy to add a logger which would warn you that a frame was dropped. Nothing could be done in Java for this, because we have a complex processing in native code and frame drops happen there. I have no idea how it could be done on other platforms, because I am familiar with this area only on the Mac. With best regards. Petr. On Jul 25, 2013, at 9:24 PM, Richard Bair richard.b...@oracle.com wrote: Hi Petr, We are in a separate thread discussing jitter where being able to measure dropped frames is crucial. We have the PulseLogger class which keeps track of this kind of information (at least, it measures the amount of time spent in a particular pulse). There is a message that sometimes displays about dropping a frame, but I don't know if it captures the same cases as what you have captured here. Where did you instrument to measure which frames were actually rendered? I need a reliable mechanism for measuring jitter. We're not running full speed, so if I'm handling frames at less than 16ms per frame, then I should never see any jitter, unless we have a loss of synchronization between our pulse timer and the display. How can I measure this reliably? Right now we have to just stare at our monitors and see if something looks suspicious. I'd rather have a fool-proof method of determining whether we're hitting each frame right on target. Any ideas? Richard On Jul 24, 2013, at 11:31 AM, Petr Pchelko petr.pche...@oracle.com wrote: Hello, Richard. These changes fix the problem with dropping frames on Mac because of locking between the render thread and UI thread. I have made some measurements with Controls benchmark and GUIMark2. The numbers without braces is the FPS rendered by Prism and the braced numbers represent how many frames we are actually rendering on the screen. Test Fix No Fix bitmap-1000 76.1 (76.0) 75.3 (44.1) bitmap-3000 38.3 (38.1) 36.9 (31.2) bitmap-5000 23.4 (23.2) 22.6 (18.4) vector 31.6 (31.3) 31.8 (29.0) CheckBox 79(79)67(47) As you could see, with the fix we almost never drop frames, all of them are actually delivered to the screen. Prism performance is improved in some cases too. These are not all the results, just examples to feel the difference. With best regards. Petr. On Jul 24, 2013, at 8:23 PM, Richard Bair richard.b...@oracle.com wrote: The name of the issue is pretty ho-hum, but actually this was a huge amount of work to get finished. Petr, Artem, or Steve, can you give us a run-down of the performance impact of this change on Mac? Thanks Richard On Jul 24, 2013, at 12:32 AM, hang...@oracle.com wrote: Changeset: dd30604ab7d0 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-07-24 11:24 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd30604ab7d0 RT-26702 Poor DisplacementMap effect performance on Mac Reviewed-by: anthony, art, snorthov ! modules/graphics/src/main/native-glass/mac/GlassEmbeddedWindow+Overrides.m ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.h ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.m ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.h ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.h ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m
hg: openjfx/8/graphics/rt: Added manual region tests
Changeset: 6a87954a02d3 Author:rbair Date: 2013-07-25 11:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6a87954a02d3 Added manual region tests + .idea/RegionTests.iml ! .idea/modules.xml + tests/manual/RegionTests/src/main/java/region/RegionBackgroundFillUITest.java + tests/manual/RegionTests/src/main/java/region/RegionBackgroundImageUITest.java + tests/manual/RegionTests/src/main/java/region/RegionBorderImageUITest.java + tests/manual/RegionTests/src/main/java/region/RegionBorderStrokeUITest.java + tests/manual/RegionTests/src/main/java/region/RegionShapeUITest.java + tests/manual/RegionTests/src/main/java/region/RegionUITestBase.java + tests/manual/RegionTests/src/main/resources/region/BlackButton.png + tests/manual/RegionTests/src/main/resources/region/WindowsButton.png + tests/manual/RegionTests/src/main/resources/region/border.png + tests/manual/RegionTests/src/main/resources/region/bor...@2x.png + tests/manual/RegionTests/src/main/resources/region/checker.png + tests/manual/RegionTests/src/main/resources/region/popover-no-arrow-empty.png + tests/manual/RegionTests/src/main/resources/region/popover-no-arrow-em...@2x.png + tests/manual/RegionTests/src/main/resources/region/test20x20.png + tests/manual/RegionTests/src/main/resources/region/test20...@2x.png + tests/manual/RegionTests/src/main/resources/region/test48x48.png + tests/manual/RegionTests/src/main/resources/region/test48...@2x.png
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
Sorry, I have misspelled the method name. It's drawInCGLContext. It's in native Glass: GlassLayer3D.m line 153. With best regards. Petr. On Jul 25, 2013, at 11:02 PM, Richard Bair richard.b...@oracle.com wrote: Can you point me at the code? I'm in graphics, and I've done a search in the whole of rt and I don't see CALayer drawInGLContext anywhere in the code. (I did both an IDEA case insensitive recursive search and also a grep -r on the command line) Thanks Richard On Jul 25, 2013, at 11:26 AM, Petr Pchelko petr.pche...@oracle.com wrote: Hello, Richard. Where did you instrument to measure which frames were actually rendered? Actually, I've made a bit of hacking to get this and my solution is not cross-platform. On Mac each time the [CALayer drawInGLContext] is called we are rendering a frame to the screen. And this is reliable - if we've exited this method the frame must be on the screen. So I've added a counter into this method which calculates the average number of method calls per second and logs it. In production this counter was removed. Of course external tools could be used, like OpenGL profiler, but I suppose that's not what you want. Also, on Mac we have a flag in native which represents if the frame was delivered or not. So, using that flag, it is quite easy to add a logger which would warn you that a frame was dropped. Nothing could be done in Java for this, because we have a complex processing in native code and frame drops happen there. I have no idea how it could be done on other platforms, because I am familiar with this area only on the Mac. With best regards. Petr. On Jul 25, 2013, at 9:24 PM, Richard Bair richard.b...@oracle.com wrote: Hi Petr, We are in a separate thread discussing jitter where being able to measure dropped frames is crucial. We have the PulseLogger class which keeps track of this kind of information (at least, it measures the amount of time spent in a particular pulse). There is a message that sometimes displays about dropping a frame, but I don't know if it captures the same cases as what you have captured here. Where did you instrument to measure which frames were actually rendered? I need a reliable mechanism for measuring jitter. We're not running full speed, so if I'm handling frames at less than 16ms per frame, then I should never see any jitter, unless we have a loss of synchronization between our pulse timer and the display. How can I measure this reliably? Right now we have to just stare at our monitors and see if something looks suspicious. I'd rather have a fool-proof method of determining whether we're hitting each frame right on target. Any ideas? Richard On Jul 24, 2013, at 11:31 AM, Petr Pchelko petr.pche...@oracle.com wrote: Hello, Richard. These changes fix the problem with dropping frames on Mac because of locking between the render thread and UI thread. I have made some measurements with Controls benchmark and GUIMark2. The numbers without braces is the FPS rendered by Prism and the braced numbers represent how many frames we are actually rendering on the screen. Test Fix No Fix bitmap-1000 76.1 (76.0) 75.3 (44.1) bitmap-3000 38.3 (38.1) 36.9 (31.2) bitmap-5000 23.4 (23.2) 22.6 (18.4) vector 31.6 (31.3) 31.8 (29.0) CheckBox 79(79)67(47) As you could see, with the fix we almost never drop frames, all of them are actually delivered to the screen. Prism performance is improved in some cases too. These are not all the results, just examples to feel the difference. With best regards. Petr. On Jul 24, 2013, at 8:23 PM, Richard Bair richard.b...@oracle.com wrote: The name of the issue is pretty ho-hum, but actually this was a huge amount of work to get finished. Petr, Artem, or Steve, can you give us a run-down of the performance impact of this change on Mac? Thanks Richard On Jul 24, 2013, at 12:32 AM, hang...@oracle.com wrote: Changeset: dd30604ab7d0 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-07-24 11:24 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd30604ab7d0 RT-26702 Poor DisplacementMap effect performance on Mac Reviewed-by: anthony, art, snorthov ! modules/graphics/src/main/native-glass/mac/GlassEmbeddedWindow+Overrides.m ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.h ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.m ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.h ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.h ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m
hg: openjfx/8/graphics/rt: Ensemble8: DisplayShelf misses pagination bar
Changeset: 2cf8414df80b Author:dmasada Date: 2013-07-25 12:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2cf8414df80b Ensemble8: DisplayShelf misses pagination bar ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/displayshelf/DisplayShelf.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/displayshelf/DisplayShelfApp.java + apps/samples/Ensemble8/src/samples/resources/ensemble/samples/graphics/displayshelf/DisplayShelf.css
Re: Code style guide lines
On 25.07.13 20:59, Richard Bair wrote: * Should a switch always have a default-case? - According to the Java guidelines this should be! I would say definitely yes. The default clause should throw an AssertionError if it really is unexpected. This will catch cases where we add an enum type and don't add the right clause to a switch statement. ok * Why are so many things not generified but use the raw types? - It looks like you are all running with raw-type warnings off, which has the effect that you don't even spot APIs who are not generified (and can't even be fixed because it would be an API breakage). Could be! * What should be done with fields declared but never used? We ought to remove anything not being used. The only trick is making sure it isn't be used evilly through reflection (most of the time this is not the case). Understood but if that is the case it should be marked and commented. I think you should also write down the policy when a Simple*Property used? - we discussed that same months ago already I'd be happy to put it in the wiki if you give me some words. I'm overloaded and drowning :) Ok. Let me see if I can come up with some words on this. Wouldn't it make sense to turn on things like static code analysis and compiler warnings in the grade build? I know that there was some effort in OpenJDK to compile -Xlint:all -Werror by default instead of suppressing them? At least I think this should be a target, not? Tom
Re: Code style guide lines
I think you should also write down the policy when a Simple*Property used? - we discussed that same months ago already I'd be happy to put it in the wiki if you give me some words. I'm overloaded and drowning :) Ok. Let me see if I can come up with some words on this. Wouldn't it make sense to turn on things like static code analysis and compiler warnings in the grade build? I know that there was some effort in OpenJDK to compile -Xlint:all -Werror by default instead of suppressing them? At least I think this should be a target, not? Yes definitely the goal. We need to get rid of all the impl_ guys first though, the amount of deprecation warnings we get is swamping any useful warning output. Richard
Re: Mixing 2D and 3D
Hi August, We did talk through some use cases such as PIP and rear view mirror. You can do simultaneous viewing from different points of view into a single 3D scene via the use of SubScenes. The key point, as you have clearly stated, is the need to clone the scene graph nodes per SubScene. - Chien On 7/25/2013 10:37 AM, Richard Bair wrote: Hi August, I think we already do multiple active cameras? More precisely: simultaneous viewing from different points of view into a single 3D scene graph was meant, i.e. several cameras are attached to one scene graph. A SubScene has exactly one camera attached which renders the associated scene graph into the corresponding SubScene's rectangle. Implementing simultaneous viewing requires a cloned 3D scene graph for the second, third, and so on SubScene/Camera. Material, Mesh, and Image objects can be re-used because they are shareable. Animations of Nodes' Transforms seem to be shareable as well. But Transitions (Rotate, Scale, Translate) have to be cloned because they operate on a Node's methods directly. So, simultaneous viewing seems practicable. Jasper or Kevin will have to comment, but I know this scenario was talked about extensively in the design for the renderToImage and cameras, and I thought this was possible today.
Re: Mixing 2D and 3D
Having to clone the nodes hardly seems like simultaneous viewing from different points of view? On Jul 25, 2013, at 5:17 PM, Chien Yang chien.y...@oracle.com wrote: Hi August, We did talk through some use cases such as PIP and rear view mirror. You can do simultaneous viewing from different points of view into a single 3D scene via the use of SubScenes. The key point, as you have clearly stated, is the need to clone the scene graph nodes per SubScene. - Chien On 7/25/2013 10:37 AM, Richard Bair wrote: Hi August, I think we already do multiple active cameras? More precisely: simultaneous viewing from different points of view into a single 3D scene graph was meant, i.e. several cameras are attached to one scene graph. A SubScene has exactly one camera attached which renders the associated scene graph into the corresponding SubScene's rectangle. Implementing simultaneous viewing requires a cloned 3D scene graph for the second, third, and so on SubScene/Camera. Material, Mesh, and Image objects can be re-used because they are shareable. Animations of Nodes' Transforms seem to be shareable as well. But Transitions (Rotate, Scale, Translate) have to be cloned because they operate on a Node's methods directly. So, simultaneous viewing seems practicable. Jasper or Kevin will have to comment, but I know this scenario was talked about extensively in the design for the renderToImage and cameras, and I thought this was possible today.
Re: Mixing 2D and 3D
We don't support sharable Node. Some one will have to do the cloning of the scenegraph, either the application or JavaFX. Now I may have opened a can of worms. ;-) - Chien On 7/25/2013 5:20 PM, Richard Bair wrote: Having to clone the nodes hardly seems like simultaneous viewing from different points of view? On Jul 25, 2013, at 5:17 PM, Chien Yang chien.y...@oracle.com wrote: Hi August, We did talk through some use cases such as PIP and rear view mirror. You can do simultaneous viewing from different points of view into a single 3D scene via the use of SubScenes. The key point, as you have clearly stated, is the need to clone the scene graph nodes per SubScene. - Chien On 7/25/2013 10:37 AM, Richard Bair wrote: Hi August, I think we already do multiple active cameras? More precisely: simultaneous viewing from different points of view into a single 3D scene graph was meant, i.e. several cameras are attached to one scene graph. A SubScene has exactly one camera attached which renders the associated scene graph into the corresponding SubScene's rectangle. Implementing simultaneous viewing requires a cloned 3D scene graph for the second, third, and so on SubScene/Camera. Material, Mesh, and Image objects can be re-used because they are shareable. Animations of Nodes' Transforms seem to be shareable as well. But Transitions (Rotate, Scale, Translate) have to be cloned because they operate on a Node's methods directly. So, simultaneous viewing seems practicable. Jasper or Kevin will have to comment, but I know this scenario was talked about extensively in the design for the renderToImage and cameras, and I thought this was possible today.
hg: openjfx/8/graphics/rt: RT-31945: Flatten Painter hierarchy
Changeset: 281a9fdae8bb Author:rbair Date: 2013-07-25 17:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/281a9fdae8bb RT-31945: Flatten Painter hierarchy - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/AbstractPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassAppletWindow.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassWindowEventHandler.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/OverlayWarning.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PaintCollector.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumRenderer.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java
Re: Mixing 2D and 3D
I thought the approach was not to have multiple parents, but to render into an image. On Jul 25, 2013, at 5:26 PM, Chien Yang chien.y...@oracle.com wrote: We don't support sharable Node. Some one will have to do the cloning of the scenegraph, either the application or JavaFX. Now I may have opened a can of worms. ;-) - Chien On 7/25/2013 5:20 PM, Richard Bair wrote: Having to clone the nodes hardly seems like simultaneous viewing from different points of view? On Jul 25, 2013, at 5:17 PM, Chien Yang chien.y...@oracle.com wrote: Hi August, We did talk through some use cases such as PIP and rear view mirror. You can do simultaneous viewing from different points of view into a single 3D scene via the use of SubScenes. The key point, as you have clearly stated, is the need to clone the scene graph nodes per SubScene. - Chien On 7/25/2013 10:37 AM, Richard Bair wrote: Hi August, I think we already do multiple active cameras? More precisely: simultaneous viewing from different points of view into a single 3D scene graph was meant, i.e. several cameras are attached to one scene graph. A SubScene has exactly one camera attached which renders the associated scene graph into the corresponding SubScene's rectangle. Implementing simultaneous viewing requires a cloned 3D scene graph for the second, third, and so on SubScene/Camera. Material, Mesh, and Image objects can be re-used because they are shareable. Animations of Nodes' Transforms seem to be shareable as well. But Transitions (Rotate, Scale, Translate) have to be cloned because they operate on a Node's methods directly. So, simultaneous viewing seems practicable. Jasper or Kevin will have to comment, but I know this scenario was talked about extensively in the design for the renderToImage and cameras, and I thought this was possible today.
hg: openjfx/8/controls/rt: 5 new changesets
Changeset: ff97242a4815 Author:jgiles Date: 2013-07-26 11:29 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ff97242a4815 RT-31907: Cleanup control code (part four: generic fixes for TableView) Contributed-by: Tom Schindl tom.schi...@bestsolution.at Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TableView.java Changeset: f5760de6984f Author:jgiles Date: 2013-07-26 11:36 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f5760de6984f RT-31907: Cleanup control code (part five: Yet more generic fixes) Contributed-by: Tom Schindl tom.schi...@bestsolution.at Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/CellSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerHijrahContent.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledImpl.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledText.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeView.java Changeset: f70737a74988 Author:jgiles Date: 2013-07-26 11:38 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f70737a74988 RT-31907: Cleanup control code (part six: Yet more generic fixes and cleanups) Contributed-by: Tom Schindl tom.schi...@bestsolution.at Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SliderSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkin.java Changeset: d575789123cc Author:jgiles Date: 2013-07-26 12:04 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d575789123cc Fix build failure. ! modules/controls/src/main/java/javafx/scene/control/TableCell.java Changeset: d2e66eac7422 Author:jgiles Date: 2013-07-26 15:14 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d2e66eac7422 RT-31692: VirtualFlow : GetAvailableCell protected RT-31570: Make some VirtualFlow method protected ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/skin/VirtualFlowTest.java
Re: Building JavaDoc and Sources JARs
You gotta set the BUILD_JAVADOC flag. Look in gradle.properties.template -- all the different flags are pretty well documented there. For sources, somebody else posted a message about wanting to do that, and I think that's great. Just need to get a patch to the gradle build to create a source zip (per platform, or just one big zip with everything in it?) Richard On Jul 25, 2013, at 8:24 PM, Daniel Zwolenski zon...@gmail.com wrote: For the Maven deploy I need a JAR of the JavaDoc and another containing the sources. That's the rules. How do I build these with the Gradle build? I tried: gradle javadoc and can't see any JavaDoc anywhere in the build directory? Admittedly I am running this on the 78 backport code, not the JFX code, but I believe this part of the build should be the same? Full log: Daniels-MacBook-Pro:jfx78 zonski$ /usr/local/gradle-1.6/bin/gradle javadoc The ConfigurationContainer.add() method has been deprecated and is scheduled to be removed in Gradle 2.0. Please use the create() method instead. :buildSrc:clean UP-TO-DATE :buildSrc:generateGrammarSource error(10): internal error: Can't get property indirectDelegates using method get/isIndirectDelegates from org.antlr.tool.Grammar instance : java.lang.NullPointerException java.util.Objects.requireNonNull(Objects.java:203) java.util.ArrayList.removeAll(ArrayList.java:674) org.antlr.tool.CompositeGrammar.getIndirectDelegates(CompositeGrammar.java:222) org.antlr.tool.Grammar.getIndirectDelegates(Grammar.java:2620) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:491) org.antlr.stringtemplate.language.ASTExpr.invokeMethod(ASTExpr.java:563) org.antlr.stringtemplate.language.ASTExpr.rawGetObjectProperty(ASTExpr.java:514) org.antlr.stringtemplate.language.ASTExpr.getObjectProperty(ASTExpr.java:416) org.antlr.stringtemplate.language.ActionEvaluator.attribute(ActionEvaluator.java:351) org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:136) org.antlr.stringtemplate.language.ActionEvaluator.templateApplication(ActionEvaluator.java:216) org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:126) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:84) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.codegen.CodeGenerator.write(CodeGenerator.java:1278) org.antlr.codegen.Target.genRecognizerFile(Target.java:94) org.antlr.codegen.CodeGenerator.genRecognizer(CodeGenerator.java:463) org.antlr.Tool.generateRecognizer(Tool.java:607) org.antlr.Tool.process(Tool.java:429) org.antlr.Tool.main(Tool.java:91) :buildSrc:compileJava :buildSrc:compileGroovy :buildSrc:processResources :buildSrc:classes :buildSrc:jar :buildSrc:assemble :buildSrc:compileTestJava Note: /Users/zonski/Development/openjdk/jfx78/jfx78-zonski/jfx78/buildSrc/src/test/java/com/sun/scenario/effect/compiler/parser/FieldSelectTest.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. :buildSrc:compileTestGroovy UP-TO-DATE :buildSrc:processTestResources UP-TO-DATE :buildSrc:testClasses :buildSrc:test :buildSrc:check :buildSrc:build Missing or incorrect path to 'jfxrt.jar': '/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/jfxrt.jar'. Perhaps bad JDK_HOME? /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home Unsupported gradle version 1.6 in use. Only 1.4 is supported OS_NAME: mac os x OS_ARCH: x86_64 JAVA_HOME: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre JDK_HOME:
Re: Can JavaFX do CAD?
Actually Jasper and Scott just pointed out some problems here. I mistyped
(should have been return _x; from the getter). But also I didn't handle the
case of binding, or setting via the property correctly here. So this modified
pattern doesn't work. I may be remembering it wrong and Alex can correct me.
Richard
On Jul 25, 2013, at 9:21 AM, Richard Bair richard.b...@oracle.com wrote:
Regarding memory requirements of the full lazy properties, let me state
the obvious:
- if the property is not used at all, we have a reference and a double
instead of just a reference (worse unless in bucket)
- if getters/setters are called, we still have a reference and a double
instead of full instantiated property (better)
- if a listener is added, we have instantiated property and a double instead
of just the property (slightly worse)
So it looks like it would make best sense to introduce this for properties
that are often get/set but usually don't have listeners on them. I'm not
sure if such set exists and can be identified.
Thanks Pavel, this is a good summary. Alex K. and I were looking at a pattern
for this once and he had another way to do it which was different than what I
had done in the past. The pattern I used to use was something like this:
private double _x;
private DoubleProperty x;
public final void setX(double value) {
if (x == null) {
_x = value;
} else {
x.set(value);
}
public final double getX() {
return x == null ? _x : x.get();
}
public final DoubleProperty xProperty() {
if (x == null) x = new DoubleProperty(this, x, _x);
return x;
}
instead it could be done like this which results in faster getters (because
you never have to delegate to another method), an almost immeasurably slower
setter, and slightly little less code:
private double _x;
private DoubleProperty x;
public final void setX(double value) {
_x = value;
if (x != null) x.set(value);
}
public final double getX() {
return x;
}
public final DoubleProperty xProperty() {
if (x == null) x = new DoubleProperty(this, x, _x);
return x;
}
The idea here is to always set the local field, so that we can always just
return the value immediately in the getter. Where I think this may make a
difference is on the smaller end systems (mobile / embedded) because from
previous analysis we saw that none of our getters were getting inlined -- we
actually paid the price of each method call overhead, because since we were
reading from the property objects and the property objects were a couple
methods worth of work for each getter call, the VM wouldn't inline the
generated code into the call sites. By using this pattern in places that are
commonly read, we would probably get these getters all inlined again and
avoid all the method call overhead entirely.
Richard
A different way to handle pulse timing
Hi, I'm probably missing something obvious and you guys on Glass / Prism / Quantum can help set me straight. I was thinking tonight of a different way of initiating pulse events that would, I think, completely smooth out the pulses such that we don't end up with drift due to the timer being at a different rate than the GPU. Suppose we have two variables in the system (and for simplicity lets talk about a single Scene, because one problem I think this idea has is with multiple scenes and I want to discuss that separately after the core mechanism is understood): - boolean pendingPulse - int runningAnimationCounter Whenever an animation starts, the runningAnimationCounter is incremented. When an animation ends, it is decremented (or it could be a SetAnimation or whatever). The pendingPulse is simply false to start with, and is checked before we submit another pulse. Whenever a node in the scene graph becomes dirty, or the scene is resized, or stylesheets are changed, or in any case something happens that requires us to draw again, we check this flag and fire a new pulse if one is not already pending. When a pulse occurs, we process animations first, then CSS, then layout, then validate all the bounds, and *then we block* until the rendering thread is available for synchronization. I believe this is what we are doing today (it was a change Steve and I looked at with Jasper a couple months ago IIRC). But now for the new part. Immediately after synchronization, we check the runningAnimationCounter. If it is 0, then we fire off a new pulse and leave the pendingPulse flag set to true. If runningAnimationCounter == 0, then we flip pendingPulse to false. Other than the pick that always happens at the end of the pulse, we do nothing else new and, if the pick didn't cause state to change, we are now quiescent. Meanwhile, the render thread has run off doing its thing. The last step of rendering is the present, where we will block until the thing is presented, which, when we return, would put us *immediately* at the start of the next 16.66ms cycle. Since the render thread has just completed its duties, it goes back to waiting until the FX thread comes around asking to sync up again. If there is an animation going on such that a new pulse had been fired immediately after synchronization, then that new pulse would have been handled while the previous frame was being rendered. Most likely, by the time the render thread completes presenting and comes back to check with the FX thread, it will find that the FX thread is already waiting for it with the next frames data. It will synchronize immediately and then carry on rendering another frame. I think the way this would behave is that, when an animation is first played, you will get two pulses close to each other. The first pulse will do its business and then synchronize and then immediately fire off another pulse. That next pulse will then also get processed and then the FX thread will block until the previous frame finishes rendering. During this time, additional events (either application generated via runLater calls happening on background threads, or from OS events) will get queued up. Between pulse #2 and pulse #3 then a bunch of other events will get processed, essentially playing catch-up. My guess is that this won't be a problem but you might see a hiccup at the start of a new animation if the event queue is too full and it can't process all that stuff in 16ms (because at this point we're really multi-theaded between the FX and render threads and have nearly 16ms for each thread to do their business, instead of only 8ms which is what you'd have in a single threaded system). Another question I have is around resize events and how those work. If they also come in to glass on the FX thread (but at a higher priority than user events like a pulse or other input events?) then what will happen is that we will get a resize event and process a half-a-pulse (or maybe a whole pulse? animations+css+layout or just css+layout?) and then render, pretty much just as fast as we can. As for multiple scenes, I'm actually curious how this happens today. If I have 2 scenes, and we have just a single render thread servicing both, then when I go to present, it blocks? Or is there a non-blocking present method that we use instead? Because if we block, then having 2 scenes would cut you down to 30fps maximum, wouldn't it? If we are non-blocking today (is that possible?) then the only way this proposed solution would work is if there was a different render thread per stage (which actually is something I think we ought to be doing anyway?). Thanks Richard
Re: Building JavaDoc and Sources JARs
I've enabled that property and I now get a bunch of errors (100+), some
random samples:
/Users/zonski/Development/openjdk/jfx78/jfx78-zonski/jfx78/modules/web/src/main/java/javafx/scene/web/HTMLEditor.java:31:
error: package com.sun.javafx.scene.web.skin does not exist
import com.sun.javafx.scene.web.skin.HTMLEditorSkin;
/Users/zonski/Development/openjdk/jfx78/jfx78-zonski/jfx78/modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java:186:
error: incorrect use of inline tag
* @inheritDoc
^
/Users/zonski/Development/openjdk/jfx78/jfx78-zonski/jfx78/modules/graphics/src/main/java/javafx/scene/input/Clipboard.java:93:
error: end tag missing: /code
* precode
/Users/zonski/Development/openjdk/jfx78/jfx78-zonski/jfx78/modules/controls/src/main/java/javafx/scene/control/TableColumn.java:381:
error: reference not found
* is the {@link PropertyValueFactory} class. Refer to this class for
more
I see properties talking about linking to the JavaDoc for the whole JDK
(which I'm now downloading). I will set this up but I don't think it's
going to solve most of those errors?
Some general feedback: Seems like a lot of hoops to jump through and magic
in the build still. I'm just trying to get some JavaDoc here, nothing
fancy. Apart from the errors working, it's not overly intuitive that I have
to set a BUILD_JAVADOC=true to make 'gradle javadoc' work - can't the
gradle command just force the jdoc to build? The gradle stuff is definitely
better than before but it's still not a check it out and get busy coding
setup, which I'm hoping is the eventual goal.
The IntelliJ project that comes down with it doesn't just open either. It
seems to be dependent on all the other JDK projects being there. I don't
know how Gradle works, but the Maven approach to this would be that all
your bits and pieces are stand-alone artefacts/modules with their own POM.
Each one could be built on their own (and the jar is then put in a repo)
and then they all just reference each other as needed. If you guys deployed
to repositories (literally a filesystem that follows a naming convention -
not that hard!) for your builds and deployed each of the modules, then
community developers could just reference these instead of having to build
and reference bits and pieces that they have no interest in.
On Fri, Jul 26, 2013 at 2:38 PM, Richard Bair richard.b...@oracle.comwrote:
You gotta set the BUILD_JAVADOC flag. Look in gradle.properties.template
-- all the different flags are pretty well documented there.
For sources, somebody else posted a message about wanting to do that, and
I think that's great. Just need to get a patch to the gradle build to
create a source zip (per platform, or just one big zip with everything in
it?)
Richard
On Jul 25, 2013, at 8:24 PM, Daniel Zwolenski zon...@gmail.com wrote:
For the Maven deploy I need a JAR of the JavaDoc and another containing
the
sources. That's the rules.
How do I build these with the Gradle build? I tried:
gradle javadoc
and can't see any JavaDoc anywhere in the build directory?
Admittedly I am running this on the 78 backport code, not the JFX code,
but
I believe this part of the build should be the same?
Full log:
Daniels-MacBook-Pro:jfx78 zonski$ /usr/local/gradle-1.6/bin/gradle
javadoc
The ConfigurationContainer.add() method has been deprecated and is
scheduled to be removed in Gradle 2.0. Please use the create() method
instead.
:buildSrc:clean UP-TO-DATE
:buildSrc:generateGrammarSource
error(10): internal error: Can't get property indirectDelegates using
method get/isIndirectDelegates from org.antlr.tool.Grammar instance :
java.lang.NullPointerException
java.util.Objects.requireNonNull(Objects.java:203)
java.util.ArrayList.removeAll(ArrayList.java:674)
org.antlr.tool.CompositeGrammar.getIndirectDelegates(CompositeGrammar.java:222)
org.antlr.tool.Grammar.getIndirectDelegates(Grammar.java:2620)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:491)
org.antlr.stringtemplate.language.ASTExpr.invokeMethod(ASTExpr.java:563)
org.antlr.stringtemplate.language.ASTExpr.rawGetObjectProperty(ASTExpr.java:514)
org.antlr.stringtemplate.language.ASTExpr.getObjectProperty(ASTExpr.java:416)
org.antlr.stringtemplate.language.ActionEvaluator.attribute(ActionEvaluator.java:351)
org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:136)
org.antlr.stringtemplate.language.ActionEvaluator.templateApplication(ActionEvaluator.java:216)
org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:126)
org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:84)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148)
Re: Building JavaDoc and Sources JARs
I've enabled that property and I now get a bunch of errors (100+), some
random samples:
I just ran it both on open and closed builds and am not seeing any errors. I'm
on the latest graphics team repo. Are you building from master? (Not that it
should matter). You had a build working before?
I see properties talking about linking to the JavaDoc for the whole JDK
(which I'm now downloading). I will set this up but I don't think it's going
to solve most of those errors?
I wouldn't imagine so. I'm pretty sure I don't have that configured.
Some general feedback: Seems like a lot of hoops to jump through and magic in
the build still. I'm just trying to get some JavaDoc here, nothing fancy.
Apart from the errors working, it's not overly intuitive that I have to set a
BUILD_JAVADOC=true to make 'gradle javadoc' work - can't the gradle command
just force the jdoc to build? The gradle stuff is definitely better than
before but it's still not a check it out and get busy coding setup, which I'm
hoping is the eventual goal.
Yes, good question. The reason there is a flag is so that when you build the
sdk (the default target at present) it doesn't build the javadoc which most
developers would find irritating every time they needed to run some test code
(although it doesn't bother me at all because I just develop from IDEA and it
doesn't run the gradle build for incremental stuff). I don't know if the
javadoc task can set the BUILD_JAVADOC flag early enough in the build cycle...
The IntelliJ project that comes down with it doesn't just open either. It
seems to be dependent on all the other JDK projects
Which projects? I'm guessing rt-closed and deploy. Really the way it should be
setup is the iml files for those modules should live in the rt-closed / deploy
directories, and then the modules.xml just references them. I think then you
could just open it and go.
being there. I don't know how Gradle works, but the Maven approach to this
would be that all your bits and pieces are stand-alone artefacts/modules with
their own POM. Each one could be built on their own (and the jar is then put
in a repo) and then they all just reference each other as needed. If you guys
deployed to repositories (literally a filesystem that follows a naming
convention - not that hard!) for your builds and deployed each of the
modules, then community developers could just reference these instead of
having to build and reference bits and pieces that they have no interest in.
We are doing the work to make it possible to publish to repositories (and have
been doing so for months). We will do so when we can.
I'm assuming here you're talking about publishing real builds (at least OpenJFX
ones) and not on a local developers machine ('cause there'd be no advantage to
that alone). But maybe you can help me understand another part of this problem,
which is that suppose we have two developers, A and B. A is on some code two
weeks old. B is completely up to date. B does some fix and pushes it. The build
server builds the artifacts and puts them in the repo. The next time A does a
build, it grabs the latest built artifacts for the code A isn't building
(WebView, for instance) and there is a compile/link error because the new
binaries from B are out of sync with the 2 week old code that A is building
with.
Normally you version for things like this, but in this case we're talking about
shared libraries that are unversioned -- they're SNAPSHOT. But one snapshot is
not equal to another. How to handle this? Right now in the closed builds we
have an explicit ant update step you have to run to get the latest binaries.
Richard
