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 >
