I think the below comment makes it sound more straight forward than it is. In building a diagramming tool there is much more to it than just the rendering frame rate.
This topic about CAD-like apps and 'performant' highly visual jfx apps in general has been raised here and in the forums before, without any clear resolution. Chris, the closest we've come to an answer is that it certainly isn't straight forward to do and there are many areas where the intuitive solution (especially for us ex-swing devs) gives results that are horribly unusable. There *might* be a way to get jfx to do this but there's no clear guidelines on how to achieve a 'performant' result. This is why I +1'd your question and added areas I feel need clarification from the jfx team. Unfortunately I'm not entirely sure they know the answers themselves and it generally comes back as a 'you try it and let us know how it goes'. The last time we raised a similar topic it led to an attempt to build a Tower Defender game (led by Richard) in order to 'see how it goes', which revealed some pretty significant problems and the game quickly stalled as a result. Having built a prototype floor plan tool in JFX2 before I can say it did not go smoothly. The things I've listed as wanting best practices for are all areas where I struggled to make jfx achieve decent results in terms of responsiveness, animation speed/smoothness, rendering quality and simplicity and cleanliness of code. The one area where I'd say it did hold up well (as far as I could tell) was frame rate but that didn't help me at all and I doubt would be much consolation for you after you make the massive effort needed to convert your app. On 24/07/2013, at 4:29 PM, Joseph Andresen <joseph.andre...@oracle.com> wrote: > I believe JavaFx could do cad, first step would be to provide a simple data > set and boil it down to the best render paths in JavaFX. > > As far as I know it shouldn't be any worse than swing with the slowest render > paths. > > -Joe > > On Jul 23, 2013, at 8:47 AM, Chris Gay <chris.gay5...@gmail.com> wrote: > >> Hello all. >> >> Please could someone advise if it is even feasible for me to consider >> re-factoring the following Swing application, so that it becomes a JavaFX >> one. From trying to read about JavaFX, I get the feeling that Oracle never >> intended Java FX for the purpose I need. >> >> I have a large Java Swing desktop CAD application which makes heavy use of >> the Java 2D API, and concurrency. It is a Menu Bar driven application, with >> a Toolbar for Tools, and a few buttons, but 99% of the user activity >> concerns selecting and manipulating vector graphical objects in a >> traditional manner using one Tool at a time (think Inkscape or LibreOffice >> Drawing apps). The application has multiple drawings open at the same time >> (but only one is visible), and each Drawing contains it's own Drawing and >> Processing threads (in addition to sharing the Main and Event Threads), >> which keeps the Event Thread lively. Each Drawing contains an ArrayList, >> acting as a Display List of all graphical objects, and each graphical object >> can be a tree structure. In many cases I use simple iteration instead of >> Iterators, simply for speed, and to avoid garbage. The graphical objects are >> lightweight, in that they do not carry references to events and handlers. >> All they carry is their basic geometric data and properties, a bounding box >> which they can lend as Read Only, and a boolean flag to indicate selection, >> which means there can be millions of the objects, with a minimum memory >> footprint. To support them, there are many hundreds of methods, which the >> tools interact with. There can be multiple Drawing Windows active on a >> single drawing, where each Window is backed up by an offscreen image, which >> handles the zoom and sliding buffer behaviour for fast scrolling, to allow >> rapid bit-blt's to the actual window. Lastly, the user manipulates the >> Drawing (Display List), using one of many Tools, where the active Tool >> receives events from the event queue, and then manipulates selected and/or >> unselected graphical objects, by using XOR Mode graphics onto the offscreen >> buffer, generally using callbacks. >> >> The system is fast and very responsive on large data sets, but what I do not >> know is whether JavaFX will help me make a better implementation, or whether >> it will fight me all the way. With JavaFX claiming hardware acceleration, I >> do not understand whether it depends on transferring the very large data >> sets into graphics hardware to render, and what happens if the hardware >> cannot cope. So far, I have found little in the way of discussions that help >> me get a mental picture of how JavaFX is intended to work. Should I stick >> with Swing? >> >> Regards, >> >> Chris >>
