Can JavaFX do CAD?
John C. Turnbull
ozemale at ozemail.com.au
Fri Jul 26 05:20:15 PDT 2013
Back on topic, I think the original question posed in this thread really
needs an answer.
I have previously asked about the capabilities of JavaFX for non-trivial
uses and don't believe that this issue is at all resolved. For a toolkit
which was first released 6 years ago, there is a remarkable lack of examples
of anything even slightly complex.
So again I ask, exactly what kinds of applications is JavaFX suitable for?
Richard has stated that he believes it is suitable for a wide range of
applications including complex visualisations and yet I still haven't seen
*any* JavaFX app even as complex as a simple Flash greeting card.
Where can I see such a card written in JavaFX with perhaps a dancing,
singing cat? Has *anyone* actually gotten non-trivial animations to work?
Even if no one in the community has developed such examples, I state again
that Oracle simply has to include something non-trivial either in Ensemble
or as a downloadable demo. At the moment we have Ensemble only and let's
face it the animation examples in there basically show that it is possible
to move a small red circle from one side of the screen to the other and not
much else. Further, from my experience, it is not possible to even do that
with jitter.
The Tower Defender demo project seems to have died and unfortunately before
it really answered the question.
I seem to remember Angela Caicedo had a demo of a pin ball machine some time
ago that I would have liked to have a play with but it never made it into
the wild as far as I know. Maybe it didn't perform very well? Why else
would such a sample *not* be available?
Is there *anyone* out there that can point me to a non-trivial example of a
JavaFX application that demonstrates complex animations or graphics in
general? Does *anyone* (Oracle included) even *know* that such an
application is actually possible?
For Flash, there are literally millions of examples of
fancy/complex/impressive graphics and animations out there that can be
really impressive at times. I have not seen ONE such example in JavaFX!
THIS IS A MAJOR PROBLEM!
-jct
-----Original Message-----
From: openjfx-dev-bounces at openjdk.java.net
[mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski
Sent: Friday, 26 July 2013 15:14
To: Richard Bair
Cc: openjfx-dev at openjdk.java.net
Subject: Re: Can JavaFX do CAD?
I think you guys need to change the topic here - nothing to do with CAD
anymore (which is still an unresolved topic).
On Fri, Jul 26, 2013 at 3:03 PM, Richard Bair
<richard.bair at oracle.com>wrote:
> Actually Jasper and Scott just pointed out some problems here. I
> mistyped (should have been return _x; from the getter). But also I
> didn't handle the case of binding, or setting via the property
> correctly here. So this modified pattern doesn't work. I may be
> remembering it wrong and Alex can correct me.
>
> Richard
>
> On Jul 25, 2013, at 9:21 AM, Richard Bair <richard.bair at oracle.com> wrote:
>
> >> Regarding memory requirements of the "full lazy" properties, let me
> state the obvious:
> >> - if the property is not used at all, we have a reference and a
> >> double
> instead of just a reference (worse unless in bucket)
> >> - if getters/setters are called, we still have a reference and a
> >> double
> instead of full instantiated property (better)
> >> - if a listener is added, we have instantiated property and a
> >> double
> instead of just the property (slightly worse)
> >> So it looks like it would make best sense to introduce this for
> properties that are often get/set but usually don't have listeners on
them.
> I'm not sure if such set exists and can be identified.
> >
> > Thanks Pavel, this is a good summary. Alex K. and I were looking at
> > a
> pattern for this once and he had another way to do it which was
> different than what I had done in the past. The pattern I used to use
> was something like this:
> >
> > private double _x;
> > private DoubleProperty x;
> >
> > public final void setX(double value) {
> > if (x == null) {
> > _x = value;
> > } else {
> > x.set(value);
> > }
> >
> > public final double getX() {
> > return x == null ? _x : x.get();
> > }
> >
> > public final DoubleProperty xProperty() {
> > if (x == null) x = new DoubleProperty(this, "x", _x);
> > return x;
> > }
> >
> > instead it could be done like this which results in faster getters
> (because you never have to delegate to another method), an almost
> immeasurably slower setter, and slightly little less code:
> >
> > private double _x;
> > private DoubleProperty x;
> >
> > public final void setX(double value) {
> > _x = value;
> > if (x != null) x.set(value);
> > }
> >
> > public final double getX() {
> > return x;
> > }
> >
> > public final DoubleProperty xProperty() {
> > if (x == null) x = new DoubleProperty(this, "x", _x);
> > return x;
> > }
> >
> >
> > The idea here is to always set the local field, so that we can
> > always
> just return the value immediately in the getter. Where I think this
> may make a difference is on the smaller end systems (mobile /
> embedded) because from previous analysis we saw that none of our
> getters were getting inlined
> -- we actually paid the price of each method call overhead, because
> since we were reading from the property objects and the property
> objects were a couple methods worth of work for each getter call, the
> VM wouldn't inline the generated code into the call sites. By using
> this pattern in places that are commonly read, we would probably get
> these getters all inlined again and avoid all the method call overhead
entirely.
> >
> > Richard
>
>
More information about the openjfx-dev
mailing list