Site navigation

A program with 2160 components?

General JUCE discussion
#1

As you might know, I’ve been working on a lighting visualizer these days, something to let you see programmed lighting patterns before they g off, and it has been going well. Now suddenly someone has a system that needs work that has 2160 lights.

Now, they don’t have a visualizer already and aren’t expecting one, but I was curious to see if mine worked but :smiley: it didn’t (I wasn’t surprised).

I haven’t even looked into it yet, but overall I’m curious - if I did have a lot of independent subareas in my canvas, would it make a difference if I had 2160 components, or if I directly redrew into one large component and did the math myself?

I’m being very careful to never take and leave the MessageManagerLock once for each component - there’s only one MML per update, it wouldn’t work for 256 lights if it didn’t do that. But is there any other overhead that might make it worth getting rid of the individual components and painting them “by hand”?

#2

It should be able to cope with that sort of number without too much sweat, but judicious use of Component::setPaintingIsUnclipped() might help keep things rendering quickly.

#3

Put that in, no change, but I’ll definitely leave it there.

I’ll report back with progress, there might be numerous other reasons it doesn’t work!

#4

It turned out that there’s a bug in a library I use for C++ YAML decoding that somehow craps out on very long strings. I found some hardcoded numbers, but they’re for name lengths, and upping them considerably made no difference.

But I have code in there to split up the strings now if they’re too long, and it worked perfectly well on 2160 components…

So I tried it on 10,000 components (1x1 pixel with a 1 pixel spacing) and I managed to get about 2 frames per second.

So I tried it on 100,000 components and I get something like a frame every 7 seconds - but it doesn’t actually crash.

100,000 components - not bad.