Somebody made a big mistake. They did not properly research the climate of available virtual machine technology of the 2003 timeframe. Even back then, we were well aware of Lua’s’ complete superiority.

JS spidermonkey and JS rhino virtual machines are irreclaimable. Their gluttonous memory consumption and slothlike performance will not be fixed.

Now Max/Msp’s great potential — a potential we looked forward for so long, is squandered. Max is not where it should be. This was so important. It was a critical mistake. Now we’re screwed for a long time.

I feel that I’m being very pragmatic about this. I’m not taking a hard-edge aggrandizing stance here. JSUI is simply a failure. It’s often easy for the creators, in this case, Cycling.. to ‘be holding the handle’ but not ‘inside the pot.’

Yes, us guys who are inside the pot.. if you heard what actually goes on in our small talks, our unvoiced frustrations. It’s just sad. “Well couldn’t you do it with JSUI?” , “Ah man…” Yes, there are fleeting moments of innocent hope. They’re quickly shattered.

Because JSUI is unusably slow. It destroys your CPU, it stabs your music. There is nothing you can do.

LUA is completely superior.

Superior in every possible way to Javascript. There is no justification you can come up with for a reason why we’d ever want Javascript, besides, “well, some web developers know it.” And that reason isn’t even real. Anybody who really wants to do something with Max’s_amazing_new_LuaUi will have no problem getting into Lua very quickly. The “PiL” (Programming In Lua) book is orthogonal to Max/Msp’s set of tutorials and help patchers. It’s definitive and highly accessible for both programmers and non-programmers alike.

If we take a look at some respectable language benchmarks of LUA vs JS for a variety of algorithms,
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=lua&lang2=javascript
We’ll see such things as, oh,
Lua being 8.6 times faster,
Javascript using 163 times more memory,
Lua being 5.7 times faster,
Javascript using 77 times more memory,
Or, in the case of LuaJit (http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=luajit&lang2=javascript), oh,
LuaJit being 30 times faster,
Javascript using 138 times more memory,
LuaJit being 15 times faster,
Ad nauseum.

Lua is an incredible little VM. It’s fast and lightweight. It’s easily embeddable with luabind or tolua++. It’s sandboxed. It’s so tiny that you can just spawn off VM’s right and left if you like.

Cycling.
Listen up.
It’s not too late.
CUT YOUR LOSSES.
JSUI has only been in Max for a few point releases. People aren’t too attached. Max 5 is your chance to say:
Oh, well we made a little booboo.

We really want something that works and uses 2% cpu.
Come on.

- Invect

Invect, without verifying your claims I’d like to say thanks for formulating your beliefs/frustrations in a comprehensive way to the MaxMSP community.

I must add that I see no problem at all in having lua -and- js available in Max.

Also check this: http://www.cycling74.com/forums/index.php?t=msg&goto=109151&rid=3579&S=acc90b750e6e7cee871bcc3602c197a9

my 2 cents
Mattijs

> what about using jit.gl.lua in a jit.pwindow?

It works, but an integrated solution would be much nicer imo. 2 issues with this workaround that come to mind:

- you can’t know when to update your window, so you’re always updating even though your pwindow might not be visible at the time.

- there is no equivalent to jitter listener in jit.gl.lua. afaik. You have to manually connect the mouse events of the window to jit.gl.lua

I totally agree with Invect. I’ve tried to do serious UI design in both JSUI and JS+gl.sketch+pwindow. The latter being an order of magnitude faster obviously.

In my last attempt (multilayer sequencer and curve editor) I wasted a lot of time only to end up with an unscalable and slow 3000+ lines Javascript file that is now useless to me.

If I could go back I’d now probably do the whole thing in C++ but that kind of defeats the idea of using Max for me. I’d end up with something more like a standalone app rather than dynamic and reusable Max components.

Since the arrival of Lua support in Max I’ve been investigating several ways to design a UI library to be used with jit.gl.lua, but I fear I might not have the time or the experience to come up with a sustainable solution on my own.

If Lua ever will be fully integrated with Max, similar to Javascript is now (UI design + Pattr support), I’d be an extremely happy person.

My 2 cents,

Thijs

I’ve been down a similar road. (Though not 3000 lines.. ;-)

I integrated a semi-complicated data structure visualization with
JSUI. It looked really nice, but as you said was quite slow. Also,
the visualization in question was intended to go inside a bpatcher,
and it turns out JSUI doesn’t play very well with this, often drawing
outside the bpatcher boundaries.

I’m actually at the moment creating an LCD-based alternative, which is
working fine, though not as pretty. We’re still using Javascript for
other tasks.

I never figured out if it’s the javascript itself or just the JSUI
stuff that is slow. I get the impression is the latter, but would
need to find some way to test it.

Steve

Anthony

> I’m actually at the moment creating an LCD-based alternative, which is
> working fine, though not as pretty. We’re still using Javascript for
> other tasks.
>
> I never figured out if it’s the javascript itself or just the JSUI
> stuff that is slow. I get the impression is the latter, but would
> need to find some way to test it.

Btw, if you disable FSAA (full scene anti-aliasing), JSUI drawing
code is 2-4x faster.

Lua’s a great language and we’re looking at easier ways for anyone to
make language bindings. So, no need to ditch JS. Btw, the Tamarin VM
which is slated for the next version of the SpiderMonkey JS
implementation is significantly faster. Personally, if speed/memory
is the utmost concern, I’d drop down to C.

-Joshua

JKC,
You’ve already said it on this forum 20 times.
We know.

Today while doing research, I read the standard “jkc-antialiasing-signature” at least 10 times.

Come on.

Not true!

listener = jit.listener(this.drawto, callbackfunc);

wes

>
> I am so sick of seeing you reply to every single person about
> disabling antialiasing for “2 to 4x” speed benefit.
> It’s as if it somehow allows you to slink away from the issue.
> EVERY TIME.

Sorry, but some people don’t read the archives, and/or forget this
fact. The reason that JSUI is slow is that it uses a software based
OpenGL renderer, and uses 4x multi-sampling if fsaa is enabled (which
it is by default). Switching to lua with this same means of rendering
will not make much performance difference as the bottleneck is in the
drawing. In this case it’s not a language perf issue. If you want to
make things faster, use js+jit.gl.sketch, or jit.gl.lua with
jit.pwindow, which is HW accelerated.

As for Lua vs. JS VM performance comparisons. Of course you’re right.
There are a number of reasons why JS was chosen, and why we’re
committed to it as a supported scripting language in Max. With
Tamarin, the VM performance discrepancy between Lua and JS will not
be such an issue.

I appreciate your frustration, but there is nothing preventing you or
other people from integrating Lua into Max. In fact two people, have
already have done this. There’s no need to be impolite.

Thanks,
Joshua

Yes, making a lua extern takes just a few hours of work with luabind. I’ve done so. But the key issue here is something else.

Sketch is great. jit.gl.sketch + jit.gl.pwindow works well in the mostly-monolithic scenario. While I have no issues pushing towards eight sketches, it doesn’t work out for atomic.

With Sketch, I would not create a whole set of building block UI components to use everywhere and love. I use Sketch for centerpiece UI’s. Not for lego-bricks.

Atomicity is what JSUI is supposed to be able to do.
And that’s where it fails too.
It’s too slow for that.

So really, there is no use-case for JSUI:
We don’t want it for atomic, (watch everything freeze up completely.)(hear your music die)
And we don’t want it for what Sketch does.

I am driving at a stronger point here.
A powerful, fast, take-it-for-granted-that-it-just-works-fundamental-essential-building-block-of-the-whole-entire-MAX-idea,
A way of building UI components to go inside of Max,
Perfectly. As a core-feature of Max,
is so important.
It’s the basics, man.
It baffles me how Cycling has placed such little importance on getting this right,
and allows JSUI to remain a failure.
The need is so obvious.

- Invect

On 10/4/07, Zola wrote:
>
> Joshua,
>
> Yes, making a lua extern takes just a few hours of work with luabind. I’ve done so. But the key issue here is something else.
>
> Sketch is great. jit.gl.sketch + jit.gl.pwindow works well in the mostly-monolithic scenario. While I have no issues pushing towards eight sketches, it doesn’t work out for atomic.
>
> With Sketch, I would not create a whole set of building block UI components to use everywhere and love. I use Sketch for centerpiece UI’s. Not for lego-bricks.
>
> Atomicity is what JSUI is supposed to be able to do.
> And that’s where it fails too.
> It’s too slow for that.
>
> So really, there is no use-case for JSUI:
> We don’t want it for atomic, (watch everything freeze up completely.)(hear your music die)
> And we don’t want it for what Sketch does.
>
> I am driving at a stronger point here.
> A powerful, fast, take-it-for-granted-that-it-just-works-fundamental-essential-building-block-of-the-whole-entire-MAX-idea,
> A way of building UI components to go inside of Max,
> Perfectly. As a core-feature of Max,
> is so important.
> It’s the basics, man.
> It baffles me how Cycling has placed such little importance on getting this right,
> and allows JSUI to remain a failure.
> The need is so obvious.
>
> – Invect
>

> Sketch is great. jit.gl.sketch + jit.gl.pwindow works well in the
> mostly-monolithic scenario. While I have no issues pushing towards
> eight sketches, it doesn’t work out for atomic.

You might find jitter-gui-sliderexample.pat useful for your purposes.
Similar strategies could be used in jit.gl.lua, and are also expose
with the Java Jitter binding.

-Joshua

Ack. I can never edit my posts.
jit.pwindow

> Zola full of lightning?

Completely :)

-Joshua

> LUA is completely superior.
>
—————————————————-

I love it, if for no other reason than the Lua sibling of jsui could be called lui-lui.

mz

> Lua’s a great language and we’re looking at easier ways for anyone to
> make language bindings. So, no need to ditch JS. Btw, the Tamarin VM
> which is slated for the next version of the SpiderMonkey JS
> implementation is significantly faster. Personally, if speed/memory

Tamarin will not be fast.
We already know that.
The deal is done.
If you are reserving some future hope that Tamarin will come in and save the day,
No chance.
If you would like proof of that fact,
Your proof will only come when you read-back on my forum posting in 3 years from now, and Tamarin has solved nothing.
Fundamentally it is impossible for Tamarin to ever be fast.
Please check here:

http://ejohn.org/apps/js-speed/results/

Notice how Tamarin is ~20% faster than SpiderMonkey.
20% is not significantly faster.
It’s not an order of magnitude faster like Lua,
or using 150 times less memory, like Lua.
LuaJIT can be 10 to 40 times faster.

Tamarin is a big bloated piece of Junk with a huge codebase. Major KLOCage goes into concerns WEB SECURITY ISSUES.
It’s complete bullshit for Max/Msp.

From wikipedia:
“
__What Tamarin is not__

Adobe contributed code for its virtual machine and the JIT compiler. The JavaScript compiler (the program generating bytecode from JavaScript source code) was not contributed as part of Tamarin. The contributed code will be integrated with SpiderMonkey to produce a complete JavaScript engine.

Tamarin is not the same as Adobe’s Flash player, which remains closed source. The virtual machine is only a part of the Flash player, and will be a part of future versions of Mozilla/Firefox.
“

It’s not a micro-VM like Lua is.
And that’s what something like Max needs.

Javascript is worth giving up on.
Let’s see Max/Msp become amazing.
Remove the things which stand in your way.

- Invect

> It’s not a micro-VM like Lua is.
> And that’s what something like Max needs.

No argument.

> Javascript is worth giving up on.

Won’t happen.

It’s not an either or question.

-Joshua

Aha! *NOW* i understand why JSUI is slow. ;-)
It has nothing to do with the FSAA per-say.. this software-based
rendering is of course going to be slow. Surely it might be
eventually possible to drop-in a more efficient renderer that takes
advantage of the operating system facilities for OpenGL? (Maybe this
is planned, sorry I haven’t read about the upcoming version yet..)

By the way I don’t share Zola’s opinion here. I think JavaScript is
actually quite a decent language. As for speed of execution, I pretty
much always expect interpreted languages to be slow and never expect
to use them in time-critical tasks. This is what C is for.

I never did understand why the JSUI stuff seemed slower than need be,
but I didn’t realized it was completely software rendered… (thus..
defeating the purpose of using OpenGL?? Though I’m sure it made it
easier to implement.)

Steve

> Not true!

> listener = jit.listener(this.drawto, callbackfunc);

Oops my bad! Don’t know how I missed that one…

Thijs

wes

On 10/4/07, Thijs Koerselman wrote:
>
> >> – there is no equivalent to jitter listener in jit.gl.lua. afaik. You have to manually connect the mouse events of the window to jit.gl.lua
>
> > Not true!
>
> > listener = jit.listener(this.drawto, callbackfunc);
>
> Oops my bad! Don’t know how I missed that one…
>
> Thijs
>

>
> Aha! *NOW* i understand why JSUI is slow. ;-)
> It has nothing to do with the FSAA per-say.. this software-based
> rendering is of course going to be slow.

Btw, I don’t think it should be much slower than the LCD you are
using if you set fsaa to zero (which is why I mentioned that old
tidbit again). As for drop in alternate renderers, you can relatively
easily change Sketch to jit.gl.sketch with jit.pwindow for HW
accelerated OpenGL with similar JS code.

-Joshua

I also investigated using JSUI for my UI, largely to make use of the better antialiased text and easy scaling/resizing. My display requirements (and thus my internal drawing overhead) are actually very simple.

What killed the deal for me seems to be the overhead involved in passing messages from Max into JSUI. I’m dealing with a fairly dense stream of input messages in some situations, and JSUI required an order of magnitude more CPU time than LCD for the same task when I prototyped using both. Yes, FSAA was off.

If anything could be done about that overhead, I’d certainly look at JSUI again. Alternately, an OpenGL-based native version of LCD that accepts the equivalent OpenGL commands as Max messages would be most welcome, and possibly more future-proof(?). In Max, not Jitter. But maybe that’s not possible?