JavaFX performance for complex visualisations

[Scott Palmer]

To be honest, I don't know if the presentation was done in Flash. The end result is MPEG4 video, not a Flash animation.  I would be happy if the *tools* used to create the presentation could easily be made using JavaFX. I think JavaFX could do the visualization with a small framework written in JavaFX.

Scott

On 2012-12-09, at 12:30 AM, "John C. Turnbull" <ozemale at ozemail.com.au> wrote:

> That looks very good Scott.
> 
> But just to put it out there, what *I'd* like to see is that the presentation at that link be developed in JavaFX instead of Flash as it is currently (not just the product it describes).  Why can't we do that?  Well, the first question is whether JavaFX is capable of supporting such a visualisation.  The second question is even if it was possible, how would it be developed without similar tools offered by Adobe Creative Suite?  We basically have Scene Builder at the moment which clearly isn't going to cut it.
> 
> -----Original Message-----
> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Scott Palmer
> Sent: Sunday, 9 December 2012 04:43
> To: Richard Bair
> Cc: openjfx-dev at openjdk.java.net
> Subject: Re: JavaFX performance for complex visualisations
> 
> That first link is very close to what I am doing now with JavaFX... and yes, the performance is below what I was hoping.  When there are many Paths performance drops substantially.
> Here's a link to info about our product:
> http://www.digitalrapids.com/en/Products/Kayak.aspx
> See Kayak Workflow Designer at 1:50 into the video.
> 
> Scott
> 
> 
> On Sat, Dec 8, 2012 at 11:55 AM, Richard Bair <richard.bair at oracle.com>wrote:
> 
>> I think the first link is a great example of something we should be 
>> able to do, and the kind of thing that I think you and Michael are 
>> saying doesn't work well right now. The second one actually is 
>> probably a lot easier now, because of Canvas. Basically, all the 
>> typographic background information isn't interactive, so you can 
>> render it once and use it as an image thereafter (with Canvas), 
>> whereas the first example has what I would guess would be a lot of interactive content.
>> 
>> Richard
>> 
>> On Dec 8, 2012, at 1:01 AM, Daniel Zwolenski <zonski at gmail.com> wrote:
>> 
>>> And just for reference, I had business cases to show:
>>> * P&IDs like these
>> http://www.creativeengineers.com/process-engineering/diagrams/pid.html
>>> * Site maps similar to this sort of thing:
>> http://www.cegenvironmental.com/Services/Phase_II_ESA/Blueberry_Proces
>> sing_Plant/topoDKWfsmall.gif
>>> 
>>> And to include zooming with LOD (i.e. more detail zoomed in, less 
>>> detail
>> at birds eye view), selective layering/highlighting (i.e. turn on/off 
>> different pipes or sections), hyperlinking and mouse overs, and 
>> markers/annotations (i.e. put a flag on the map, or a semi-transparent 
>> overlay over a "hot" section). No animations at least.
>>> 
>>> JFX wasn't up to the task performance wise as far as I could tell in
>> 2.0. We scaled back to just showing blurry images and putting a few 
>> markers (e.g. triangles/arrows/dots) on them but this was still quite 
>> slow but that could well have been the logic behind it (things got ugly).
>>> 
>>> This was for mining, chemical, manufacturing and general heavy
>> industries (not unlike the cargo unloading thing from JavaOne).
>>> 
>>> 
>>> 
>>> 
>>> On Sat, Dec 8, 2012 at 7:37 PM, Dr. Michael Paus <mp at jugs.org> wrote:
>>> Am 07.12.2012 21:20, schrieb Richard Bair:
>>> 
>>> Hi Michael,
>>> 
>>> According to my experience JavaFX is currently not able to handle
>> graphically intensive
>>> applications.
>>> Depends on what you are doing that is "graphically intense" -- if it 
>>> is
>> a lot of paths (thousands) then yes, this is slow. If it is a lot of 
>> images and lines and effects and such, then actually you can do a heck 
>> of a lot with FX (which is graphically intense!)
>>> This is of course true but tell me how far do you really get if you 
>>> only
>> have these elements available?
>>> You cannot even draw a simple filled triangle without creating a 
>>> path
>> and thus slowing down your application.
>>> A graphically intensive business application without paths seems to 
>>> be a
>> very specific corner case to me but
>>> maybe it is just me who feels so. What I have in mind when I talk 
>>> about
>> such applications are large diagrams,
>>> floor plans, vector maps with a lot of symbols on them and so on.
>>> If you're needing triangles, then you're in another class of 
>>> application
>> than the kind we've so far properly supported. Hopefully the 3D stuff 
>> will help bridge the gap.
>>> 
>>> (I've not seen triangles in use except in 3D programming which may
>> explain why I haven't considered that particular use case critical for 
>> our earlier releases, but hopefully we'll be able to handle your case 
>> properly now).
>>> Just to avoid some misunderstanding. I mentioned triangles only as 
>>> an
>> example for the most trivial geometry which cannot be
>>> created without using paths right now. In practice I have to create 
>>> more
>> complicated geometries of course.
>>> 
>>> 
>>> --
>>> 
>> ----------------------------------------------------------------------
>> ----------------
>>> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
>>> For more information visit www.jugs.de.
>>> 
>>> 
>> 
>> 
>