Can JavaFX do CAD?

[Richard Bair]

> 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