JavaFX performance for complex visualisations

Scott Palmer swpalmer at gmail.com
Sat Dec 8 09:43:01 PST 2012


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_Processing_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.
> >
> >
>
>


More information about the openjfx-dev mailing list