Canvas rendering issues / Text Transition rendering issues

[Daniel Zwolenski]

Thanks for the feedback guys. Very helpful!

I just did a quick test, changing the Labels to Text nodes and it has fixed
the sudden jump at the end for the font transitions. I'm curious as to the
fundamental difference between these two classes: why do we have both, what
are their strengths and weaknesses and how are we as consumers of the API
meant to know when to use what? The JavaDoc doesn't provide any kind of
semantic clues to this that I can see.

In this simple example we are only animating in some text but eventually
I'd like to be able to animate in the whole toolbox and menu's etc. These
will be more complicated aggregations of nodes (i.e. Panels containing lots
of Labels and buttons etc all part of a layout manager) and I'd like to be
able to skew and slide and grow all these. Label would be the
normal/logical choice for such controls, and there's no real alternative to
things like Buttons' etc (except for rolling my own clickable Text nodes).
What's the best strategy for creating animation friendly Panes containing
complicated controls?

The change to Text hasn't fixed the jitter of the initial scaling-in of the
text. It almost looks like a rounding error, like it's trying to find the
best font size nearest the scale that it should be at and that's causing it
to jump around a bit. Not sure though, just a thought.

Layouts are used in all cases. The general approach is to use Layouts to
position all the nodes in their 'final position' (so the title text is
centered in a VBox for example) and then use Transitions that first offset
the node from that position (to off screen, for example) and then gradually
reduce the offset until it is zero, meaning the Node moves back to it's
natural/preferred position as determined by the layout. I'm open to other
suggestions on this.

Regarding the Vector based enemies, this code was contributed by Jose and
I'm not as familiar with it's internals. Looks like he's just joined the
conversation so I'll let him comment on this. I have run into similar
changing-bounds problems before though and it does seem a little
odd/limiting to not to be able to just set a fixed size on a Group (or have
some alternate node to use) and then the children just get clipped to this
and their layout and bounds are always relative to a well defined area.

To clear up my earlier email, the Canvas problems I mentioned are all only
visible in the "grass" level. This is the only Canvas in the entire app
currently, and all these other issues are non-canvas related (as most of
you worked out :) ).

Cheers,
Dan





On Thu, Jan 3, 2013 at 1:07 PM, Jim Graham <james.graham at oracle.com> wrote:

> I noticed that the path-based Vector enemies jump around a bit.  I'm
> wondering if this could be due to the bounds of the enemy shifting around
> as the electric lines are added.  Note that you use a stroked Path with its
> default decorations which I believe means miter joins which can have spikes
> in their contributions to bounds when you turn tight corners, so as the
> last triangular segment is randomly generated the angle of that last corner
> to the end before the path is closed can shoot out a miter of arbitrary
> length.
>
> Try using a round or bevel join instead - both of which will have faster
> and more stable bounds computations anyway which can avoid some per-frame
> overhead.  Round would be the most stable choice for bounds, but bevel
> would be the fastest to render.  Another technique for making the bounds
> stable is to include an element that pads the bounds of your group beyond
> the most outlying "jittery" element.  For example, including a transparent
> rectangle whose bounds exceed the circle by enough to encompass the spiking
> of the miter joins or the tiny variations in the bevel joins would smooth
> out the stability of the bounds.  The bounds with round joins will always
> be fairly stable since they always have a constant stroke extension
> distance from the outermost points of a path...
>
>                         ...jim
>