Re: add calculating methods to bind
That would be nice. Don't forget to add it to JIRA!
-Martin
On 23.5.2014 07:11, Tom Eugelink wrote:
I feel the standard binding should offer an easy hook option
heightProperty().multiply(3.4).calc( value - { snap(vallue); }
).add(5.0)
On 2014-5-21 22:00, Tomas Mikula wrote:
Just a side note, you could use
EasyBind.map(heightProperty(), value -
NodeUtil.snapXY(value.doubleValue() * 0.2));
instead of
snap(heightProperty().multiply(0.2))
and you don't need your custom DoubleBinding implementation. But note
that it returns BindingDouble, not DoubleBinding.
EasyBind is at http://www.fxmisc.org/easybind/
Tomas
On Wed, May 21, 2014 at 9:47 PM, Tomas Mikula
tomas.mik...@gmail.com wrote:
Yeah, and you could also eliminate Observable... dependencies from
snap's signature, since now you are not using them to invalidate your
binding.
On Wed, May 21, 2014 at 9:36 PM, Tom Eugelink t...@tbee.org wrote:
Found it! Slightly different DoubleBinding was required (copied it
from
negate).
private DoubleBinding snap(final ObservableNumberValue value,
final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(value);
}
@Override
public void dispose() {
super.unbind(value);
}
@Override
protected double computeValue() {
return NodeUtil.snapXY(value.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return FXCollections.singletonObservableList(value);
}
};
}
On 2014-5-21 21:34, Tomas Mikula wrote:
Hi Tom,
it seems to me that in your custom DoubleBinding implementation
`other` is not its dependency, thus it does not react to it's
invalidations.
Tomas
On Wed, May 21, 2014 at 9:25 PM, Tom Eugelink t...@tbee.org wrote:
I came up with this:
startXProperty().bind( *snap(*heightProperty().multiply(0.2)) )
And then:
private DoubleBinding snap(final ObservableNumberValue
other, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(dependencies);
}
@Override
public void dispose() {
super.unbind(dependencies);
}
@Override
protected double computeValue() {
return NodeUtil.snap(other.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return new
ImmutableObservableListObservable(dependencies);
}
};
}
But that always returns 0... I feel this should have worked.
Tom
Re: add calculating methods to bind
https://javafx-jira.kenai.com/browse/RT-37255
On 2014-5-23 8:05, Martin Sladecek wrote:
That would be nice. Don't forget to add it to JIRA!
-Martin
On 23.5.2014 07:11, Tom Eugelink wrote:
I feel the standard binding should offer an easy hook option
heightProperty().multiply(3.4).calc( value - { snap(vallue); } ).add(5.0)
On 2014-5-21 22:00, Tomas Mikula wrote:
Just a side note, you could use
EasyBind.map(heightProperty(), value -
NodeUtil.snapXY(value.doubleValue() * 0.2));
instead of
snap(heightProperty().multiply(0.2))
and you don't need your custom DoubleBinding implementation. But note
that it returns BindingDouble, not DoubleBinding.
EasyBind is at http://www.fxmisc.org/easybind/
Tomas
On Wed, May 21, 2014 at 9:47 PM, Tomas Mikula tomas.mik...@gmail.com wrote:
Yeah, and you could also eliminate Observable... dependencies from
snap's signature, since now you are not using them to invalidate your
binding.
On Wed, May 21, 2014 at 9:36 PM, Tom Eugelink t...@tbee.org wrote:
Found it! Slightly different DoubleBinding was required (copied it from
negate).
private DoubleBinding snap(final ObservableNumberValue value, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(value);
}
@Override
public void dispose() {
super.unbind(value);
}
@Override
protected double computeValue() {
return NodeUtil.snapXY(value.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return FXCollections.singletonObservableList(value);
}
};
}
On 2014-5-21 21:34, Tomas Mikula wrote:
Hi Tom,
it seems to me that in your custom DoubleBinding implementation
`other` is not its dependency, thus it does not react to it's
invalidations.
Tomas
On Wed, May 21, 2014 at 9:25 PM, Tom Eugelink t...@tbee.org wrote:
I came up with this:
startXProperty().bind( *snap(*heightProperty().multiply(0.2)) )
And then:
private DoubleBinding snap(final ObservableNumberValue other, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(dependencies);
}
@Override
public void dispose() {
super.unbind(dependencies);
}
@Override
protected double computeValue() {
return NodeUtil.snap(other.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return new
ImmutableObservableListObservable(dependencies);
}
};
}
But that always returns 0... I feel this should have worked.
Tom
Re: Layout regression
How can we be notified of exceptions like these programmatically? When my code is on the call stack, I can catch the exception programmatically. In this stack trace, only JavaFX code is there, but I still want to know that something bad happened. For the case of the JavaFX Application Thread, I guess I could do a Platform.runLater in that code call Thread.currentThread().setUncaughtExceptionHandler(myHandler) // ugh! Do I need to save away the previous one chain to it? Is that the best way for this thread? What about JavaFX's other threads? Does application code ever run on those threads? How can I know that something went wrong on those threads? Even if my code never runs there, I still want an automated way to know if something went wrong. Thanks, Neil From: Scott Palmer swpal...@gmail.com To: openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net, Date: 05/22/2014 03:56 PM Subject:Re: Layout regression Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net This appears to be a bug introduced in JavaFX 8 I have filed https://javafx-jira.kenai.com/browse/RT-37252 and will work on a test case. Scott On Thu, May 22, 2014 at 3:45 PM, Scott Palmer swpal...@gmail.com wrote: I'm investigating an issue with my application where things are working fine running with JavaFX 2.2 on 7u55, but I have a particular case where 8u5 is throwing the following exception during layout: Exception in thread JavaFX Application Thread java.lang.NullPointerException at javafx.scene.layout.GridPane.computeMinHeights(GridPane.java:1450) at javafx.scene.layout.GridPane.computeMinHeight(GridPane.java:1224) at javafx.scene.Parent.minHeight(Parent.java:946) at javafx.scene.layout.Region.minHeight(Region.java:1404) at javafx.scene.layout.Region.computeChildMinAreaHeight(Region.java:1700) at javafx.scene.layout.Region.getMaxAreaHeight(Region.java:1981) at javafx.scene.layout.Region.computeMaxMinAreaHeight(Region.java:1854) at javafx.scene.layout.StackPane.computeMinHeight(StackPane.java:293) at javafx.scene.Parent.minHeight(Parent.java:946) at javafx.scene.layout.Region.minHeight(Region.java:1404) at javafx.scene.layout.Region.computeChildPrefAreaHeight(Region.java:1765) at javafx.scene.layout.Region.getMaxAreaHeight(Region.java:1982) at javafx.scene.layout.Region.computeMaxPrefAreaHeight(Region.java:1884) at javafx.scene.layout.StackPane.computePrefHeight(StackPane.java:310) at javafx.scene.Parent.prefHeight(Parent.java:918) at javafx.scene.layout.Region.prefHeight(Region.java:1438) at com.sun.javafx.scene.control.skin.TitledPaneSkin.computePrefHeight(TitledPaneSkin.java:249) at javafx.scene.control.Control.computePrefHeight(Control.java:543) at javafx.scene.Parent.prefHeight(Parent.java:918) at javafx.scene.layout.Region.prefHeight(Region.java:1438) at javafx.scene.layout.Region.computeChildPrefAreaHeight(Region.java:1765) at javafx.scene.layout.GridPane.computePrefHeights(GridPane.java:1407) at javafx.scene.layout.GridPane.computePrefHeight(GridPane.java:1242) at javafx.scene.Parent.prefHeight(Parent.java:918) at javafx.scene.layout.Region.prefHeight(Region.java:1438) at com.sun.javafx.scene.control.skin.ScrollPaneSkin.computeScrollNodeSize(ScrollPaneSkin.java:916) at com.sun.javafx.scene.control.skin.ScrollPaneSkin.layoutChildren(ScrollPaneSkin.java:791) at javafx.scene.control.Control.layoutChildren(Control.java:574) at javafx.scene.Parent.layout(Parent.java:1076) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Scene.doLayoutPass(Scene.java:576) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2386) at com.sun.javafx.tk.Toolkit$3.run(Toolkit.java:321) at com.sun.javafx.tk.Toolkit$3.run(Toolkit.java:319) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:319) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:348) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:479) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:460) at com.sun.javafx.tk.quantum.QuantumToolkit$13.run(QuantumToolkit.java:327) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.access$300(WinApplication.java:39) at com.sun.glass.ui.win.WinApplication$4$1.run(WinApplication.java:112) at
[8u20] Review request for RT-37033: [SwingNode] JEditorPane in SwingNode inside TabPane does not get focus properly when clicked
Steve, Anton, Please review the fix for: https://javafx-jira.kenai.com/browse/RT-37033 -- best regards, Anthony
[8u26] Review request: RT-37085 [Monocle] FX crash on ODROID U3
Daniel, David, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-37085 at cr.openjdk.java.net/~kselle/webrev-20140523-1242-RT-37085/webrev/ Thanks, Lisa
Planning for M5: June 23, 2014 [RDP2]
Hi all, The next milestone M5, June 23, 2014 [RDP2], is an important one. Essentially, we are shipping FX for 8u20 after this. There is a week before the final FX ZBB date which is July 1, 2014, but we should not be touching any code during this week. After July 1 ZBB, we are stopping all development on FX 8u20 and starting on 8u40. Here is the plan for M5: May 26-30: Fix P123, fix or move P45 to 8u40 June 2-5: Fix P123, zero P45 targeted to 8u20 June 9-13: Fix P123, defer bugs that won't make it June 16-20: Code freeze, ramp down rules, fix doc bugs During the week June 16-20, the usual milestone rules will be in effect and we are likely to be quite ruthless about any code changes. We will likely only accept fixes for P12 critical bugs / regressions. Thanks to everyone for their hard work, Steve and Kevin
review request: RT-36639 [RTL] PasswordField rendering issue when it's highlighted.
Hi Steve, Please review: https://javafx-jira.kenai.com/browse/RT-36639 http://cr.openjdk.java.net/~fheidric/RT36639-MAC/webrev/ http://cr.openjdk.java.net/~fheidric/RT36639-LINUX/webrev/ Thanks Felipe
Monday, May 26 is a US holiday + (in)sanity testing
As a reminder, Monday, May 26 is a US holiday. We will keep to this week's freeze / insanity testing schedule, but as there will be fewer people testing, please be extra careful not to introduce a regression between now and 1am PT Monday. Barring a DOA or other stopper, I will integrate whatever is in the repo as of 1am Pacific that day + any critical stopper fixes approved by Steve (which are the only changesets that should go in between 1am and 1pm). Thanks. -- Kevin
Re: Planning for M5: June 23, 2014 [RDP2]
Steve can you clarify the process for various stages for retargeting bugs to a later release? On 5/23/2014 1:15 PM, Stephen F Northover wrote: Hi all, The next milestone M5, June 23, 2014 [RDP2], is an important one. Essentially, we are shipping FX for 8u20 after this. There is a week before the final FX ZBB date which is July 1, 2014, but we should not be touching any code during this week. After July 1 ZBB, we are stopping all development on FX 8u20 and starting on 8u40. Here is the plan for M5: May 26-30: Fix P123, fix or move P45 to 8u40 June 2-5: Fix P123, zero P45 targeted to 8u20 June 9-13: Fix P123, defer bugs that won't make it June 16-20: Code freeze, ramp down rules, fix doc bugs During the week June 16-20, the usual milestone rules will be in effect and we are likely to be quite ruthless about any code changes. We will likely only accept fixes for P12 critical bugs / regressions. Thanks to everyone for their hard work, Steve and Kevin
Re: Layout regression
Application code only runs on the app thread. Setting the uncaught exception handler should work for you. Steve On 2014-05-23 8:33 AM, ngalarn...@abinitio.com wrote: How can we be notified of exceptions like these programmatically? When my code is on the call stack, I can catch the exception programmatically. In this stack trace, only JavaFX code is there, but I still want to know that something bad happened. For the case of the JavaFX Application Thread, I guess I could do a Platform.runLater in that code call Thread.currentThread().setUncaughtExceptionHandler(myHandler) // ugh! Do I need to save away the previous one chain to it? Is that the best way for this thread? What about JavaFX's other threads? Does application code ever run on those threads? How can I know that something went wrong on those threads? Even if my code never runs there, I still want an automated way to know if something went wrong. Thanks, Neil From: Scott Palmer swpal...@gmail.com To: openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net, Date: 05/22/2014 03:56 PM Subject:Re: Layout regression Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net This appears to be a bug introduced in JavaFX 8 I have filed https://javafx-jira.kenai.com/browse/RT-37252 and will work on a test case. Scott On Thu, May 22, 2014 at 3:45 PM, Scott Palmer swpal...@gmail.com wrote: I'm investigating an issue with my application where things are working fine running with JavaFX 2.2 on 7u55, but I have a particular case where 8u5 is throwing the following exception during layout: Exception in thread JavaFX Application Thread java.lang.NullPointerException at javafx.scene.layout.GridPane.computeMinHeights(GridPane.java:1450) at javafx.scene.layout.GridPane.computeMinHeight(GridPane.java:1224) at javafx.scene.Parent.minHeight(Parent.java:946) at javafx.scene.layout.Region.minHeight(Region.java:1404) at javafx.scene.layout.Region.computeChildMinAreaHeight(Region.java:1700) at javafx.scene.layout.Region.getMaxAreaHeight(Region.java:1981) at javafx.scene.layout.Region.computeMaxMinAreaHeight(Region.java:1854) at javafx.scene.layout.StackPane.computeMinHeight(StackPane.java:293) at javafx.scene.Parent.minHeight(Parent.java:946) at javafx.scene.layout.Region.minHeight(Region.java:1404) at javafx.scene.layout.Region.computeChildPrefAreaHeight(Region.java:1765) at javafx.scene.layout.Region.getMaxAreaHeight(Region.java:1982) at javafx.scene.layout.Region.computeMaxPrefAreaHeight(Region.java:1884) at javafx.scene.layout.StackPane.computePrefHeight(StackPane.java:310) at javafx.scene.Parent.prefHeight(Parent.java:918) at javafx.scene.layout.Region.prefHeight(Region.java:1438) at com.sun.javafx.scene.control.skin.TitledPaneSkin.computePrefHeight(TitledPaneSkin.java:249) at javafx.scene.control.Control.computePrefHeight(Control.java:543) at javafx.scene.Parent.prefHeight(Parent.java:918) at javafx.scene.layout.Region.prefHeight(Region.java:1438) at javafx.scene.layout.Region.computeChildPrefAreaHeight(Region.java:1765) at javafx.scene.layout.GridPane.computePrefHeights(GridPane.java:1407) at javafx.scene.layout.GridPane.computePrefHeight(GridPane.java:1242) at javafx.scene.Parent.prefHeight(Parent.java:918) at javafx.scene.layout.Region.prefHeight(Region.java:1438) at com.sun.javafx.scene.control.skin.ScrollPaneSkin.computeScrollNodeSize(ScrollPaneSkin.java:916) at com.sun.javafx.scene.control.skin.ScrollPaneSkin.layoutChildren(ScrollPaneSkin.java:791) at javafx.scene.control.Control.layoutChildren(Control.java:574) at javafx.scene.Parent.layout(Parent.java:1076) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Parent.layout(Parent.java:1082) at javafx.scene.Scene.doLayoutPass(Scene.java:576) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2386) at com.sun.javafx.tk.Toolkit$3.run(Toolkit.java:321) at com.sun.javafx.tk.Toolkit$3.run(Toolkit.java:319) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:319) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:348) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:479) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:460) at com.sun.javafx.tk.quantum.QuantumToolkit$13.run(QuantumToolkit.java:327) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at
Bad performance with Canvas and extensive clipping
Hi,
Maybe as some of you might know I've been working since sometime on SWT
on JavaFX and to implement direct drawing operations we use JavaFX-Canvas.
I've today tried to run a heavy direct drawing grid implementation and
it performed very bad because it makes heavy use of clipping.
For a grid I've counted ~1500 clipping operations the library works
something like this:
boolean activeClip;
Canvas canvas = new Canvas();
public void setClipping(PathIterator pathIterator) {
GraphicsContext gc = canvas.getGraphicsContext2D();
if(activeClip) {
gc.restore();
activeClip= false;
}
if( pathIterator == null ) {
return;
}
activeClip = true;
float coords[] = new float[6];
gc.save();
gc.beginPath();
float x = 0;
float y = 0;
gc.moveTo(0, 0);
while( ! pathIterator.isDone() ) {
switch (pathIterator.currentSegment(coords)) {
case PathIterator.SEG_CLOSE:
gc.lineTo(x, y);
break;
case PathIterator.SEG_CUBICTO:
gc.bezierCurveTo(coords[0], coords[1],
coords[2], coords[3],
coords[4], coords[5]);
break;
case PathIterator.SEG_LINETO:
gc.lineTo(coords[0], coords[1]);
break;
case PathIterator.SEG_MOVETO:
gc.moveTo(coords[0], coords[1]);
x = coords[0];
y = coords[1];
break;
case PathIterator.SEG_QUADTO:
gc.quadraticCurveTo(coords[0], coords[1],
coords[2], coords[3]);
break;
default:
break;
}
pathIterator.next();
}
gc.clip();
gc.closePath();
}
Am I doing something ultimately wrong, totally wrong? Has anyone an idea
how I would work around the problem?
Tom
hg: openjfx/8u-dev/rt: [TEST] Fix compile error in unit tests (follow-on to RT-32597)
Changeset: 419ff0dc23c8 Author:kcr Date: 2014-05-23 12:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/419ff0dc23c8 [TEST] Fix compile error in unit tests (follow-on to RT-32597) ! modules/graphics/src/test/java/com/sun/javafx/pgstub/StubStage.java ! modules/graphics/src/test/java/com/sun/javafx/pgstub/StubToolkit.java
hg: openjfx/8u-dev/rt: RT-36056 arm builds should fail if missing toolchain
Changeset: 55abe340d827 Author:ddhill Date: 2014-05-23 15:27 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/55abe340d827 RT-36056 arm builds should fail if missing toolchain Reviewed-by: kcr ! buildSrc/android.gradle ! buildSrc/armv5sf.gradle ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/armv7hf.gradle ! buildSrc/armv7sf.gradle
(In)Sanity Monday...
Reminder to check out the matrix at https://wiki.openjdk.java.net/display/OpenJFX/8u20 for your insanity testing assignment for this week. Testing should take 1 hour or less. If your assignment takes longer, stop after an hour and continue where you left off the following week. Also, please review the weekly code freeze and push rules As Kevin mentioned, Monday is a US holiday so the US team will not be doing their testing this week. Happy testing! Lisa
Re: Bad performance with Canvas and extensive clipping
Are you clipping to an arbitrary path in all cases or just a rectangle?
Unfortunately we only offer the arbitrary clip-to-current-path method
that isn't optimized for basic rectangular clipping and it implements
soft clipping.
There is an outstanding tweak that we added faster clipping support for
WebNode and we need to start using it for
Node.setClipNode(non-rectangle) and Canvas, but we haven't implemented
that yet. (https://javafx-jira.kenai.com/browse/RT-30107) It basically
is a direct render this texture through that other texture as a clip
operation instead of the current code that runs it through some Blend
effect filters. It would definitely improve your run times, but I'm not
sure how much.
Even more savings could be had for rectangular clips if we provided some
way to communicate them to the GC...
...jim
On 5/23/14 11:47 AM, Tom Schindl wrote:
Hi,
Maybe as some of you might know I've been working since sometime on SWT
on JavaFX and to implement direct drawing operations we use JavaFX-Canvas.
I've today tried to run a heavy direct drawing grid implementation and
it performed very bad because it makes heavy use of clipping.
For a grid I've counted ~1500 clipping operations the library works
something like this:
boolean activeClip;
Canvas canvas = new Canvas();
public void setClipping(PathIterator pathIterator) {
GraphicsContext gc = canvas.getGraphicsContext2D();
if(activeClip) {
gc.restore();
activeClip= false;
}
if( pathIterator == null ) {
return;
}
activeClip = true;
float coords[] = new float[6];
gc.save();
gc.beginPath();
float x = 0;
float y = 0;
gc.moveTo(0, 0);
while( ! pathIterator.isDone() ) {
switch (pathIterator.currentSegment(coords)) {
case PathIterator.SEG_CLOSE:
gc.lineTo(x, y);
break;
case PathIterator.SEG_CUBICTO:
gc.bezierCurveTo(coords[0], coords[1],
coords[2], coords[3],
coords[4], coords[5]);
break;
case PathIterator.SEG_LINETO:
gc.lineTo(coords[0], coords[1]);
break;
case PathIterator.SEG_MOVETO:
gc.moveTo(coords[0], coords[1]);
x = coords[0];
y = coords[1];
break;
case PathIterator.SEG_QUADTO:
gc.quadraticCurveTo(coords[0], coords[1],
coords[2], coords[3]);
break;
default:
break;
}
pathIterator.next();
}
gc.clip();
gc.closePath();
}
Am I doing something ultimately wrong, totally wrong? Has anyone an idea
how I would work around the problem?
Tom
Re: (In)Sanity Monday...
In lieu of Monday's testing, I did run a full build / test on all three platforms (dev-build-full) this afternoon and ran a couple samples. No new issues. -- Kevin Lisa Selle wrote: Reminder to check out the matrix at https://wiki.openjdk.java.net/display/OpenJFX/8u20 for your insanity testing assignment for this week. Testing should take 1 hour or less. If your assignment takes longer, stop after an hour and continue where you left off the following week. Also, please review the weekly code freeze and push rules As Kevin mentioned, Monday is a US holiday so the US team will not be doing their testing this week. Happy testing! Lisa
hg: openjfx/8u-dev/rt: [Accessibility] On Windows, when a combobox closes, the Narrator focus stays behind where the last selected list item was. The fix is to send focus changed event when the window
Changeset: 2eb6b8e042b3 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-05-23 15:02 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2eb6b8e042b3 [Accessibility] On Windows, when a combobox closes, the Narrator focus stays behind where the last selected list item was. The fix is to send focus changed event when the window closes. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java
Re: Bad performance with Canvas and extensive clipping
Hi,
As an experiment I've now written a SWT-GC implementation using a
BufferedImage Graphics2D and transfering the pixels over to JavaFX and
the performance is as it is with native SWT.
I always thought Canvas works similar to Image and one only draws pixels
- looks like that is not the case, having a dep in my application
java.awt is not what I'm aiming at but without acceptable performance in
conjunction with clipping it looks like i have to go this route :-(
Tom
On 23.05.14 23:57, Tom Schindl wrote:
In the current usecase it is a rect all time but that's just in this special
use case.
I guess that rect clipping is the most common one so having an optimization
for rects and a slow path for none rects might help.
Tom
Von meinem iPhone gesendet
Am 23.05.2014 um 23:35 schrieb Jim Graham james.gra...@oracle.com:
Are you clipping to an arbitrary path in all cases or just a rectangle?
Unfortunately we only offer the arbitrary clip-to-current-path method that
isn't optimized for basic rectangular clipping and it implements soft
clipping.
There is an outstanding tweak that we added faster clipping support for
WebNode and we need to start using it for Node.setClipNode(non-rectangle)
and Canvas, but we haven't implemented that yet.
(https://javafx-jira.kenai.com/browse/RT-30107) It basically is a direct
render this texture through that other texture as a clip operation instead
of the current code that runs it through some Blend effect filters. It
would definitely improve your run times, but I'm not sure how much.
Even more savings could be had for rectangular clips if we provided some way
to communicate them to the GC...
...jim
On 5/23/14 11:47 AM, Tom Schindl wrote:
Hi,
Maybe as some of you might know I've been working since sometime on SWT
on JavaFX and to implement direct drawing operations we use JavaFX-Canvas.
I've today tried to run a heavy direct drawing grid implementation and
it performed very bad because it makes heavy use of clipping.
For a grid I've counted ~1500 clipping operations the library works
something like this:
boolean activeClip;
Canvas canvas = new Canvas();
public void setClipping(PathIterator pathIterator) {
GraphicsContext gc = canvas.getGraphicsContext2D();
if(activeClip) {
gc.restore();
activeClip= false;
}
if( pathIterator == null ) {
return;
}
activeClip = true;
float coords[] = new float[6];
gc.save();
gc.beginPath();
float x = 0;
float y = 0;
gc.moveTo(0, 0);
while( ! pathIterator.isDone() ) {
switch (pathIterator.currentSegment(coords)) {
case PathIterator.SEG_CLOSE:
gc.lineTo(x, y);
break;
case PathIterator.SEG_CUBICTO:
gc.bezierCurveTo(coords[0], coords[1], coords[2], coords[3],
coords[4], coords[5]);
break;
case PathIterator.SEG_LINETO:
gc.lineTo(coords[0], coords[1]);
break;
case PathIterator.SEG_MOVETO:
gc.moveTo(coords[0], coords[1]);
x = coords[0];
y = coords[1];
break;
case PathIterator.SEG_QUADTO:
gc.quadraticCurveTo(coords[0], coords[1], coords[2],
coords[3]);
break;
default:
break;
}
pathIterator.next();
}
gc.clip();
gc.closePath();
}
Am I doing something ultimately wrong, totally wrong? Has anyone an idea
how I would work around the problem?
Tom
