MouseOver bug

[tulamide]

(I'm assuming, though I don't know, that mouse moves will use more CPU depending on the size of the gui area)

That's not the case. The only thing that affects CPU load is the amount of the mouse messages. If your mouse sends 500 signals per second, Flowstone gets 500 mouse messages. Also, this is a one time factor. Once it is enabled somewhere, all system's move messages are evaluated. It doesn't change with the number of modules (where it is activated) nor the size of a panel.

But why? Might as well enable it for the entire project if you're going to force that. And as I mentioned, the odd thing is that it works fine if you enable front panel without placing an actual MGUI object, so why can't it work with the MGUI?

It does. It just makes it an option, while without a mgui it is always on and send through.

I would hope it doesn't affect performance... I agree it can be bothersome at times, but others it makes things far simpler. If I have 10 different elements in one small chunk of interface, and I want to move all of that together on the top-level GUI, it's far easier to just click and drag it as one object. Also I have two big chunks of my GUI synced, which makes things much easier since I don't have to make every single change twice and make sure they're exactly the same. Also there's purportedly a feature added in the latest release that lets you move individual elements wrapped in another MGUI from the top level.

It shouldn't affect performance. Technically, everything you see on your monitor is one big bitmap, composed of other bitmaps from running applications, widgets, etc.. The same is true for Flowstone. Everything you see on the top front panel is one bitmap. The difference from having no layer and drawing everything to the topmost panel, or having, say, 4 different modules is just the creation of additional 4 bitmaps, which is done at a speed that is neglectable (keyword "bit blit").

But thanks to Exo we know that modules itself, no matter their content, affect performance. So it is still advisable to not nest them too deep. Keep it at 2 or 3 layers and you're safe.

[Perfect Human Interface]

(I'm assuming, though I don't know, that mouse moves will use more CPU depending on the size of the gui area)

That's not the case. The only thing that affects CPU load is the amount of the mouse messages. If your mouse sends 500 signals per second, Flowstone gets 500 mouse messages. Also, this is a one time factor. Once it is enabled somewhere, all system's move messages are evaluated. It doesn't change with the number of modules (where it is activated) nor the size of a panel.

OK, this is the key here! I need to understand this correctly though. From the way you're describing it, it would seem I really could just enable mouse moves on the top level for the whole project and it would be no difference in performance compared to just enabling it for one knob or something. Is that true? My assumption was that, at least, it would only eat CPU when the mouse was over the given area, meaning it would do so less if it was only a small section compared to the entire GUI.

But thanks to Exo we know that modules itself, no matter their content, affect performance. So it is still advisable to not nest them too deep. Keep it at 2 or 3 layers and you're safe.

Haha, unfortunately, my knobs alone are like 7 deep, nevermind everything else. It's definitely good to keep in mind, but I'm not ready to create entire projects out of Ruby (which isn't exactly fast itself).

[RJHollins]

Good stuff Guys !

It's an education just following along and getting insights on the 'nature of the beast' ... particularly when optimization for smooth performance is part of the goal.

[tulamide]

OK, this is the key here! I need to understand this correctly though. From the way you're describing it, it would seem I really could just enable mouse moves on the top level for the whole project and it would be no difference in performance compared to just enabling it for one knob or something. Is that true?

Basically, yes.

My assumption was that, at least, it would only eat CPU when the mouse was over the given area, meaning it would do so less if it was only a small section compared to the entire GUI.

That's wrong. A mouse over is just a simple rectangle check. Where humans do just see that the mouse is over some spot, computers have to use math to evaluate that. So with the incoming mouse message, Flowstone has to calculate a position anyway. The size of the rectangle for that check doesn't matter (it's the same procedure, just other values)

Ruby (which isn't exactly fast itself).

It is as at least as fast as green. In some situations, better structuring in Ruby makes it faster than green.

[RJHollins]

I wonder if some of the CPU use/speed is related to 'screen redraws'

What I've read, here, is that sometimes minimizing the re-draw area can improve response. This is not much related to mouse STATUS as it is to updating sections of the GUI.

Again ... just a wonder

[Perfect Human Interface]

Basically, yes.

Thanks Tulamide

It is as at least as fast as green. In some situations, better structuring in Ruby makes it faster than green.

How did you come to this understanding? I can understand how it could be faster, but never slower?

[tulamide]

How did you come to this understanding? I can understand how it could be faster, but never slower?

Both Flowstone and Ruby are interpreters. Both have optimized C/C++ Code under the hood. Ruby in Version 1.9.3 (which is used here) is, for example, 2x as fast as Python (another interpreter). Ruby runs independantly from Flowstone. They just met when Flowstone passes data to the Ruby editor, takes them from the editor, or when Ruby requests access to Flowstone data (e.g. the front panel). Given all that I can't imagine any situation where Ruby could be slower.

Besides that it's also more versatile. The IO class alone is worth using Ruby, not mentioning the most advanced arrays I've seen so far. Green is good. If you want to realize more complex things, Ruby is at least just as good

[Perfect Human Interface]

Thanks for taking the time to answer all my questions.