Can JavaFX do CAD?

[Daniel Zwolenski]

+1

I've failed to convince multiple clients that they should use JFX because
of
a) lack of examples of what it can really do, and how to make it do that
(e.g. in enterprise space we have
http://static.springsource.org/docs/petclinic.html)
b) lack of any big or notable players out there actually using it, or at
least publicly saying they are using it
c) the deployment hassles vs the ease of html app deployment and the true
cross-platform-ness of html

After actually getting one client to trust me on it and use it on a real,
commercial app (startup), I hit problems with performance (broad
interpretation of the term, not 'framerate'), crippling deployment and auto
updating issues, missing basic features (e.g. maximise button, coming in
2014 I believe?), unpredictability of CSS styling, and a lack of best
practices for things like how to do CAD-like diagrams (not so much render
performance but zooming, panning, mouse input, layering, dragging, etc).

Like John, I've been guilty of letting my frustration show in these forums.
Like John, it's because I want so badly for JavaFX to be the platform I
develop on, it has the potential to be awesome, but things (that seem
obvious and small to me) completely stop it from being usable in a real
world situation for me.

It's not that we think the JFX team aren't slogging their guts out, clearly
you are. It's just that in some key areas, there are small-ish blocks that
stop the whole rocket from launching. To then see a whole lot of effort be
poured into things like binary CSS/FXML compilation, Pi platform support
(that's more important than iOS/Android, really?), web deployment patches,
or even 3D (as cool as that is), just knocks me about. Obviously your
priorities are coming from somewhere different to ours, but the way you
prioritise is unfathomable to me and that definitely adds to the
frustration.

At this stage, I am not suggesting my clients use JFX (I actively
discourage them from it, in their interest). Mobile is the area that has
the potential to bring JFX back into usable for me as it can compete easier
with the current technologies (which are all crap). Maybe if that ends up
working (a long, long road to go on that and very much an 'if') then it
will seep back into the desktop for me, but at a minimum the desktop
deployment options will need to be improved before that's even a
possibility.

I've come to accept that I am not in the primary target audience for
JavaFX, maybe a secondary target. I don't understand who the primary target
is though, and knowing/accepting doesn't make it any less frustrating. I
keep involved in the hope that I might get a usable platform somewhere
along the way but it's more of a hope than a belief.

So nothing really new above, but just adding my voice to John's. JavaFX is
definitely not production ready for me, my clients and the types of apps I
build (e.g. consumer facing online systems, enterprise/backoffice systems,
form/data systems, diagramming systems). One day I hope it will be, but
it's moving extremely slowly or not at all in the areas that would make it
so for me. Meanwhile the competitors (primarily JavaScript based solutions)
are improving rapidly in the areas where they have traditionally been weak.



On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull <ozemale at ozemail.com.au>wrote:

> Hi Richard,
>
> I have to stop posting late at night, that one came across as really ANGRY!
>
> It's not anger, it's passion... and frustration.
>
> I am frustrated because I spend much of my day trying to convince my
> employer that we should be using JavaFX.  They ask me questions like:
>
> "What happens if Oracle abandons JavaFX just like Sun did with JMF, Java3D,
> JOGL etc. ?"
>
> I say:
>
> "This is Oracle, not Sun."
>
> They say:
>
> "Can you show me what JavaFX can do? There must be examples out there
> right?"
>
> And I say:
>
> "Sure, here's Ensemble."
>
> They say:
>
> "OK, so it has a nice set of basic controls and can do simple animations
> but
> what about more complex things like Flash?"
>
> ...hence the dancing cat reference.
>
> It's not that my employer *needs* dancing cats, it's just that they need to
> see that there is more to JavaFX than red circle transitions.  I can't even
> prove to them that JavaFX is capable of dancing cats.  They don't have the
> resources to fund me to develop something more sophisticated but they tell
> me that if JavaFX truly was a "mature" technology (like I tell them) then
> where are all the examples?
>
> I am finding it difficult to convince them that JavaFX is production ready
> and is not still in "experimental" mode because I am unable to demonstrate
> its true capabilities or refer them to many examples of people (and I mean
> big companies) actually using it.
>
> The main concerns of my employer and I think many companies in a similar
> situation is that JavaFX won't survive long term and that it is only really
> suitable for form based applications.  Then of course there is the whole
> "HTML5 runs on all platforms" argument but that's another story...
>
> So this is why I think it's imperative that Oracle invests in developing a
> true showcase application for JavaFX.  Something that non-technical people
> (like managers who make decisions about where the money goes) can look at
> it
> and go "wow!".
>
> I am just not getting my managers to go "wow" at what I can show them with
> JavaFX at the moment.
>
> Every comment or apparent criticism I post about JavaFX is from the
> perspective that I am trying to deal with real-world problems and people
> who
> require proof (such as demos, reference sites etc.) and not because I
> myself
> think JavaFX is not up to scratch.
>
> It's quite the opposite actually.
>
> I am a very, very strong believer and supporter of JavaFX and have many
> reasons both personal and professional as to why I want it to be a massive
> success.  As I have said before, there are plenty of people who praise
> JavaFX and tend to avoid the very real issues that are restricting its
> adoption.  I just think we have to face these issues head on if we are to
> compete in what is a very cut-throat industry.
>
> -jct
>
> -----Original Message-----
> From: Richard Bair [mailto:richard.bair at oracle.com]
> Sent: Saturday, 27 July 2013 01:40
> To: John C. Turnbull
> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net
> Subject: Re: Can JavaFX do CAD?
>
> > 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!
>
> Point to one?
>
> Have you seen any of the JavaOne examples? The movie wall or movies on a
> stack of 3D cubes was pretty good. But I guess you're not interested in the
> 3D aspect? What is it you are looking for exactly? Different people (on
> this
> list) have had different perceptions on both (a) what's important and (b)
> what kind of graphics they're interested in. Most people would deride the
> dancing cat as being totally irrelevant to the types of applications
> they're
> trying to build (the basis for much of flash animations is shape morphing,
> you can find some code here https://gist.github.com/gontard/5029764).
>
> On the other hand, JavaFX is not a replacement for OpenGL. Drawing 25
> million lines is just not something we can do right now, especially in a
> resource constrained environment. I've already commented on the memory
> overhead (which would continue to be an issue even if the drawing part of
> the problem were solved).
>
> I've pushed to graphics repo the StretchyGrid, which is about 300k line
> nodes (the actual amount is variable, see the javadoc comments). At 300k
> nodes the scene graph overhead is negligible on the FX side, dirty opts is
> taking a long time to run, and painting is really slow.
>
> PULSE: 347 [122ms:222ms]
> T12 (8 +0ms): CSS Pass
> T12 (8 +0ms): Layout Pass
> T12 (47 +53ms): Waiting for previous rendering
> T12 (100 +1ms): Copy state to render graph
> T10 (101 +16ms): Dirty Opts Computed
> T10 (117 +105ms): Painted
> Counters:
>         Nodes rendered: 306565
>         Nodes visited during render: 306565
>
> If I were doing this by hand in open GL, I think the drawing would be
> essentially free, if I used LINES with GL anti-aliasing, I could send 'em
> all down to the card in a single shot (and if I had a modern GL I could do
> LINES + FXAA or one of the other per-pixel AA algorithms available and it
> would turn out pretty nice). Because our shapes don't implement the non-AA
> path, and our AA involves software rasterization and uploading of pixels, I
> expect that to be the main source of the 105ms time being spent here.
>
> Also I noticed (by turning on prism.showdirty=true) that the entire grid is
> being painted every time, even though visually it looks like only a small
> subset actually needs to be changed. But that's really a minor thing, as I
> said, drawing this many lines should basically be free if I configure
> "smooth" to false in the app. Except that right now it is totally not
> implemented (in NGShape):
>
>     public void setAntialiased(boolean aa) {
>         // We don't support aliased shapes at this time
>     }
>
> The point of stretchy grid is not to say "wow look at this amazing demo".
> The point is to say "what happens if I put in 300K nodes. Where does the
> system start to fall over?".
>
> Richard=
>
>