JavaFX graphics performance and suitability for advanced animations

[Daniel Zwolenski]

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 oracle.com>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 gmail.com> 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 gmail.com> 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 oracle.com> 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 gmail.com>
> 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 oracle.com>
> wrote:
> >>>>
> >>>>> 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 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
> >>>
>
>