Okay, yes, I generally agree. I would have to take a crack at coding the
Brick Breaker sample with Transition and Timelines to fully appreciate
it. Adjusting a transition on-the-fly might make sense, but there are
limitations. E.g. the Transition's duration is fixed, is it not? Brick
Breaker
As I see it, our animation API can be viewed as four levels:
- simple transitions
- custom transitions
- timelines
- AnimationTimer
If you know how an object will move, you should be fine with the upper
two. If you want to react on user actions you can still adjust the
transitions in input even
In this particular example you may be right. The trajectory of the ball
can be pre-computed for at least the entire length of the straight line
that it will travel in. You could go a couple bounces ahead even, to the
point where the ball would get back to the bottom. However, that is
definitely n
Can you make the changes and verify the results? BrickBreaker and the
other samples are supposed to be "how to" examples for people to emulate.
Steve
On 03/06/2013 7:56 AM, Pavel Safrata wrote:
Hello,
I'm a bit behind with this thread but I want to make a few comments on
AnimationTimer as t
Hello,
I'm a bit behind with this thread but I want to make a few comments on
AnimationTimer as there is a hidden message in the discussion that
AnimationTimer is the way to go.
First, AnimationTimer is called in each pulse, which doesn't have much
in common with display refresh rate (if I u
On 1/06/2013 02:24, Daniel Zwolenski wrote:
Can anyone recommend any good screen capture software for windows? Not sure
it would capture this problem but it would be useful for some of the other
problems I'm seeing in the TD game that I can't seem to reproduce in small
snippets of code.
I used ht
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
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 s
> 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
> If I fill the box with a darkish color (blue) the shimmering is barely
> detectable and with yellow it is less pronounced. Could it be that the
> shimmer is more pronounced to the eye if it is on the 'inside' of the box.
> Maybe if the inside of the border was kept crisp the eye is ok with the
No problem. I wish I took a look sooner!
Scott
On 2013-05-31, at 4:45 PM, Richard Bair wrote:
> I pushed the fix to graphics. Thanks Scott for tracking that down! It looks
> 10x better.
>
> Richard
>
> On May 31, 2013, at 9:25 AM, Richard Bair wrote:
>
>> Patch attached to https://javafx
For screen capture as video then Camtasia is the way to go (from the makers of
SnagIt too)
On 01/06/2013, at 10:44, "John C. Turnbull" wrote:
> Try SnagIt for screen shots. It's really very good.
>
> -jct
>
> On 01/06/2013, at 10:24, Daniel Zwolenski wrote:
>
>> Can anyone recommend any go
Try SnagIt for screen shots. It's really very good.
-jct
On 01/06/2013, at 10:24, Daniel Zwolenski wrote:
> Can anyone recommend any good screen capture software for windows? Not sure
> it would capture this problem but it would be useful for some of the other
> problems I'm seeing in the TD g
This is the issue: https://javafx-jira.kenai.com/browse/RT-6475
Lets carry on the conversation there about the API. Basically what we need is a
simple API on Text (which we can then also add to Labeled) that allows you to
pick the rendering mode. Right now we're picking it for you (and happen to
Yes, this one is beautiful on my system. Nice!
I tried scaling down to 0 instead of 1, there is a slight jitter and
pixelation at the tiny ranges.
I also tried swapping in a Label instead Text just to see. It is also very
pretty at the larger sizes and possibly the pixelation and jitter is
slight
Can anyone recommend any good screen capture software for windows? Not sure
it would capture this problem but it would be useful for some of the other
problems I'm seeing in the TD game that I can't seem to reproduce in small
snippets of code.
If I had to describe what I was seeing I would say tha
>> The text in PowerPoint is very likely outlines (treat the text as shapes)
>> since there isn't much text per slide and its usually very large (in fact
>> most render engines stop rendering text as glyphs at a given size -- for us
>> it is > 80pt.). H. I wonder if you used an 81pt font and
On 5/31/13 4:52 PM, Richard Bair wrote:
The text in PowerPoint is very likely outlines (treat the text as shapes) since
there isn't much text per slide and its usually very large (in fact most render
engines stop rendering text as glyphs at a given size -- for us it is > 80pt.).
H. I wonde
> The text in PowerPoint is very likely outlines (treat the text as shapes)
> since there isn't much text per slide and its usually very large (in fact
> most render engines stop rendering text as glyphs at a given size -- for us
> it is > 80pt.). H. I wonder if you used an 81pt font and sca
>> The text in PowerPoint is very likely outlines (treat the text as shapes)
>> since there isn't much text per slide and its usually very large (in fact
>> most render engines stop rendering text as glyphs at a given size -- for us
>> it is > 80pt.). H. I wonder if you used an 81pt font and
The text in PowerPoint is very likely outlines (treat the text as shapes) since
there isn't much text per slide and its usually very large (in fact most render
engines stop rendering text as glyphs at a given size -- for us it is > 80pt.).
H. I wonder if you used an 81pt font and scaled it d
I just did some animated text scaling in PowerPoint and it was beautiful. If
jfx did that you'd have no complaints from me.
Is it worth me putting up the PPS file for comparison? Can you open PPS on Mac?
I did the box one too and it was roughly on par with jscript one, though the
drop shadow s
We used the second method in a case where we painted animated Swing hierarchies
in an external OpenGL context, each character associated bitmap was cached when
it was necessary to draw the Glyph. The result seemed ok to us. Now I'm
thinking that we could have done the same thing in pure Java rat
Yes, and sounds like what we want to do with Text. Basically in your swing
example you were treating the text as outlines rather than glyphs. It draws
much nicer -- but also much slower.
The other option is to treat them as images and not snap-em. Not as nice but
probably quite decent for a lot
I don't know if there is the same behavior in JavaFX as in Swing, but using
Swing for complex animated rendering of texts, we discovered that if we used
the standard way of daring the strings in a Graphics2D, there was a kind of
Jitter on each String when moving or rotating the texts, the letter
ble. I am going to devote some time into building OpenJFX and trying
> to get to the bottom of the performance issues I have informally reported.
>
> If other products can achieve high-quality and high-performance animations
> on my computers then why can't JavaFX? The answers m
Felipe found these links:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee663563(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd756767%28v=vs.85%29.aspx
I followed the 2nd link to run in Parallels. I'm not sure to what extent it is
the same as what you'd see on
I pushed the fix to graphics. Thanks Scott for tracking that down! It looks 10x
better.
Richard
On May 31, 2013, at 9:25 AM, Richard Bair wrote:
> Patch attached to https://javafx-jira.kenai.com/browse/RT-29801. I'm not
> seeing any stutter on my Mac, interested to hear the experience on Wind
The magnifying glass is harder (but with render to image you could do it I
think). Otherwise I agree this should be quite doable.
Richard
On May 31, 2013, at 9:17 AM, Scott Palmer wrote:
> Flip the link from Mobile to Desktop at the top.
>
> I think JavaFX could easily handle this.
>
> Scott
Patch attached to https://javafx-jira.kenai.com/browse/RT-29801. I'm not seeing
any stutter on my Mac, interested to hear the experience on Windows.
Richard
On May 31, 2013, at 8:44 AM, Richard Bair wrote:
> Ya I did the same, am now adjusting it so the factor by which things move is
> better
Flip the link from Mobile to Desktop at the top.
I think JavaFX could easily handle this.
Scott
On Fri, May 31, 2013 at 12:08 PM, Richard Bair wrote:
> The link didn't work for me, is there another link? (It came up with a
> page of videos, the top one being video.3gp)
>
> Richard
>
> On May 3
The link didn't work for me, is there another link? (It came up with a page of
videos, the top one being video.3gp)
Richard
On May 31, 2013, at 8:46 AM, Daniel Zwolenski wrote:
> Just on the topic of what should we expect performance/animation/graphic
> wise, are there technical limitations w
Just on the topic of what should we expect performance/animation/graphic wise,
are there technical limitations why jfx can't achieve this exact level of
quality in animations:
http://m.youtube.com/#/watch?v=-fNg-qZcIdY&feature=youtube_gdata_player&desktop_uri=%2Fwatch%3Fv%3D-fNg-qZcIdY%26feature
Ya I did the same, am now adjusting it so the factor by which things move is
better.
Richard
On May 31, 2013, at 8:32 AM, Scott Palmer wrote:
> Richard, I suspect you made a typo. I think you mean "*40*ms is a really odd
> number..." (it was 25 FPS, not 25ms)
>
> I quickly hacked it to use
Richard, I suspect you made a typo. I think you mean "*40*ms is a really
odd number..." (it was 25 FPS, not 25ms)
I quickly hacked it to use AnimationTimer and the animation is very smooth
now. Though I didn't make the required changes to adjust the speeds based
on the refresh rate. The quick c
Btw, there is a JIRA issue filed against BrickBreaker specifically:
https://javafx-jira.kenai.com/browse/RT-29801
Richard Bair wrote:
Have you tried to determine what the FPS is? My guess is that FPS is not
anywhere near the limit and it is the occasional stutter that is the problem,
but I'm
Wow great find. AnimationTimer wasn't around when BrickBreaker was written
(somewhere in the JavaFX 1.0 timeframe iirc) and probably the author was
working around really bad performance at the time by trying to get the ball to
do less work!
I will take a look here in a second. I suspect there w
Taking a quick look at the code it seems that the animation time for ball
updates is fixed at 40ms using a Timeline with a single KeyFrame. So
25fps, half the refresh speed of any known desktop computer display.
brickbreaker/Config.java:40
public static final Duration ANIMATION_TIME = Duratio
Perhaps it is a windows issue. Does seem like a few of the people reporting
problems in this thread are on windows, and without those lovely high-res Mac
displays that make everything look so pretty. On my machine there is no way you
could say the jfx one is on par with the jscript one. I'd have
and high-performance
animations
on my computers then why can't JavaFX? The answers must be out there...
-jct
-Original Message-
From: Richard Bair [mailto:richard.b...@oracle.com]
Sent: Friday, 31 May 2013 01:12
To: John C. Turnbull
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Ja
Sorry, read the list out of order. Is Brick Breaker something that we
should concentrate on?
Steve
On 31/05/2013 7:26 AM, Scott Palmer wrote:
Speaking of poor animation in Ensemble...
Is anyone able to run Brick Breaker without choppy animation or poor
framerate performance on the ball?
Now
[mailto:richard.b...@oracle.com]
Sent: Friday, 31 May 2013 01:12
To: John C. Turnbull
Cc: openjfx-dev@openjdk.java.net
Subject: Re: JavaFX graphics performance and suitability for advanced
animations
Hi John,
Graphics? Yes, to a point. But my post was really about graphics and
the issues r
Have you tried to determine what the FPS is? My guess is that FPS is not
anywhere near the limit and it is the occasional stutter that is the problem,
but I'm not certain. Knowing that helps to point in which direction to go. The
fact that it runs pretty well on a PI is indication that it isn't
That JS example looks worse in Safari and Chrome than JavaFX on my system
(looks like pixel snapping is going on -- the border doesn't look fuzzy but the
animation is rough). You now know the parameters (you can either pixel snap, or
not). The question is how to determine that an animation is ha
avaFX? The answers must be out there...
-jct
-Original Message-
From: Richard Bair [mailto:richard.b...@oracle.com]
Sent: Friday, 31 May 2013 01:12
To: John C. Turnbull
Cc: openjfx-dev@openjdk.java.net
Subject: Re: JavaFX graphics performance and suitability for advanced
animations
Hi John,
&
Speaking of poor animation in Ensemble...
Is anyone able to run Brick Breaker without choppy animation or poor
framerate performance on the ball?
Now, I suspect the issue there is in the balls animation implementation in
the application rather than the JavaFX framework, as the bat moves smoothly
Here is pretty much the same animation in JavaScript of the animated box:
http://www.zenjava.com/demo/animate1.html
While it's not perfect, on my system (Google Chrome, Windows 7, Dell
Latitude E6520) the visual appearance is noticeably better than the JavaFX
one. For example there is no shimmerin
Thanks for the issues! As mentioned in RT-30830 and RT-30827, the jittery text
and fuzzy lines are two manifestations of the same thing. When animating, you
have two choices. Do you draw everything on pixel boundaries, or do you draw
"in the cracks" between the pixels? Of course the only way to
A little bit more esoteric, but some "not very nice looking" rendering when
animating a very lightly styled Node:
https://javafx-jira.kenai.com/browse/RT-30830
On Fri, May 31, 2013 at 12:07 PM, Daniel Zwolenski wrote:
> Jittery text when scaling in an animation:
> https://javafx-jira.kenai.com/
Jittery text when scaling in an animation:
https://javafx-jira.kenai.com/browse/RT-30827
On Fri, May 31, 2013 at 12:01 PM, Richard Bair wrote:
> Wow. Thanks!
>
> On May 30, 2013, at 6:48 PM, Daniel Zwolenski wrote:
>
> I have replicated the z-order problem with the Tower Defender game and the
>
Wow. Thanks!
On May 30, 2013, at 6:48 PM, Daniel Zwolenski wrote:
> I have replicated the z-order problem with the Tower Defender game and the
> Canvas: https://javafx-jira.kenai.com/browse/RT-30826
>
>
> On Fri, May 31, 2013 at 1:26 AM, Richard Bair wrote:
> Note this is only for Mac.
>
>
I have replicated the z-order problem with the Tower Defender game and the
Canvas: https://javafx-jira.kenai.com/browse/RT-30826
On Fri, May 31, 2013 at 1:26 AM, Richard Bair wrote:
> Note this is only for Mac.
>
> On May 30, 2013, at 7:54 AM, Richard Bair wrote:
>
> > Anybody interested in jit
Note this is only for Mac.
On May 30, 2013, at 7:54 AM, Richard Bair wrote:
> Anybody interested in jitter ought to look at
> https://javafx-jira.kenai.com/browse/RT-26702
>
> Richard
Hi John,
> Graphics? Yes, to a point. But my post was really about graphics and the
> issues related to performance. Again, unless those issues are resolved then
> it's not appropriate to state that JavaFX is suitable for "graphics".
You asked what the "full range of applications for which Jav
Anybody interested in jitter ought to look at
https://javafx-jira.kenai.com/browse/RT-26702
Richard
On May 29, 2013, at 5:18 PM, Richard Bair wrote:
>
>> As ever, just a suggestion. I'll leave it at that so we can get back to the
>> real issues.
>
>
> So, back to the real issues :-). Here
Hmm, there's no point to talk politics about platforms here I think.
And I don't think that we will go anywhere if we only say that Oracle does not
do enough, or that the performance is not enough, without being more specific.
Again we use swing (yes swing...) for complex graphic cockpit soft r
Hi Richard,
Thanks for the comprehensive reply. Responses inline.
>> 1. Can someone from Oracle please outline the full range of
>> applications for which JavaFX is or will be suitable for?
>
> That's a pretty broad question. Lots of stuff? At a minimum everything
Swing and SWT were used f
Another thing to consider is that you may get your port off the ground
and running a little faster by starting with a Canvas port since it is
closer to your Graphics2D code. But, that depends on how much picking
you were doing and/or animation and you'd have to manage your own
(partial or full
> As ever, just a suggestion. I'll leave it at that so we can get back to the
> real issues.
So, back to the real issues :-). Here is a good JIRA query:
https://javafx-jira.kenai.com/issues/?filter=12938&jql=project%20%3D%20RT%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20perfo
Ok, thanks.
As we have a lot of dynamic elements in our map overlay, I will post about
performance (compared to our swing based implementation, which is currently
rather good for us), as soon as we have finished our implementation.
Herve
Sent from my iPhone
On 29 mai 2013, at 19:59, Richard B
I would start with scene graph nodes and see how it goes. The Canvas should be
thought of as a nice utility for drawing images, rather than a hook into the
low-level drawing machinery.
Richard
On May 29, 2013, at 10:23 AM, Hervé Girod wrote:
> Hello,
>
> Concerning my previous question, is
Hello,
Concerning my previous question, is it planned to provide some kind of "shape "
drawing for JavaFX 8 in the graphic context, or is it safer to assume that the
scene graph will be the preferred way to handle this (apart from the svgpath
drawing of course)?
I have the same kind of questio
> If avoiding confusion is your goal, I'd suggest avoiding using performance as
> a synonym for fps. 'fps' seems like a pretty good term to use for 'fps' ;)
OK. I'll try to stick to "speed" and "jitter" (or one of its synonyms.
Using Android as an example, this is a good indication of how open the term
performance is in that space:
http://developer.android.com/training/best-performance.html
If avoiding confusion is your goal, I'd suggest avoiding using performance as a
synonym for fps. 'fps' seems like a pretty good t
On May 28, 2013, at 9:43 PM, Daniel Zwolenski wrote:
>> Lets use performance to mean fps, and choppiness to mean inconsistent
>> framerate. I think being consistent will help keep track of which issues are
>> affecting which manifestation of "visual crappiness" :-)
>
> I agree with having cle
>> Did we try turning cache to true and cache hint to SPEED?
>
> A simple game I wrote used some basic animation of about 50 nodes with
> effects applied to them (translucent, blur, sectioned viewports into a large
> Image) and without caching ran painfully slowly. Setting caching to true and
> Lets use performance to mean fps, and choppiness to mean inconsistent
> framerate. I think being consistent will help keep track of which issues are
> affecting which manifestation of "visual crappiness" :-)
I agree with having clear terminology. On that fromt performance to me (and to
many f
I've converted a large Swing based app to JavaFX... but unfortunately not
without issues.
I also much prefer the JavaFX APIs + scene graph. But I am forced when
testing with JavaFX 8 to use the software pipeline, and with JavaFX 2.2.x
(the only option we can ship with this year) I must used the J
No need to reply to this email (or this thread could rapidly get very long ;-)
The email is just a summary of some thoughts I had on performance.
Perhaps more wiki material than anything else.
---
> The biggest thing when doing performance work is identifying the benchmarks.
> Once we k
Thanks for your answer!
As for our experience, we are currently migrating a big UI application
(Java ARINC 661 Server: http://sourceforge.net/projects/j661/) from being
Swing-based to JavaFX based. We still keep the Swing compatibility, but we
found that using the JavaFX scene graph makes things
> Animations, particularly with text, were jerky and not real nice, with timing
> and smoothness issues.
I think this is still the case because of the fact that the text is pixel
snapped. Did we try turning cache to true and cache hint to SPEED?
> At this stage I don't think there's much point
Hi John,
> 1. Can someone from Oracle please outline the full range of
> applications for which JavaFX is or will be suitable for?
That's a pretty broad question. Lots of stuff? At a minimum everything Swing
and SWT were used for, as well as mobile and embedded UIs, rich media,
graphics,
I'm also very interested in the topic. I suspect many smoothness issues are
related to lack of pre caching, e.g. transition and animations lag when shown
the first time because of a lot of initial instantiation, lazy allocation, gpu
upload, tesselation, image caching etc. The smart resource cons
The Tower Defense game did go quiet. Partly this was because I was traveling up
until a couple of weeks ago.
But a bigger reason is because even in the very simple and limited
functionality we had we already hit some pretty serious issues. The canvas in
particular was doing really weird buffer
I have previously posed questions about the limits of performance that can
be expected with JavaFX and also the kind of applications for which it is
suitable.
In response to this and other questions from JavaFX developers a project was
created to develop a Tower Defence game in JavaFX. Has thi
75 matches
Mail list logo
