I would start with scene graph nodes and see how it goes. The Canvas should be thought of as a nice utility for drawing images, rather than a hook into the low-level drawing machinery.
Richard On May 29, 2013, at 10:23 AM, Hervé Girod <herve.gi...@gmail.com> wrote: > Hello, > > Concerning my previous question, is it planned to provide some kind of "shape > " drawing for JavaFX 8 in the graphic context, or is it safer to assume that > the scene graph will be the preferred way to handle this (apart from the > svgpath drawing of course)? > > I have the same kind of question about attributed strings which are handled > using the TextFlow node in JavaFX 8, but for which there is no direct way to > handle them in the canvas graphic context. > > We are currently trying to draw complex and animated map overlays in JavaFX. > > We did that drawing directly in the graphic context in swing, and we assumed > that it was safe to use the JavaFX canvas graphic context to do the same > thing, but are now not so sure that its the right way to handle it. I'm not > talking about the current JavaFX 2.2 API, but rather what you are planning > for Java FX 8. > > Herve > > Sent from my iPhone > > On 29 mai 2013, at 02:40, Herve Girod <herve.gi...@gmail.com> wrote: > >> Thanks for your answer! >> >> As for our experience, we are currently migrating a big UI application (Java >> ARINC 661 Server: http://sourceforge.net/projects/j661/) from being >> Swing-based to JavaFX based. We still keep the Swing compatibility, but we >> found that using the JavaFX scene graph makes things MUCH more simple for >> us. And in our very preliminary tests it does seem that our performance is >> good (the application is almost completely ported and working, but several >> of our custom widgets implementations still have to be implemented in >> JavaFX, so we don't have direct comparisons yet). >> >> However, as you talk about the scene graph / the canvas API, I have a >> question. We are mostly rendering controls and Shapes (exactly what JavaFX >> scene graph is about), but we also have to render Map overlays (with >> waypoints, flight plans, etc...). We used to do it by overriding the >> paintComponent method of a custom Component in our Swing implementation, >> dealing directly with the Graphics2D Layer. The "natural" path for us with >> JavaFX would be to use the Canvas widget, and GraphicContext, but reading >> your answer, I begin to suspect that we could maybe achieve a better >> performance with a simpler architecture by using directly the scenegraph for >> that too. What do you think? >> >> Herve >> >> >> 2013/5/29 Richard Bair <richard.b...@oracle.com> >> Hi John, >> >> > 1. Can someone from Oracle please outline the full range of >> > applications for which JavaFX is or will be suitable for? >> >> That's a pretty broad question. Lots of stuff? At a minimum everything Swing >> and SWT were used for, as well as mobile and embedded UIs, rich media, >> graphics, etc. I don't expect somebody to write Halo 5 with it. >> >> > 2. Is there something inherent in the JavaFX architecture (such as >> > CPU/GPU interaction, the performance of the JVM or the Java language >> > itself) >> > that limits its suitability and thus effectiveness in advanced >> > animations/visualisations? >> >> Absolutely not, in fact, quite the opposite. The basic architecture >> (threading model, GPU usage model, etc) is designed for high concurrency and >> throughput. Some of the features in Controls though (like CSS lookup, color >> derivation, etc) put a tax on performance. When it wasn't exposed in the >> API, every design decision is made with performance as a for most thought. >> When it comes to API usability is considered primarily but performance is >> also always considered (along with security). And for every feature that >> adds weight, there is a way to avoid it when absolutely necessary. >> >> > 3. Is this choppiness and lack of smoothness I have experienced >> > typical of JavaFX performance or is it some issue with my >> > environment/drivers etc.? >> >> Hard to say. I saw a couple weeks ago a machine where scrolling the table >> view was 14fps whereas it was 320fps for me. The difference was the other >> system was falling back to the software pipeline. To determine what you're >> seeing, we need to know whether what you're running is producing >> consistently slow results or erratic results. Also, we need to know whether >> you are render bound or compute bound. What's taking so long to complete? >> >> We have seen situations where we are preparing a frame but never rendering >> it, which might also be contributing to the choppiness. >> >> > 4. Is JavaFX more targeted at form-based UIs rather than high >> > performance graphics? >> >> No. >> >> > 5. Do you have any other comments on JavaFX and its suitability for >> > advanced animations and visualizations? >> >> The biggest issue at present architecturally is that we don't expose any way >> for you to *really* draw without the scene graph. The Canvas gets you >> partway there, but ultimately that guy is still just buffering up drawing >> commands and issuing them later against a texture, rather than allowing you >> to go directly down to OpenGL. So that's a feature that is missing that is >> going to impact some people. >> >> Instead, you have to do everything with the scene graph which in more >> advanced scenarios means a huge scene graph and tons of memory. >> >> We're still making a lot of progress on the raw performance side. We had an >> embedded hack-fest a couple weeks ago in which performance on desktop went >> from 320-800+fps on table view scrolling, which in large measure came down >> to reducing the number of state switches on the graphics card (and the >> resulting decrease in the number of OpenGL calls). >> >> However choppiness is often the culprit in perceived performance rather than >> actual fps. >> >> One thing you can try is to run your application with >> -Djavafx.pulseLogger=true and analyze the output. This records the amount of >> time spent in various phases of the pulse, the number of dirty nodes >> processed per frame, etc. One thing I saw a couple weeks back, for instance, >> was that if more than 15 nodes are dirty (or is it 12?) then we punt on >> determining the dirty region and accumulate the entire parent. This is a >> heuristic used to trade off figuring out how big the dirty area is against >> just drawing it -- sometimes it is cheaper to do the former, sometimes the >> latter. >> >> Also each individual dirty region probably comes with some overhead in terms >> of setup for each render pass (each unique dirty area ends up getting its >> own render pass), and this fixed cost has not been analyzed and perhaps >> needs to be factored in to our determination of the number of dirty regions >> we support, or the heuristic in any case. >> >> Are your slow examples reproducible? If so we need the test case. Is there >> an issue filed? We can't fix things we can't reproduce. We spend a >> *considerable* amount of time and energy on performance and for the things >> we're measuring we're doing well. As the saying goes "what's measured, >> improves". After the switch to gradle and the new project layout, one thing >> I'm going to look at is using JMH[2] in OpenJFX so we can write micro >> benchmarks and have them easy for everybody to run and contribute to. Our >> current set of micro benchmarks are based on the predecessor of JMH which >> was the JRockit benchmark suite and was proprietary (hence we cannot just >> open source our existing benchmarks without doing some rewrite). >> >> [1] Attributed to Peter Drucker >> http://blog.johnrchildress.com/2012/06/05/key-business-metrics-and-milestones/ >> [2] >> http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/ >>
