JavaFX performance for complex visualisations

[Will Hoover]

Not sure if it's relevant or not, but I've experimented with generating some
gauge graphics without using any external images (i.e. paths and the alike
are used). I knew going into it that this is not the optimal method for
doing this, but I wanted to see how well JavaFX performed under such
stresses. Again, I'm not sure if it's relevant to your gaming project, but
it may be of some use for testing the limits of drawing in JavaFX. Here is
some screenshots of the gauges (gauges under "Alarm Settings" and knobs
under "Positioning" are what I'm referring to):

http://www.ugate.org/screenshots.php

-----Original Message-----
From: openjfx-dev-bounces at openjdk.java.net
[mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski
Sent: Thursday, December 13, 2012 5:02 PM
To: Scott Palmer
Cc: <openjfx-dev at openjdk.java.net>
Subject: Re: JavaFX performance for complex visualisations

Somewhat related to this thread, I'd be interest in people's responses to
this forum post:
https://forums.oracle.com/forums/thread.jspa?threadID=2476169&tstart=0

Basically looking for some good design patterns on building these sorts of
diagrammatic applications. This will then feed back into Richard's game
project with the ultimate goal of testing performance and either showing
just what can be done with jfx or just as importantly highlighting to
Richard and crew where the problems are.

On that same note, there was a lot of enthusiastic comments about people
interested in contributing to this project but so far its been pretty light
on with only Jose and myself making any serious contributions. It would be
good to have more input, users and actual coders. We are getting close to
the stage where we need some more complex sprites (mine are currently blue
circles), either vector and flip-image style (we'd like to have both in
there), and I know quite a few of you wanted to test some specific things in
this area.

If you're interested in getting involved but don't know how, the two best
things to do would be to read through the issues list on the project (we are
kind of using this as a forum) or send me an email direct and I'll kick you
off - we can look at building up a bit of a JFX games mailing list too so as
not to spam this forum too much.

Cheers,
Dan








On Mon, Dec 10, 2012 at 2:31 AM, Scott Palmer <swpalmer at gmail.com> wrote:

> 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.h
> >> tml
> >>> * Site maps similar to this sort of thing:
> >> http://www.cegenvironmental.com/Services/Phase_II_ESA/Blueberry_Pro
> >> ces
> >> 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.
> >>>
> >>>
> >>
> >>
> >
>