Re: Clarification on javafx.concurrent.Task cancellation behavior
Hi Weiqi,
this is definitely a bug, I filed
https://javafx-jira.kenai.com/browse/RT-37067 to track this.
Thanks,
-Martin
On 11.5.2014 20:22, weiqi...@gmail.com wrote:
Hi,
Looking at the javafx.concurrent.Task code, I see the following in the nested class
TaskCallableV’s call() method:
try {
final V result = task.call();
if (!task.isCancelled()) {
// If it was not cancelled, then we take the return
// value and set it as the result.
task.runLater(new Runnable() {
@Override public void run() {
// The result must be set first, so that when the
// SUCCEEDED flag is set, the value will be
available
// The alternative is not the case, because you
// can assume if the result is set, it has
// succeeded.
task.updateValue(result);
task.setState(State.SUCCEEDED);
}
});
return result;
} else {
// There may have been some intermediate result in the
// task set from the background thread, so I want to be
// sure to return the most recent intermediate value
return task.getValue();
}
} catch (final Throwable th) {
….
}
When this code is executed off the JavaFX Application Thread, which I take to
be the case almost all the time, the “task.getValue()” call will always throw
an exception as the getValue() method does a checkThread() first. Is this
intentional?
The practical implication is that a cancelled task, in addition to its state
being CANCELLED, also has an IllegalStateException with a message of “Task must
only be used from the FX Application Thread” recorded as an exception of the
task if the task chooses to exit the call() method normally when the task is
cancelled. And of course, if the task chooses to exit the call() method
abruptly by throwing its own RuntimeException, that runtime exception will be
recorded as the exception of the task instead of the ISE.
--
Weiqi Gao
Dragboard#setDragViewOffsetX/Y limitations
Hi, Using Dragboard#setDragViewOffsetX/Y allows me to offset the drag image but it looks like this x/y is constrainted to the image.width/2 image.height/2. Is this OS specific, a general limitation or a bug? If it is 1 or 2 I think information on that in the JavaDoc would help understand that. Tom
Canvas initial delay issue
Hi all,
I'm trying to convert some Java2D code to JavaFX and I'm stuck with an
issue regarding the performance of the JavaFX Canvas. At some point, I'll
have to draw thousands of small circles on the screen.
My problem is on the first drawing, on which my code takes a lot of time to
execute. But if I have to perform a second drawing, it takes only a
fraction of the time to draw (it is at least 10 times faster).
Is there anything I'm doing wrong? Is there any way to prevent that initial
delay?
I wrote this code to test it. In this code I draw 500,000 circles at random
positions on a 1000 x 1000 canvas (built previously). I linked this code to
a button click event, and on the first time I click it takes 10 seconds to
execute. But if I just click again, it takes only 0.025 seconds.
private void paintCanvas() {
long initTime = System.currentTimeMillis();
GraphicsContext cg = canvas.getGraphicsContext2D();
cg.setFill(Color.WHITE);
cg.fillRect(0, 0, canvas.getWidth(), canvas.getHeight());
cg.setFill(Color.rgb(0, 0, 0, 0.1));
Random rand = new Random();
for (int i = 0; i 50; i++) {
cg.fillOval(1000 * rand.nextFloat(), 1000 * rand.nextFloat(), 2, 2);
}
long endTime = System.currentTimeMillis();
System.out.println(Time spent on drawing: + (endTime -
initTime)/1000.0f);}
Can anyone help me to understand the reason of this initial paint delay?
Thanks in advance,
Renato.
--
*Renato Rodrigues Oliveira da Silva*
VICG - Visualization, Imaging and Computer Graphics - ICMC - USP São Carlos
Re: Canvas initial delay issue
My guess is that the first time this runs, it is rasterizing the ovals and
caching them as textures on the GPU - then subsequent runs are just using
the pre-cached textures. If this is the case, I'm not sure there is a
simple solution for speeding up the first run.
On Mon, May 12, 2014 at 8:40 AM, Renato Rodrigues r...@icmc.usp.br wrote:
Hi all,
I'm trying to convert some Java2D code to JavaFX and I'm stuck with an
issue regarding the performance of the JavaFX Canvas. At some point, I'll
have to draw thousands of small circles on the screen.
My problem is on the first drawing, on which my code takes a lot of time to
execute. But if I have to perform a second drawing, it takes only a
fraction of the time to draw (it is at least 10 times faster).
Is there anything I'm doing wrong? Is there any way to prevent that initial
delay?
I wrote this code to test it. In this code I draw 500,000 circles at random
positions on a 1000 x 1000 canvas (built previously). I linked this code to
a button click event, and on the first time I click it takes 10 seconds to
execute. But if I just click again, it takes only 0.025 seconds.
private void paintCanvas() {
long initTime = System.currentTimeMillis();
GraphicsContext cg = canvas.getGraphicsContext2D();
cg.setFill(Color.WHITE);
cg.fillRect(0, 0, canvas.getWidth(), canvas.getHeight());
cg.setFill(Color.rgb(0, 0, 0, 0.1));
Random rand = new Random();
for (int i = 0; i 50; i++) {
cg.fillOval(1000 * rand.nextFloat(), 1000 * rand.nextFloat(), 2,
2);
}
long endTime = System.currentTimeMillis();
System.out.println(Time spent on drawing: + (endTime -
initTime)/1000.0f);}
Can anyone help me to understand the reason of this initial paint delay?
Thanks in advance,
Renato.
--
*Renato Rodrigues Oliveira da Silva*
VICG - Visualization, Imaging and Computer Graphics - ICMC - USP São Carlos
--
Steve Hannah
Web Lite Solutions Corp.
hg: openjfx/8u-dev/rt: [Accessibility] Window are suppose to have UIA_IsContentElementPropertyId=true and UIA_IsControlElementPropertyId=true. The fact these were false in JavaFX was due the a acciden
Changeset: 1ebbae8d6fc9 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-05-12 13:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1ebbae8d6fc9 [Accessibility] Window are suppose to have UIA_IsContentElementPropertyId=true and UIA_IsControlElementPropertyId=true. The fact these were false in JavaFX was due the a accidental changeset. A consequence of this error was the window not being visible to tools such as accevent.exe, and inspect.exe (Windows7) ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java
hg: openjfx/8u-dev/rt: 15 new changesets
Changeset: bba1bfdf8cba Author:jgiles Date: 2014-05-06 13:39 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bba1bfdf8cba [TEST ONLY] First attempt to fix a build server only test failure on Linux for RT-36955. ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewMouseInputTest.java Changeset: b7e1015ab37e Author:jgiles Date: 2014-05-06 14:23 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b7e1015ab37e RT-36942: JavaFX ListView SelectionModel java.lang.IllegalStateException ! modules/controls/src/main/java/javafx/scene/control/ListView.java ! modules/controls/src/test/java/javafx/scene/control/ListViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java Changeset: e95465693e03 Author:jgiles Date: 2014-05-06 16:47 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e95465693e03 RT-36932: TableView Cell Headers go out of Alignment when Columns Removed ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableHeaderRow.java Changeset: fcb9a6bbadd4 Author:jgiles Date: 2014-05-07 11:41 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/fcb9a6bbadd4 RT-36971: [RTL, Regression] RTL orientation, on ColorPicker palette, saved colors don't start from right. RT-36980: [RTL, Regression] RTL orientation, on ColorPicker palette, key navigation issue at both ends of the rows. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPalette.java Changeset: 85cd083a542a Author:jgiles Date: 2014-05-08 09:50 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/85cd083a542a RT-37009: Removing and instantly re-adding a Tab to the same TabPane does not work ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: 6f24ae710029 Author:jgiles Date: 2014-05-08 09:51 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6f24ae710029 RT-37007: [TabPane] NPE when in TabPane ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: 776ddd4c1b55 Author:jgiles Date: 2014-05-08 10:01 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/776ddd4c1b55 RT-37021: CustomMenuItem in a sub menu will fire once for each time the sub men has been shown. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: 76655dbc23fd Author:jgiles Date: 2014-05-08 11:13 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/76655dbc23fd RT-37015: [VirtualFlow] When height is zero, AIOOB occurs during layout ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 3faf10865303 Author:jgiles Date: 2014-05-08 13:32 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3faf10865303 RT-37022: CSS warnings logged to console when showing a sub menu in a rebuilt ContextMenu. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: 07114320d480 Author:jgiles Date: 2014-05-09 11:09 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/07114320d480 RT-24658: When Tab is disabled, its content must be disabled,too ! modules/controls/src/main/java/javafx/scene/control/Tab.java ! modules/controls/src/test/java/javafx/scene/control/TabPaneTest.java Changeset: 923349122172 Author:jgiles Date: 2014-05-12 12:56 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/923349122172 RT-37061: [TableView] Adding an item throws a ChangeEvent to the selectedItemProperty ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/test/java/javafx/scene/control/ListViewTest.java ! modules/controls/src/test/java/javafx/scene/control/SelectionModelImplTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java Changeset: 40998c2392ca Author:jgiles Date: 2014-05-12 15:14 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/40998c2392ca RT-37058: TableColumn sometimes ignores it's setPrefWidth() method ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java Changeset: dda9b7db686e Author:jgiles Date: 2014-05-13 08:42 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dda9b7db686e RT-37057: Hidden Columns confuse Column Re-ordering with Mouse ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/skin/TableColumnHeaderRetriever.java !
Re: [8u] Review Request: RT-36838 - Strange behavior of TreeItem's disclosure arrow // expanded/collapsed state not reflected correctly
Can I get your +1 or -1 on this change. Thanks. On 5/9/14, 10:45 AM, David Grieve wrote: Per Kevin's instructions, the previous changeset for RT-36838 was backed out in order to resolve RT-36995. I've attached a new webrev to RT-36838 which is an improved fix for RT-36838 and which also ensures RT-36995 doesn't regress. These changes won't be pushed until after M4 integration. http://cr.openjdk.java.net/~dgrieve/RT-36838/webrev.02/ https://javafx-jira.kenai.com/browse/RT-36838
[8u] Review Request: RT-37025 - CSS not reloaded when loaded through FXML
Jonathan, Can I get you to review https://javafx-jira.kenai.com/browse/RT-37025 http://cr.openjdk.java.net/~dgrieve/RT-37025/webrev.00/ Thanks
Re: Canvas initial delay issue
This is likely due to growing the command buffer which was done linearly
at one point (probably still done that way in 2.2), but is now
exponential in 8.0. The first render time is nearly instantaneous in
8.0, but takes a long time as you found when I try it with one of my old
2.x builds...
...jim
On 5/12/14 8:40 AM, Renato Rodrigues wrote:
Hi all,
I'm trying to convert some Java2D code to JavaFX and I'm stuck with an
issue regarding the performance of the JavaFX Canvas. At some point, I'll
have to draw thousands of small circles on the screen.
My problem is on the first drawing, on which my code takes a lot of time to
execute. But if I have to perform a second drawing, it takes only a
fraction of the time to draw (it is at least 10 times faster).
Is there anything I'm doing wrong? Is there any way to prevent that initial
delay?
I wrote this code to test it. In this code I draw 500,000 circles at random
positions on a 1000 x 1000 canvas (built previously). I linked this code to
a button click event, and on the first time I click it takes 10 seconds to
execute. But if I just click again, it takes only 0.025 seconds.
private void paintCanvas() {
long initTime = System.currentTimeMillis();
GraphicsContext cg = canvas.getGraphicsContext2D();
cg.setFill(Color.WHITE);
cg.fillRect(0, 0, canvas.getWidth(), canvas.getHeight());
cg.setFill(Color.rgb(0, 0, 0, 0.1));
Random rand = new Random();
for (int i = 0; i 50; i++) {
cg.fillOval(1000 * rand.nextFloat(), 1000 * rand.nextFloat(), 2, 2);
}
long endTime = System.currentTimeMillis();
System.out.println(Time spent on drawing: + (endTime -
initTime)/1000.0f);}
Can anyone help me to understand the reason of this initial paint delay?
Thanks in advance,
Renato.
Re: Canvas initial delay issue
For the record, no such lengthy caching is done. Ovals are either rendered using a single oval shader or on some platforms (i.e. embedded) using a combination of that shader or an oval farm that is populated nearly instantly on startup (a single texture upload)... ...jim On 5/12/14 9:58 AM, Steve Hannah wrote: My guess is that the first time this runs, it is rasterizing the ovals and caching them as textures on the GPU - then subsequent runs are just using the pre-cached textures. If this is the case, I'm not sure there is a simple solution for speeding up the first run.
hg: openjfx/8u-dev/rt: [Accessibility, Windows] Implement HighContrast Mode Detection
Changeset: f29a46d66886 Author:Joseph Andresen joseph.andre...@oracle.com Date: 2014-05-12 14:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f29a46d66886 [Accessibility, Windows] Implement HighContrast Mode Detection + apps/toys/Hello/src/main/java/hello/HelloHighContrast.java ! modules/graphics/src/main/java/com/sun/glass/ui/Application.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinApplication.java ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java ! modules/graphics/src/main/java/com/sun/javafx/css/StyleManager.java ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/native-glass/win/GlassApplication.cpp ! modules/graphics/src/main/native-glass/win/GlassApplication.h ! modules/graphics/src/main/native-glass/win/Utils.h
Review request: RT-28977 - 3D API methods should handle null values consistently
Hi Martin and Kevin, Please review the proposed fix: JIRA: https://javafx-jira.kenai.com/browse/RT-28977 Webrev: http://cr.openjdk.java.net/~ckyang/RT-28977/webrev.00/ Thanks, - Chien
