"Wrap text" backwards compatibility issue

[Daniel Zwolenski]

Since I had to run that old app for those performance screenshots, I found
this: https://javafx-jira.kenai.com/browse/RT-30868

I'm just highlighting it here because it is another pretty major backwards
compatibility issue between minor release versions. I think backwards
compatibility of styling is going to be pretty darn hard for you guys to
preserve (read "impossible").

Here's where I throw out my usual call to have Applets and Webstart
deprecated, so we don't need auto-updating, and so this kind of backwards
compatibility issue isn't so debilitating. Yea, yea, no go, whatever.

Hopefully I'm the only one who built an app with single letter buttons,
that also has the wrap-text flag set to true for the base button style, but
if you were unlucky enough to do this and your app is using web deployment,
you probably want to tweak your code around this.

Re: JavaFX graphics performance and suitability for advanced animations

[Daniel Zwolenski]

I tried your pixel snapping one and it is on par with the JScript version,
so it could be that either my system or my eye prefers that option. Good to
know we can switch between them at least to cater for different devices.
That project I captured in the last email had a fixed brand/model of tablet
that it was on so in that case it's good to be able to maximise performance
for that particular device.

I tried to taking screen captures of the different scenarios but it's too
fine detail and the animation just looks crap on all of them in the
captures.

I'm hearing you that this is a messy problem with no ideal, and some
options might be better in case A but worse in case B. Happy to say that
one is done and dusted and not worth going into deeper. I think the trick
will be to use coloured backgrounds - windows metro style.




On Sat, Jun 1, 2013 at 1:59 PM, Richard Bair wrote:

> > This looks bad for me though in FX, I'm wondering what it looks like for
> you.
>
> I ran with the pulse logger and definitely there is no frame taking more
> than a couple milliseconds. Things look awful because this example is
> truncating (by casting to int) instead of rounding, and so on each frame
> the rectangle is pixel snapped to a position that may be closer, or farther
> away from the expected location and our brain sees it. To test this theory,
> one thing I did was modify the sample so that instead of taking 3 seconds
> to travel 400 pixels, I use 4 seconds and I removed the EASE_BOTH
> interpolators. In this case the expected location on each frame is exactly
> a pixel boundary, and of course it looks smooth. Note though that the
> border still looks fuzzy (to me) but this is because the refresh rate on
> the monitor or possibly the eye is exhibiting a motion blur.
>
> public void start(Stage stage) throws Exception {
> final StackPane rootPane = new StackPane();
> VBox box = new VBox();
> box.setMaxSize(200, 200);
> box.setStyle("-fx-border-color: black; -fx-background-color:
> white; -fx-effect: dropshadow(two-pass-box , darkgray, 10, 0.0 , 4, 5);");
> rootPane.getChildren().add(box);
> createTranslation(box, 4, -200, -200, 200, 200).play();
>
> Scene scene = new Scene(rootPane, 1200, 800);
> stage.setScene(scene);
> stage.show();
> }
>
> protected Animation createTranslation(Node node, int seconds, int
> fromX, int fromY, int toX, int toY) {
> IntegerProperty xProperty = new SimpleIntegerProperty(fromX);
> IntegerProperty yProperty = new SimpleIntegerProperty(fromY);
> node.translateXProperty().bind(xProperty);
> node.translateYProperty().bind(yProperty);
>
> Timeline t = new Timeline(
> new KeyFrame(Duration.seconds(seconds),
> new KeyValue(xProperty, toX),
> new KeyValue(yProperty, toY)));
> t.setCycleCount(Timeline.INDEFINITE);
> t.setAutoReverse(true);
> return t;
> }
>
>
>
>
> And here is another version which instead keeps the interpolator and the 3
> second movement (so we're back to unexpected irregular positions) and we
> pixel snap by rounding instead of by truncating.
>
> public void start(Stage stage) throws Exception {
> final StackPane rootPane = new StackPane();
> VBox box = new VBox();
> box.setMaxSize(200, 200);
> box.setStyle("-fx-border-color: black; -fx-background-color:
> white; -fx-effect: dropshadow(two-pass-box , darkgray, 10, 0.0 , 4, 5);");
> rootPane.getChildren().add(box);
> createTranslation(box, 3, -200, -200, 200, 200).play();
>
> Scene scene = new Scene(rootPane, 1200, 800);
> stage.setScene(scene);
> stage.show();
> }
>
> class RoundingValue extends SimpleDoubleProperty {
> public RoundingValue(int initialValue) {
> super(initialValue);
> }
>
> @Override public void set(double newValue) {
> super.set(Math.round(newValue));
> }
> }
>
> protected Animation createTranslation(Node node, int seconds, int
> fromX, int fromY, int toX, int toY) {
> RoundingValue xProperty = new RoundingValue(fromX);
> RoundingValue yProperty = new RoundingValue(fromY);
> node.translateXProperty().bind(xProperty);
> node.translateYProperty().bind(yProperty);
>
> Timeline t = new Timeline(
> new KeyFrame(Duration.seconds(seconds),
> new KeyValue(xProperty, toX,
> Interpolator.EASE_BOTH),
> new KeyValue(yProperty, toY,
> Interpolator.EASE_BOTH)));
> t.setCycleCount(Timeline.INDEFINITE);
> t.setAutoReverse(true);
> return t;
> }
>
>
> This looks pretty good perhaps this is what you are seeing in the browser?
>
> Richard

Animation swipe stutter

[Daniel Zwolenski]

Here is another one I can't reproduce in a constrained example.
http://www.screencast.com/t/ufJsZhiLhNJH

This is a real world app that runs on a tablet (Windows). I tried to give
this app a bit of an "iPad style", with animations to transition between
screens, etc (this was built a year or two ago). Many of the animations '
perform poorly' and are either slow or jumpy, etc, but it's hard to capture
on video and hard to replicate in simple examples.

In this video you can see a 'stutter' as the animation goes from left to
right and back again. The stutter is right at the end just before the
transition finishes. Sometimes it's pretty much perfect but 70% of the time
it either overshoots and re-adjusts or just suddenly jumps to the end point
before it's finished the smooth animation. At least that's the visual
effect as far as I can tell.

This (and many of the problems) could very well be an issue with the actual
code on my end and not true JFX issues. I've tried to narrow down further
but it is very time consuming to do this and it would help to know if there
were any rough guesses at what might be causing this problem.

Is it the fact that everything is so highly styled, or just the number of
components, is it something like I shouldn't do any actual real work in an
'on finished' method, etc? If there are any possible leads then I can try
and put together a small sample but at the moment I'm firing randomly.

As far as the code goes, it's a fairly standard parallel transition
containing two translate transitions. A very simple example of the sort of
logic used can be seen here:
https://code.google.com/p/zenjava-playtime/source/browse/trunk/javafx-performance/animate1/src/main/java/com/zenjava/jfx/performance/animate1/SwipeApp.java

But this one animates consistently smooth.

Re: Canvas clip problems

[Scott Palmer]

Try
-Dprism.order=sw
with JavaFS 8

or
-Dprism.order=j2d
with JavaFX 2.2

to see if the clipping issue goes away.

Also try -Dprism.dirtyopts=false to see if that fixes the smearing.


On Sat, Jun 1, 2013 at 9:14 PM, Scott Palmer  wrote:

> This looks like it may be related to the clipping issue that I'm having
> (the one that forces me o use the software pipeline in JavaFX 8 or the j2d
> pipeline in JavaX 2.2)
>
> https://javafx-jira.kenai.com/browse/RT-30591
>
> I'll try to do the same screencast thingy, as the still in my report don't
> do justice to the problem.
>
> Scott
>
>
> On Sat, Jun 1, 2013 at 8:55 PM, Richard Bair wrote:
>
>> "Cheese" (the smear) should never be possible. It means that the clip
>> used on the device is wrong for some reason, and therefore some area of the
>> screen was not being repainted that needed to be. In Swing (or Android or
>> any other immediate mode API) it is possible that your app could have a bug
>> that causes this, but with the scene graph the responsibility is with JFX
>> not to mess up the dirty regions.
>>
>> My guess is this is related to the other issue you already filed about
>> the "z order" rendering issue (which is also related to the clip being
>> wrong). It might be worth putting the link to the screencast on that bug
>> report.
>>
>> Richard
>>
>> On Jun 1, 2013, at 3:21 PM, Daniel Zwolenski  wrote:
>>
>> > Here is one I can't reproduce in smaller code.
>> >
>> > http://www.screencast.com/t/AJZjx1TjFT
>> >
>> > You can see that when the enemies start off the canvas they end up
>> leaving
>> > a smear behind. When they leave the canvas at the other end they also
>> > smear.
>> >
>> > I suspect it's something to do with the clipping code used in the game
>> but
>> > I haven't been able to narrow it down (and this area I was a bit flaky
>> on
>> > and I think Richard did the starting setup for).
>> >
>> > It's probably a case of clipping properly, but should this sort of
>> > behaviour be even possible to occur?
>> >
>> > p.s. thanks for the Camtasia tips - nice product.
>>
>>
>

Re: Canvas clip problems

[Scott Palmer]

This looks like it may be related to the clipping issue that I'm having
(the one that forces me o use the software pipeline in JavaFX 8 or the j2d
pipeline in JavaX 2.2)

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

I'll try to do the same screencast thingy, as the still in my report don't
do justice to the problem.

Scott


On Sat, Jun 1, 2013 at 8:55 PM, Richard Bair wrote:

> "Cheese" (the smear) should never be possible. It means that the clip used
> on the device is wrong for some reason, and therefore some area of the
> screen was not being repainted that needed to be. In Swing (or Android or
> any other immediate mode API) it is possible that your app could have a bug
> that causes this, but with the scene graph the responsibility is with JFX
> not to mess up the dirty regions.
>
> My guess is this is related to the other issue you already filed about the
> "z order" rendering issue (which is also related to the clip being wrong).
> It might be worth putting the link to the screencast on that bug report.
>
> Richard
>
> On Jun 1, 2013, at 3:21 PM, Daniel Zwolenski  wrote:
>
> > Here is one I can't reproduce in smaller code.
> >
> > http://www.screencast.com/t/AJZjx1TjFT
> >
> > You can see that when the enemies start off the canvas they end up
> leaving
> > a smear behind. When they leave the canvas at the other end they also
> > smear.
> >
> > I suspect it's something to do with the clipping code used in the game
> but
> > I haven't been able to narrow it down (and this area I was a bit flaky on
> > and I think Richard did the starting setup for).
> >
> > It's probably a case of clipping properly, but should this sort of
> > behaviour be even possible to occur?
> >
> > p.s. thanks for the Camtasia tips - nice product.
>
>

Re: Canvas clip problems

[Richard Bair]

"Cheese" (the smear) should never be possible. It means that the clip used on 
the device is wrong for some reason, and therefore some area of the screen was 
not being repainted that needed to be. In Swing (or Android or any other 
immediate mode API) it is possible that your app could have a bug that causes 
this, but with the scene graph the responsibility is with JFX not to mess up 
the dirty regions.

My guess is this is related to the other issue you already filed about the "z 
order" rendering issue (which is also related to the clip being wrong). It 
might be worth putting the link to the screencast on that bug report.

Richard

On Jun 1, 2013, at 3:21 PM, Daniel Zwolenski  wrote:

> Here is one I can't reproduce in smaller code.
> 
> http://www.screencast.com/t/AJZjx1TjFT
> 
> You can see that when the enemies start off the canvas they end up leaving
> a smear behind. When they leave the canvas at the other end they also
> smear.
> 
> I suspect it's something to do with the clipping code used in the game but
> I haven't been able to narrow it down (and this area I was a bit flaky on
> and I think Richard did the starting setup for).
> 
> It's probably a case of clipping properly, but should this sort of
> behaviour be even possible to occur?
> 
> p.s. thanks for the Camtasia tips - nice product.

hg: openjfx/8/controls/rt: RT-28346: TextArea - Pressing ENTER/RETURN does not move cursor to new line

[hang . vo]

Changeset: 2f5985406164
Author:leifs
Date:  2013-06-01 17:39 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2f5985406164

RT-28346: TextArea - Pressing ENTER/RETURN does not move cursor to new line

! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java

Canvas clip problems

[Daniel Zwolenski]

Here is one I can't reproduce in smaller code.

http://www.screencast.com/t/AJZjx1TjFT

You can see that when the enemies start off the canvas they end up leaving
a smear behind. When they leave the canvas at the other end they also
smear.

I suspect it's something to do with the clipping code used in the game but
I haven't been able to narrow it down (and this area I was a bit flaky on
and I think Richard did the starting setup for).

It's probably a case of clipping properly, but should this sort of
behaviour be even possible to occur?

p.s. thanks for the Camtasia tips - nice product.

Aliased image edges when rotated

[Richard Bair]

Hi Michael,

I've modified the thread so we can keep these different threads straight :-)


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

I've copied the relevant comment from RT-6933 (not sure it needs to be internal 
but it has attachments I'd have to vet, easier to copy the common tout) into 
RT-11486 which is the issue for introducing an API to allow you to choose how 
you want rotated images to look. This is interesting in that the idea of having 
a rendering hint is very similar to that being discussed for fonts (RT-6475) 
which we are discussing on that issue as being something to have specified on 
all shapes, although maybe we want it also on Images.

> Anyway - you still can't animate images smoothly with JavaFX out of the box
> because although the image itself is placed at sub-pixel positions the border
> of the image is clipped to exact pixel boundaries which makes the animation 
> look bad.
> 
> I have attached code to show this. You can also switch between a smooth and a
> non-smooth animation by clicking into the image with the mouse. When you
> click into the image I apply a little hack so the animation becomes smooth. 
> But
> one should not be forced to use such tricks with a framework like JavaFX in 
> order
> to get a smooth animation for such a trivial use case.

Agreed. Lets discuss on RT-11486 what kind of API should be exposed. I'm not 
sure what the level of effort is on the implementation in this case.

Richard

Re: JavaFX graphics performance and suitability for advanced animations

[Dr. Michael Paus]

On 31.05.13 23:35, Richard Bair wrote:

We should start simple and work our way up. Since we've spent most of our time 
working on raw frame rates, perhaps it would be best to face down the jitter 
problem first. Lets start with something simple: a basic translate transition 
of a rectangle, and see how that goes.


Hi,
I'd like to add a very similar problem - a translate transition of a 
simple image.

This is something you see very often in animation examples but although the
JavaFX problem associated with this has already been reported many years ago
(on monday it will be exactly 3 years) this has not been fixed until now.
(I just checked it with JDK8 b92) My original report
 was marked as a duplicate,
although I am still not sure it really is but I can't check this because 
the explanation

of the possible reason in RT-6933 is kept secret.

Anyway - you still can't animate images smoothly with JavaFX out of the box
because although the image itself is placed at sub-pixel positions the 
border
of the image is clipped to exact pixel boundaries which makes the 
animation look bad.


I have attached code to show this. You can also switch between a smooth 
and a

non-smooth animation by clicking into the image with the mouse. When you
click into the image I apply a little hack so the animation becomes 
smooth. But
one should not be forced to use such tricks with a framework like JavaFX 
in order

to get a smooth animation for such a trivial use case.

Here comes the code: (You can use the image from the original bug report)


package bugs.smoothness;

import java.awt.image.BufferedImage;
import java.io.IOException;
import java.io.InputStream;

import javafx.animation.Animation;
import javafx.animation.Interpolator;
import javafx.animation.TranslateTransition;
import javafx.application.Application;
import javafx.embed.swing.SwingFXUtils;
import javafx.event.EventHandler;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.image.Image;
import javafx.scene.image.ImageView;
import javafx.scene.input.MouseEvent;
import javafx.scene.paint.Color;
import javafx.stage.Stage;
import javafx.util.Duration;

import javax.imageio.ImageIO;

public class ImageAnimation extends Application {
private static final String INPUT_IMAGE = "image1.jpg";

private static final double WIDTH = 1024;
private static final double HEIGHT = 768;

private static final Duration DURATION = Duration.millis(10);

private Image image1;
private Image image2;

private ImageView imageView;

private TranslateTransition moveAnim;

private Stage currentStage;

public Image createImage(String relFilePath, boolean smooth) {
InputStream is = getClass().getResourceAsStream(relFilePath);
Image image = null;

if (smooth) {
try {
BufferedImage i1 = ImageIO.read(is);

BufferedImage i2 = new BufferedImage(i1.getWidth()+2, 
i1.getHeight()+2, BufferedImage.TYPE_INT_ARGB);
i2.getGraphics().drawImage(i1, 1, 1, new 
java.awt.Color(0, 0, 0, 0), null);


image = SwingFXUtils.toFXImage(i2, null);
} catch (IOException e1) {
e1.printStackTrace();
}
} else {
image = new Image(is);
}

if (image != null && !image.isError()) {
return image;
} else {
System.err.println("Could not open " + relFilePath);
return null;
}
}

public void adjustStageTitle() {
if (imageView.getImage() == image1) {
currentStage.setTitle("image1 - standard border");
} else {
currentStage.setTitle("image2 - one pixel transparent border");
}
}

@Override public void start(Stage stage) {
System.out.println("javafx.runtime.version: " + 
System.getProperties().get("javafx.runtime.version"));


currentStage = stage;

image1 = createImage(INPUT_IMAGE, false);
image2 = createImage(INPUT_IMAGE, true);

imageView = new ImageView(image1);
imageView.setSmooth(true);
imageView.addEventHandler(MouseEvent.MOUSE_CLICKED, new 
EventHandler() {

@Override
public void handle(MouseEvent event) {
Image currentImage = imageView.getImage();
if (currentImage == image1) {
imageView.setImage(image2);
} else {
imageView.setImage(image1);
}
adjustStageTitle();
}
});

Group root = new Group();
root.getChildren().add(imageView);

// create scene
Scene scene = new Scene(root, WIDTH, HEIGHT);
scene.setFill(Color.LIGHTGRAY);

stage.setScene(scene);

adjustStageTitle();

// show stage
s

hg: openjfx/8/graphics/rt: 2 new changesets

[hang . vo]

Changeset: cc621195ec3c
Author:kcr
Date:  2013-06-01 08:00 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cc621195ec3c

[TEST-ONLY] Disable failing unit tests until RT-30865 is fixed

! javafx-beans/test/javafx/collections/ObservableArrayTest.java

Changeset: 582edfecdb04
Author:kcr
Date:  2013-06-01 08:00 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/582edfecdb04

imported patch gradle-builders

! build.gradle
! generator.gradle
! settings.gradle