Comments on: Performance: improving insertion times

By: Pedro Duque Vieira

Pedro Duque Vieira — Tue, 22 Sep 2009 16:48:46 +0000

Richard,

Can you tell us when will the embedding of javafx in java be available? Will it be on the next release?

Why doesn’t the JavaFX team simply make JXScene (blogged on Josh Marinnaci blog) an official API?

Having some decisions to make and some openness on JavaFX would be greatly appreciated.

Thanks a lot!

By: Noel Grandin

Noel Grandin — Tue, 22 Sep 2009 14:39:02 +0000

Surely you can supply an API for batch inserts – then the checks can be done once per batch instead of for every object.

That does push the responsibility to the client programmer, but sometimes that is the easiest answer

By: Richard

Richard — Fri, 18 Sep 2009 15:26:04 +0000

Yes, nearly. A childless/leaf node might also be used as a clip on some node, so you have to make sure that it also doesn’t have a clip parent. For example, I could do:

var r:Rectangle = Rectangle { clip: r }

By: Hans

Hans — Fri, 18 Sep 2009 11:16:02 +0000

One remark on the circularity check: if child has no children there can be no circularity, can there? So you could use that to speed it up?

Cheers, Hans

By: Pedro Duque Vieira

Pedro Duque Vieira — Thu, 17 Sep 2009 11:11:29 +0000

That’s nice Richard!

I’m really looking forward for that to become available.

I think javafx is awesome, it would be a tremendous waste not to make it available to existing swing developers who want to spice up their apps.

Thanks.

By: Richard

Richard — Wed, 16 Sep 2009 14:43:00 +0000

The main reason we’ve not released a supported method for embedding fx into an existing swing app is that there is not yet a nice way to call from java directly to javafx. Emphasis on the word “yet”.

Cheers!

By: Pedro Duque Vieira

Pedro Duque Vieira — Wed, 16 Sep 2009 11:22:06 +0000

Sadly, I’m in the middle of giving up javafx, after some months of commitment and working hours.
There are still no news of an official way to embed javafx on java which is a main killer point for me and I expect a lot other developers. But on the contrary there are some guesses that the next release will make it even more difficult/impossible for that to happen.
All those improvements are good but they are not targeting the main issues.
Sorry for being so negative, just my view on things.

By: Tbee

Tbee — Wed, 16 Sep 2009 07:06:41 +0000

Another option, since you are working closely with the compiler guys, is splitting up the insert and the check in special methods.

So there is the “official insert” that does “insert” + “check”.
And there is the “dangerous insert” that only does “insert”.

Since insert is a special keyword, the compiler guys could route that keyword to “dangerous insert” and call “check” just before the next time the group is used inside the block (directly or as a parameter) or when exiting the block. This way you keep the check close to where the magic is happening instead of getting an error completely else.

An challenge is how to deal with non local groups (instance variables).

We could also do both approaches: insert does not check, check at the block boundary or first usage AND check when reading. A boolean “dirty” could be used to mark if checking is required.

By: Richard

Richard — Wed, 16 Sep 2009 03:50:06 +0000

Hey Osvaldo, thanks for the comments (and voting is always allowed and appreciated!). There isn't any gain by cutting out the circularity check in terms of download or loading time -- its one function:

    package function wouldCreateCycle(parent:Node, child:Node): Boolean {
        var n: Node = parent;
        while (n != child) {
            if (n.parent != null) {
                n = n.parent;
            } else if (n.clipParent != null) {
                n = n.clipParent;
            } else {
                return false;
            }
        }
        true
    }

By: Osvaldo Pinali Doederlein

Osvaldo Pinali Doederlein — Wed, 16 Sep 2009 01:28:48 +0000

Great stuff. But if I could vote, I’d raise both hands for “giving developers / designers all kinds of rope” – I can use this rope to hang myself, but I can also use a strong, simple, cheap piece of rope to do lift pretty heavy stuff, without paying the cost of a high-tech hydraulic elevator. And perhaps that’s just my lack of experience programming scene graphs (JavaFX is my first), but circularity seems the kind of Awesome Stupidity bug that I’d never expect the average developer to do with any significant frequency. (As for designers, they are supposed to use visual tools like CS4 or the upcoming Designer Tool, so many structural errors can be made impossible, or validated, by the tool.)

Idea: have such high-level validations conditionally compiled (or enabled through the assertion mechanism), so they are only active in the SDK for debugging/testing purpose (and even there with a option to disable), but absent in the end-user runtimes. Cutting this stuff out of the runtime would also remove some download and loading-time overhead. Right now JavaFX has worse deployment story than competing RIA toolkits, it’s perhaps the Achilles heel of all Java-based desktop technologies, so the last thing we need is extra bloat that serves only to prevent people from shooting their own feet.