Geertjan's Blog

  • January 28, 2009

JavaFX vs. Visual Library

Geertjan Wielenga
Product Manager
Yesterday I published an article about integrating JavaFX with the NetBeans Platform:


I think there are many use cases where using JavaFX on the NetBeans Platform would make sense, because it simplifies aspects of Swing coding.

What I'm wondering is, maybe it would be cool to clarify exactly how the NetBeans Visual Library differs from JavaFX. Obviously there are differences, but what are they concretely?

E.g., some random brainstorming:

  • JavaFX is focused on animation, effects, i.e., Flash-like behavior.
  • Visual Library is focused on modeling/representing/viewing data.
  • Visual Library is a widget library, each widget comes with predefined/customizable properties.
  • Visual Library integrates with NetBeans Platform idioms, such as Nodes and Explorer Views.
  • JavaFX has no special relationship with the NetBeans Platform, currently needs to be bolted on, same way as must currently be done for any Swing application.

They're very different, though both focused on graphic concerns.

To me, the million dollar question is: could JavaFX be integrated with the Visual Library? E.g., you'd use one of the widgets from the Visual Library and then add JavaFX juice for providing animations and special effects to that widget?

Join the discussion

Comments ( 6 )
  • Thomas Wuerthinger Wednesday, January 28, 2009

    I guess the other way round would be easier: Make some of the visual library utilities (e.g. graph layout) available in JavaFX.

  • Cormac Wednesday, January 28, 2009

    I think JavaFX will take over, for me mainly because of the ability to add animations and SVG support. But the visual library does a lot of smart thing that I would miss. The different layers as you zoom in and out (Never got to use this feature but I wanted to). ConnectionWidget functionality. If these could be added to JavaFX, that would be amazing.

  • Michael Mann Wednesday, January 28, 2009

    I do have a need to use the capabilities of VisualLib2.0. However, I am concerned about the continued support for the library. I do like the idea of incorporating JavaFX effects into a Widget for all kinds of special effects for various domains. The more I have created a "WOW" factor into any desktop applications I build, the psychological effect to my clients is one of a more robust, mature, and polished product. I actually have engineers that want to use the Netbean's tool we are creating just to enjoy having a "software latte" experience.

  • Mark Wednesday, January 28, 2009

    Geertjan, great post. I've been wondering about this myself. I'm currently using Netbeans Visual Library outside of the Netbeans RCP. The main concern for me is Performacne: I am using it to visualize VERY large graphs (100's of nodes are common, with a few over 1000). As of now, I don't believe the Visual Library does any type of 'view culling' (ie don't draw stuff that can't be seen. I may be wrong, I haven't examined the source).

    So, how is JavaFX performance? How would Visual Library from JavaFX perform?

  • Fabrizio Giudici Wednesday, January 28, 2009

    Mark, at the moment I didn't try the VL with a huge number of objects, but I believe it does visual culling. Look at the demos: there's one devoted to a scene with a large number of widgets at different scales and I believe it demonstrates that widgets out of scale, and possibly out of sight, are not rendered.

    Back to Geertjan's question, it's an extremely interesting subject and I'm thinking about it since a long time. I think I've got a clear idea about the answer, even though I didn't look into details. IMHO SG and VL stay at two different layers, SG being more low-level and focused to rendering (let's not forget that it gets hardware acceleration) and visual cuteness, the VL adding a lot of facilities for quickly doing things such as pop up menus, status management (selection), connection management and routing. I've personally developed a very simple specialization, named NodeGraph (blogging soon) which is a subclass of GraphScene<Node>, which is extermely powerful. SG is just not so high level, and it's not its purpose. So the perfect match would be the VisualLibrary 3.0 whose low-level rendering engine is made on SceneGraph.

    I think it will be not easy to get it soon. First, JavaFX has to consolidate and to be available on Linux. Second, I've got to better figure out the licensing stuff, even though I believe SceneGraph is already GPL+CPE.

    There is room for some partial, but interesting, integration in the middle term. For instance, I've been always interested in having VL with some sort of hardware acceleration support - I was thinking e.g. to some cool animation effects that software such as Apple Aperture does (let's remember I'm using the VL for rendering photos on a "light table"). The idea could be: use the VL as is for normal operations, where you interact with only a widget at a time and performance is ok. When you have to run an animation, create a SG on the fly with a capture of the rendering for each widget; switch the view to the SG; perform any kind of fancy animation (during an animation usually you don't interact with widgets, so SG is enough) and when the animation is over switch back to the VL where widgets have been placed in the final position, so you have interactivity back.

    In all these discussions, let's remember that the single limitation of a certain degree of VL is that it doesn't support rotation of widgets (but I think it's doable with some tweaking).

  • softwarevisualization Thursday, February 19, 2009


    SG is definitely not GP + CPE. Joshy just posted on this subject. The way it goes is, SG is GPL with NO CPE and the SG inside FX is not permitted for use outside of FX.

    I also read from Chris Campbell that the long term goal of FX in relation to Swing is to have them be interoperable in the sense of being able to use FX from a Swing app and use Swing from an FX ap (which you can do now).

    The landscape for the rough category of "cool rendering" is getting quite populated. There's NB VL, SG, FX (and its separate SG which is not the GPLed SG project) and all the fine work that was done in the Filthy Rich Clients with the animation framework. Also, there's stuff in SwingX . Whew!

    The most basic distinction in this rendering work is - is the library what's called retained mode or is it immediate mode? Scene graphs are retained mode, meaning, they "remember" what objects are to be drawn and what positions / rotations / sizes and visibility.

    Immediate mode graphics are described as drawn and forgotten; the program has no recollection of what was drawn where.

    If you think about Swing, actually, it's retained mode. It's a scenegraph of sorts. You just declare that a JPanel contains a JButton and specify the layout then Swing makes sure that relationship holds throughout the life of the program.

    Advanced Swing programmers who dig into the rendering of Swing components and override paintComponent()and cusmtomize the Graphics object are dealing with immediate mode rendering.

    Going a little further in this thought exercise, programmers who customize the LAF through "approved" channels like Synth are programming the same way you program using JavaFX- it's the declarative control of the contents of a scene graph, that scene graph being Swing.

    Given all that, I think of the relationship between the two types like this- scene graphs are higher level abstractions that have the benefit of saving the programmer from having to maintain the spatial relationships between the components at the potential cost of having access to all the possible rendering a graphics object is capable of restricted to whatever the scene graph author chooses to expose through the scene graph API.

    In theory, you can always go "behind" the scene graph's back, get a hold of the graphic object as we do in Swing and have at it. I am not sure if the details of the scene graph permit that or not or even if they can control whether that kind of thing is doable or not.

    So thinking now about the integration of SG and VL, if VL are widgets in the same way Swing components are, we can imagine them being animated (rendered) under the control of scenegraph and at the same time rendered by their own paint() routines like any Swing component.

    How would that actually work out in the real world? Dunno!

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.