JavaFX graphics performance and suitability for advanced animations

John C. Turnbull ozemale at
Fri May 31 17:44:57 PDT 2013

Try SnagIt for screen shots.  It's really very good.


On 01/06/2013, at 10:24, Daniel Zwolenski <zonski at> 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.
> If I had to describe what I was seeing I would say that the movement of the
> box as a whole across the path is quite smooth, no jumping or skipping,
> etc.
> The visual bit that puts me off is that the border line visually appears to
> 'dim' and 'shimmer' slightly. I think perhaps it is the dimming that makes
> it the most noticeable, It's almost like the border has gone from black to
> a soft grey (which from the sounds of it, it is). Maybe it's as simple as
> the crack filling (or whatever) being just a shade darker or something.
> When the animation stops and turns around it jumps from grey to crisp black
> and this highlights the change. Possibly if this colour change transition
> was minimised it would be less noticeable, hard to say.
> The 'shimmering' is that the line gets ever so slightly  (but just enough
> to be noticeable) fatter at times, almost making it look like the line is
> wobbling. I wouldn't say this is pronounced but combined with the dimming
> the two affects just make it look on the amateur side of things.
> With the drop shadow, it's almost like the shadow is lagging a frame behind
> the shape. So on the way down, the shadow overlaps with the inside of the
> box. On the way up, the there is a small gap (or possibly solid gray) line
> or two of space between the box and the shadow. Perhaps this might be the
> smoothing of the border doubling up with the alpha of the drop shadow
> making it look solid. Just guessing though.
> 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
> outside being soft (typically where shadow is, etc)? I don't know.
> If I speed up the animation the problems are much less noticeable but
> that's probably just that the eye doesn't have time to process it all. If I
> slow down the animation (10 seconds) then the shimmer is still noticeable,
> and it may be my eyes playing tricks or just coincidence but it seems worse
> just for last few pixels before the animation ends and turns
> around. Interestingly on the JScript one at this speed the jerkiness is
> more noticeable - in line perhaps with your comments that there are
> trade-offs either way with the various options. It would be nice if we all
> had retina displays and didn't have to worry about this sort of stuff.
> Been staring at it too long though. It's hard to know what's perception and
> what's reality sometimes.
> Also, keep in mind that I'm on latop using it's monitor and traditionally
> these are not the nicest rendering - perhaps my symptoms are linked to that
> aspect too.
> On Sat, Jun 1, 2013 at 9:52 AM, Richard Bair <richard.bair at>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.). Hmmmm. I wonder if you used an 81pt font and scaled it down
>> what that would look like?
>> I'm curious on the animated box though as to what you are seeing that you
>> like. Is it pixel snapping but its moving fast enough that it looks OK? Or
>> is it that the AA algorithm is "better" for this case? If you did a screen
>> capture would it be high enough quality to show exactly what it is you see?
>> Richard
>> On May 31, 2013, at 4:26 PM, Daniel Zwolenski <zonski at> wrote:
>>> 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 seemed slightly less jumpy.
>>> On 01/06/2013, at 9:08 AM, Hervé Girod <herve.girod at> wrote:
>>>> 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
>> rather than using our outlines ;)
>>>> Sent from my iPad
>>>> On 1 juin 2013, at 00:43, Richard Bair <richard.bair at> wrote:
>>>>> 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 of stuff and a *lot* faster.
>>>>> On May 31, 2013, at 3:10 PM, Hervé Girod <herve.girod at>
>> wrote:
>>>>>> 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
>> letters seemed to move relatively to each other.
>>>>>> To avoid this effect, we used a TextLayout and cached the Strings
>> Layouts when they changed and draw their outline Shapes. With this method,
>> there was no Jitter at all. Perhaps this is the same case with the two
>> methods you mention with these Microsoft links.
>>>>>> Herve
>>>>>> Sent from my iPad
>>>>>> On 31 mai 2013, at 22:57, Richard Bair <richard.bair at>
>> wrote:
>>>>>>> Felipe found these links:
>>>>>>> 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 dedicated hardware, but I
>> thought it would be good for you to see what kind of options DirectWrite
>> provides (and to know that Felipe is working on the DirectWrite backend for
>> text rendering on Windows).
>>>>>>> Running the "Default" rendering method gives predictably crappy
>> looking animated text. Predictable in that MS is doing the same thing we
>> are by default -- focusing on producing crisp text. Their crappy might be
>> better or worse than our crappy, but in both cases it is crappy when
>> animated :-). The "Outlines" method is very nice (and much slower). I
>> couldn't run the A8 method on Parallels (it just didn't draw anything).
>>>>>>> Give a play and see what the native system is doing. We need some
>> kind of API (as linked in your JIRA issue) to allow you to easily pick
>> which method you want.
>>>>>>>> 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 a hard time convincing anyone to use jfx over even lowly jscript
>> using that incredibly basic showdown I put together.
>>>>>>> We have a mix of systems but I personally have only a Mac +
>> parallels (and when it comes to performance you really can't draw any
>> accurate conclusions when running in a VM).
>>>>>>>> How often do you personally run something like ensemble on windows?
>> It could be that we're seeing big issues and you're seeing minor ones,
>> hence out angst at how casually these issues are treated (two bugs I spent
>> hours narrowing down and reproducing got closed in around 10 minutes - was
>> the code run on the environment it was reported to be found on in this
>> time?). Might be worth you having an eyeball just to see.
>>>>>>> I know Kevin and Jonathan have Windows machines. But this is a good
>> point we need to make sure we run on a similar environment.
>>>>>>>> Regarding the Text vs Label thing, I'm not sure I get what that's
>> about. My primary use with animations is to do ipad like transitions of
>> rich widgets containing labels, buttons, tables, etc. So a panel of buttons
>> might slide in left, a document might get folded up and put in a rubbish
>> bin, or a dialog might grow out of a button that was clicked. Are you
>> saying smooth animations are not intended to be used on complex node graphs
>> like this?
>>>>>>> Usually when animating a page of stuff, the best way to get good
>> performance (on desktop and mobile) is to first set cache=true on the panel
>> being animated, animate the thing, and then turn cache=false on the panel.
>> In that case, you won't see any of these issues. But I think you are right
>> that Labeled things should have a setting to indicate the way they render
>> their text just like the Text node should.
>>>>>>>>> JS is driving tis animation and not CSS?
>>>>>>>> Is this a question about the HTML I put up? If so then the answer
>> is jquery is used to animate between a start css style and an end css style
>> (just view source on the HTML, it's about 10 lines of code). How it does
>> this you would have to look at jquery's animate method. I know as much
>> about it's internals as I do about JFX's.
>>>>>>> Right, my thought was whether the difference between what I see on
>> Mac vs. what you see on Windows is based on the browser engine (but I tried
>> chrome, so maybe not). When JS is driving the animation you often get
>> different performance / behavior than when CSS is driving it.
>>>>>>> Richard

More information about the openjfx-dev mailing list