RUBY: Droplist selector uses massive CPU when copied

[Spogg]

Another step!

If I make 3 copies I get high cpu. BUT, if I change to the topmost front panel view, the cpu drops to zero. See the attached.

This doesn’t further my understanding really, but it’s interesting to find. I made some similar tests using other Ruby-based modules but I don’t get the same behaviour. I can have many Ruby knobs or keyboards inside a module but the static cpu doesn’t increase when I view them.

Cheers

Spogg

[Spogg]

Maybe the final step…

I tested this in the current X64 and 32 bit beta versions of Flowstone and there is no problem. CPU usage is “zero” for all situations.

So, while I honestly don’t understand what’s going on, it’ll be gone in the forthcoming Flowstone 4 release.

Like tulamide said, there has been Ruby development for the next version, so my conclusion must be that the issue relates somehow to the createDropList method, since that’s the only thing unique to this module.

So it’s back to my actual fun project now

Thanks for all the input guys.

Spogg

[tulamide]

This is what I'm referring to.

spoggissue.png (15.24 KiB) Viewed 15459 times

But the two lines above it also doesn't belong into a drawing method, since they create anarray from a string and evaluate one of the created values. That's all time consuming, when several redraws take place. The method is called "draw" for a reason

[Spogg]

Thank you SO much tulamide!
I do believe I actually understand this now

I’ve re-worked the RubyEdit and all seems well now, but maybe you or someone else could have a look to see if there’s anything else stupid remaining.

This has been a great learning experience for me so, again, thanks to all for joining in.

Spogg

[tulamide]

Nicely done
I couldn't spot any more issues from the code. There is still a good part of optimization possible, but nothing drastically. For example, you could define all the pens and brushes as class instance variables in the init method. This will save a little bit cpu load, but more importantly doesn't claim and release so much memory. Instead of doing it per draw call, it is only done once at the beginning. This will reduce the load to the gc (garbage collector), that has to take care of releasing classes and variables that aren't used anymore, which is a time consuming process.

For your understanding:
a = 2 + 4 -> gc gets notified about a variable referring to 6
...some time passes
gc checks if variable is still in use. If not, it will release the memory asociated with the it.
Let's assume 'a' is still alive, as this code is executed:
a = "Word"
gc gets notified that 'a' now references a string. It marks '6' as to be released and at the next collection process it will be released.

In the real code the pens and brushes are assigned to a variable everytime a drawing takes place. Each time also the gc is informed about the variables pointing to a newly created class, which makes it mandatory to release the memory of the previous classes, that are now not needed anymore. The more redraws, the more work for the gc. With my proposal this relation is broken, since all variables will point to one place in memory each, which won't ever change through runtime = no work for the gc = saved a lot of time.

[Spogg]

Fascinating!

I’ve not tried to implement this but it leads me to a question:

If a brush or pen colour is changed external to the RubyEdit (as in my example) would this be picked up if it had been defined in the init method?

I understood the init method was only called at start-up, or when there was a change in the code.In a RubyEdit which is fixed at the design stage, I can see the idea working well. But my aim was to have a generic droplist, whereby I could use Properties in a module to configure the visuals.

Maybe I’m missing something (as usual).

Cheers

Spogg

[tulamide]

It doesn't matter if you get the colors from external or internal links.

What matters is, if you plan to change colors during runtime of the plugin. In short, if you give the user of your plugin access to the color settings. In that case it needs dynamic assignment. But fear not: Most pens and brushes can be defined once as explained, and their color changed later on, without creating a new class instance. Even the color of a color class can be changed without creating a new instance. Most of that infor however is the result of long sessions where I looked at the classes, Malc created and their instance methods. A lot of them were not described in the user guide. However, some of them are now described in the user guide, so that guide again is very informative read

A much better way for color management, btw., is to use my ACM. That tool allows you to setup and group as many colors as you wish (complete with color wheel, different models like RGB, HSV or Hexcolor, and easy copy or overwrite handling) all on the top layer of your schematic, while you just plug a little receiver wherever you need access to the colors. When publishing the plugin finally, you just remove the central managemant module. All the receivers keep their last selected color.

[Spogg]

Got it!

Thanks again tulamide

Cheers

Spogg