[General] King of Lively part II : LIE and CHEAT
Dan.Ingalls at Sun.com
Wed Nov 11 22:06:17 CET 2009
Peter Fraser <pfraser at spatialmedia.com> wrote...
>IMO, the *Java* version of Lively is the fast route to a universal,
>fast, tight platform. Such a platform is a prerequisite for an active
>Where has the Java work got to?
Peter, and all -
This is great. This is just the kind of thinking we need to do now.
Just to let you know, this is exactly where our thinking was a year
ago. We got everything running on top of the JavaFX scene graph.
This allowed us to run all the regular LK demos, but in addition Java
(Swing) UI components in Lively windows (or not) and, hey, even a
midi player to hook up to the PianoKeyboard. It ran at about the
same speed, though, because it was still all going through (our
experiment with direct calls on the graphics and demonstrated
something like a 4x speedup -- I think we ran over 100 bouncing
ellipses before slowing down to the normal speed for 25. What a
great strategy - runs everywhere on the Open Web, and runs much
faster and ties into Enterprise libraries on the Sun platform.
Alas, this strategy competed with another strategy and our project
got cancelled :-(
But it's 11 months later and people realize ours might have been good
after all ;-)
Now to your topics...
>Did I really say "Lively isn't ready for the prime time"? I immediately
>regretted pushing send. It is close and beautiful, and packs more power
>into the browser than anything else -but the prime time is unforgiving
>and insists that if you are going to play the browser game, you have to
>play it well. This means supporting four browsers on all the platforms
>those browser run on. Lively could do it, (though it's thankless task
>that never ends) but doesn't do four browsers now. And (yawn yawn) we
>need more speed, and can't rely on Moore's Law.
>To me, the way forward is obvious: Focus on the Java implementation,
>doing whatever it takes (meaning writing tactical Java) to make Lively
>as slick, responsive and consistent as it will be when browsers get
>their act together.
>I'm NOT talking about switching to Java. I'm talking about building, in
>Java, the kind of future-browser that Lively is anticipating. Lie and
>cheat unabashedly. If Rhino isn't performing (and let's not forget Da
>Vinci etc) then resort to Java. If (say) SVG doesn't offer a decent RGB
>interface, add it. If SVG is too slow, revert to Java graphics. Lie and
>cheat -but be sure to have a browser implementation on hand lest you be
I agree about this. There are actually two ways to pull this off right now.
One is to take what Krzysztof did for the ellipses demo, and carry it
through to the full Morphic graphics layer. The nice thing is that
(with a couple days' work ;-) the result could be wrapped up
as a Java Applet, and thus run in any browser where Java is available.
This would cover just about everything, including our current big
handicap, Internet Explorer. This is the strategy I mentioned above ;-).
The other is to use the 2D canvas in O3D. This is a very attractive
bundle since it includes not only a directly accessible canvas
Of course these are both plugin solutions, but I think the LK story
remains clean as long as there is a full Open Web version that
remains reasonably compatible.
>If Lively in the browser works, great -but let users know that Java
>will give them a better user experience today, especially for complex
>worlds, and serious Lively hacking. The Internet Explorer problem goes
>away(ish), and Sun research has a (better than) ringside view of the
>[Aside: Silverlight would be an alternative to Java, but I'm assuming
>that Sun/Oracle remain involved and people continue to fret about their
>air supply. If Flash suddenly got a compliler on the client, it too
>would make a nice Lively incubator. ]
Yes, yes, and yes. I think we're on the same page.
>More metaphors: I'm aware that the project worked with Java for a while
>but encountered too much intrinsic complexity. I propose that Java be
>considered *microcode*. The problem with the browser as computer, is
>that you can't microcode it. When you hit a wall, there are no options.
>Even Mozilla starts to feel like proprietary software.
Actually, complexity was not the problem. It's just that we felt an
Open Web solution would get us much more traction.
>My sense would be to implement HTML Canvas in "jmicrocode" (if a
>implementation doesn't exist already). Canvas feels to me like a better
>lively substrate than SVG, and doing Canvas in Java (oops -jmicrocode)
>feels better to me than adapting to another graphics api (eg scene graph
>etc) in Lively JS directly.
>Tell me I'm wrong (it's good for me).
You and Krazy Kat, huh? ;-)
Well, the Canvas port does exist - check it out in Safari, FireFox or Chrome at
You can tell it's the real thing by evaluating
WorldMorph.current().showDamageRectangles = true
every damaged rectangle on the canvas. [Of course it runs slower doing this]
So, the step to a Java applet or O3D is not that all hard to contemplate ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lively-kernel