Juce critics...?


#1

Hello all, and particulary Jules,

Your API is really welcome in music soft, of course, and many people thank you for your job. Im wondering of the limits of an API when developed by only one person, even skilled and genius this one is…

So I red it on a cycling74 forum :

Can answer to it ? How ?..
Sorry for this unfriendly post, but I think you have your word to say about it, and it can interest lots of people.

BR

[quote]There’s 2 separate but related problems in Max5 which shouldn’t be lumped into one.

The problems are: JUCE’s code, and MAX’s code.

1A) JUCE’s performance.

Some months back I was learning more about vector and wanted a firm grasp of all the operations, and so I put together a quick benchmark that runs through all of my documented vector operations in Qt and JUCE. Spitting all manner of shapes on screen, stacking xparent stuff up, spinning stuff around while zooming, messing with pens, etc. It was just a big ugly benchmark. But the results were astounding. In the best case scenarios-- a few tests, JUCE was only 15 times slower than Qt. But commonly JUCE was 100 times slower than Qt. 40 times slower was a good average. The varied numbers were also influenced by flipping Qt between software, opengl, and direct3d modes. But all in all, JUCE’s performance couldn’t be taken seriously. Measurement in CPU usage rather than framerates was equally horrid. With OpenGL, Qt would use 6% CPU for awesome vector stuff, effectively making my GPU do all the work, whereas JUCE doing the same thing would peg my core to 95%. Qt’s software rendering of vector is also devastatingly faster than JUCE.

And this is the foundation of the future of Max… Think about that for a moment.
What a wonderful executive move.

The day I benchmarked JUCE and Qt, I removed Max5 from my computer and haven’t worried about it since.

It was a moment of understanding, and I realized I could never come to accept Max5 with this knowledge in mind.

If Max5 was truly pushing the envelope, right on the edge of what’s even possible to do with our computers-- doing something amazing on computers just barely capable of keeping up with its demands, I’d be using it and loving it despite the flaw. But rather, the missed potential as a result of Cycling’s choices, is why I cannot use Max5. It was a huge letdown, something that could have been great.

If Cycling is interested in some CPP code to show how ridiculous JUCE is, I’ll provide it, but this is trivial for them to whip up.

1B) JUCE’s latency.

The way that JUCE works, is to complete its operations over a period of time. This is how JUCE works. JUCE ui’s are long pipelines. Regardless of how perfect Cycling codes up their end of the deal, JUCE still works with an inherent latency. That’s out of Cycling’s control unless we started seeing commits by them, and that shouldn’t be their job.

  1. Specifically addressing swieser1 and vuxivil’s point:
    Max 5’s code.

Cycling has coded Max5 in a way which is straightforward and clean to them, but which fails to introduce a lot of hack-code to avoid pegging JUCE. It’s ‘Solve the problem cleanly first, and then optimize later.’ The patch which vuxivil provided demonstrates Max5’s straightforward implementation.

If you look at a graphical system which has something like the composite pattern, or rather anything like a set of update dependencies / dependencies which can trigger other things to need rerender, it can sometimes be faster to just do it straight and let the fast graphics backend handle the cases of duplication, rather than chewing CPU time trying to avoid duplication. But this won’t work for Max5 because of its faulty foundation. JUCE’s weakness triggers a chain of events which ruins Max’s straight approach. And so Cycling will have to introduce more intelligence to try to avoid their vector toolkit, which is a sad state of affairs.

[Updated on: Tue, 21 October 2008 15:15][/quote]


#2

Well, when someone starts talking about benchmarks and doesn’t even mention whether they’re using a mac or PC, it’s hard to take it seriously. For all we know he might have been running it in debug mode, where you’d easily see a 50x slowdown in the speed of the pure c++ renderers.

And he’s probably talking about performance on the mac, which has always been worse than on windows, (but that’ll be much better in the new cocoa stuff). The bit about latency sounds like a load of bollocks IMHO.

Interestingly, if you search this forum, there was someone else who did some benchmarks and got some good results. Can’t remember if that compared with Qt, but I think it might have done.

Anyway, there’s always room for improvement! Historically, I wrote all the compositing functions as pure c++ because when I started all this, the OSes couldn’t actually do a lot of the alpha-transparency stuff that I needed. Then they added those functions but the performance was no good. But now that the OSes are finally providing some really good hardware-accelerated compositing ops, I’m thinking about rebuilding the graphics classes to take advantage of that.


#3

For some reason, I am usually fairly sensitive to that kind of thing. On Linux I tend to use XFCE over Gnome because I notice the very slight overhead, and I use VC2003 because the later versions are not as responsive. Again, a barely noticeable thing that for some reason annoys me to no end.

But I’ve never noticed stuff like that about JUCE. Might be a Mac issue?

I suppose there is a slight overhead in the broadcaster/listener model, but you’ll end up with some kind of indirection in all non-trivial software.
I can’t imagine the overhead being much more than with a normal event-dispatcher rig.
Unless he’s comparing it to the “naive” methods, like function pointer callbacks, or hard coding direct function calls. I mean, those are fast, for sure, but one false move and you are neck deep in spaghetti.


#4

Well Jules, thanks for playing fair with all that.


#5

Haha I just read this thread. It’s so funny :slight_smile: But I’m also rather keen to see the move to Cocoa finished. And I’ll be for sure testing it.

Interesting fact: QT’s Graphics View uses a BSP (Binary Space Partitioning) tree to provide very fast item discovery, and as a result of this, it can visualize large scenes in real-time, even with millions of items. Does JUCE also use a tree or does it check items linearly?

Jules, do you think that the move to Cocoa will also accelerate things on older machines, such as my lovely IBook G4, where the performance of JUCE was really not good ?


#6

It uses a BSP for 2D components? That sounds like overkill to me, unless you were writing some kind of crazy UI with many thousands of components.

Don’t know if cocoa will speed up on G4s, and I no longer have one to try. Would be interested to find out though. It certainly runs much better on intel.


#7

Well, if (like me dumbo) one does a midi sequencer and uses components for everything (notes, velocity, midi env points), it is well possible to have a few thousands of components on screen. I think it goes faster that one might first think, if one uses the component-for-everything-approach.

And why should it be overkill to use a tree? the insertion perhaps takes a little bit more time (who cares?), but then afterwards it is as fast as hell.

[quote]Don’t know if cocoa will speed up on G4s, and I no longer have one to try. Would be interested to find out though. It certainly runs much better on intel.[/quote]I’ll test that for you.


#8

Well, it’s only useful when you have thousands of sibling components - if you have thousands of comps nested inside various different parents, then it won’t help much.

And it only helps with finding the component at a particular point. How does z-order work? If the list isn’t sorted by z-order, you’d need to sort the whole thing every time you repaint. Or maintain two parallel lists, with all that extra overhead. Plus, every time a component moves, you’d need to do some nasty aglorithms to rebalance the tree… All sounds like more trouble than it’s worth!


#9

Wow, what a brain numbing thread that one was.


#10

[quote]It uses a BSP for 2D components? That sounds like overkill to me, unless you were writing some kind of crazy UI with many thousands of components.[/quote]Typically : MaxMSP-like soft. I know Juce doesnt present Itself as an API for it, but…