We switched a vector editor which used swing to JavaFX (using a standard called ARINC 661), and we have no problems of performance in the Editor even for thousands of nodes. But I agree that you should not use the obvious Swing-converted way to do the same thing in JavaFX.
Hervé Sent from my iPhone On 24 juil. 2013, at 09:19, Daniel Zwolenski <zon...@gmail.com> wrote: > 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 >>>
