How best can i simplify "Redraw"?

[Matth23u]

Is there some really best way to simplify all things "Redraw"?

Say, if i make a signal matrix instead of having individual redraw components, or redrawing background instead of objects...

How would i best make-so redrawing entire interface would be fast and smooth, even when all knobs are automated?

[trogluddite]

Is there some really best way to simplify all things "Redraw"?

How would i best make-so redrawing entire interface would be fast and smooth, even when all knobs are automated?

Which would you prefer, "simplify" or "fast and smooth"? Keeping the amount of redrawing to a minimum does usually take extra work on the schematic - though it's not too hard to build up a little toolbox of sub-components to make it easier.

The general principles are simple enough to explain...

Minimise Areas

Always draw the smallest area that you can get away with. If only part of a control has changed, use area redraws to redraw only that part. If there are two or more smaller parts to draw, the smallest area that will encompass them all can be calculated mathematically, or the Area Union primitive can help.

Minimise Layering

Once you're happy with your GUI layout, incorporate static items such as labels into background bitmaps so that the graphics rendering has fewer layers to composite together. Most image editing software will let you work with grid snapping, so getting everything aligned isn't as difficult as you might think. It's also possible to draw to a bitmap within FlowStone - so a control which doesn't change often but contains a lot of drawing components can be 'flattened' into a single layer that doesn't get re-calculated for every single frame as it would otherwise.

Minimise Complexity

Bitmap controls are usually more efficient than those drawn by the vector graphics primitives or Ruby commands. If you can avoid re-scaling or rotating them, bitmap pixel data can just be blasted straight into the graphics memory, whereas the vector stuff involves a lot of complex mathematics. Likewise bitmaps of text labels will draw more efficiently than real-time rendered text.

Minimise ReDraws

Just because a parameter value has changed, it doesn't mean that the GUI always needs updating. For example, with bitmap-strip knobs, you only need to redraw when a new animation frame is chosen, not every time the control's float value changes. The changed primitive is your friend; it will also block redraws when the control is pushed up against its limits.

Restricting the rate of redraw triggers to a maximum number of frames per second can be done quite easily either in primitives or in Ruby; and it can be done per-control, so that you can keep high frame rates where you really need them.

Minimise Ruby Junk

When using Ruby for drawing, try to avoid constructing new Colors, Brushes, Fonts, etc. within the draw method. It wastes CPU power on re-creating a whole bunch of identical objects for every single frame, and creates lots of temporary Ruby objects for the Ruby garbage collector to deal with. Create as many of these as you can in the init method and access them via @instance @variables.

Here's a schematic containing the GUI modules from my Trogz Toolz collection. The modules are mostly sub-components rather than whole controls, but you'll find some of the bitmap rendering and draw rate limiting stuff I've mentioned in there (particularly in the "bitmap strip" modules.)

trogtools_gui.fsm

(44.44 KiB) Downloaded 1430 times

Ultimately, having nearly every control animated at once will always incur quite a high CPU load in FlowStone, just because of the graphics rendering engine that it uses (i.e. it doesn't use graphics hardware acceleration.) But it can definitely be done better than the standard toolbox controls do it.

[Matth23u]

By "simplify" i mean, make it more complicated so in the end, it does the redraw job just once and in sync with all areas... (reading further into text)

[Spogg]

... or the Area Union primitive can help...

... a schematic containing the GUI modules from my Trogz Toolz collection.

That’s a great collection of GUI tools trog! I had them before but now I can thank you for them!

I’m not too clear on the use of the Area Union prim. Would it be possible for you to explain a bit more about what it does etc?

Cheers

Spogg

[tulamide]

I’m not too clear on the use of the Area Union prim. Would it be possible for you to explain a bit more about what it does etc?

Actually the component reference explains it very good: "The Area Union primitive takes two area inputs and finds the smallest bounding rectangular area in which both will fit."

So, you create a new area of a size that encompasses both areas at the inputs. Say, the first is 0, 0, 10, 10 and the second is 30, 30, 10, 10
The resulting union area would be 0, 0, 40, 40

[trogluddite]

Here's an example of the most common thing I'd use Area Union for...

area_union_example.fsm

(754 Bytes) Downloaded 1442 times

The module contains a simple "moving object" - when you click in the module GUI, a circle is drawn centred on where you click. To try to make drawing as fast as possible, a RedrawArea is used.

However, note that when 'Use Area Union' is false, clicking in different places leaves "ghost" images behind - the area where the circle is right now is redrawn, but not its previous position. If you click so that that the positions overlap, you can see how bits of the old circle do get removed within the rectangular area enclosing the current circle.

With 'Use Area Union' turned on, the smallest possible area containing both the current and the old position is calculated, so the 'ghosts' get overdrawn, but without redrawing the entire view when that isn't really necessary.

To use it wisely, you need to understand how 'Redraw Area' works...

It has nothing to do with which drawing primitives will be recalculated. Like other primitives, they'll do something whenever a green trigger updates one of their inputs, as usual - and they'll update a little internal bitmap buffer when they do. All RedrawArea does is to say "I have drawn new things in here, so refresh this part of the display." FlowStone has no idea whether you really did draw anything new there or anywhere else, it just takes it on trust that all on-screen pixels outside the area are fine to stay just as they are. The important thing is that ReDraw Area doesn't decide which primitives will or won't update their little component of the graphics - it's a way for you to let the graphics engine know that you updated them!

Essentially, then, much of optimising graphics drawing is the same as any other trigger optimisation - not sending green values to drawing primitives when what they'll draw will be exactly the same, and then only doing a Redraw Area when at least one drawing primitive really was given new values to work with. The workload for updating the primitives is no different whether you Redraw Area for them individually or just ReDraw the whole view - the only difference is in how many "new" pixels have to be blended from the various "layers" and sent to update the display. Sometimes ReDrawing fewer, larger areas can be more efficient, especially if controls are very close together, overlap, or always move at the same time, because it involves fewer calls for updates; but most often, drawing the tiniest bits that you can get away with only on demand is the best way to go.

[tulamide]

Ah, my bad. It wasn't about the area union prim itself, but a certain drawing tech to spare CPU time. Now I got it!

@trog For several years now I point to many of your points as well, esp. regarding proper Ruby setup to keep the draw method light on cpu. I made lots of re-works of the standard toolbox RubyEdits and tried to give an understanding of what is going on behind the scenes, and why therefore a certain behavior might be better in terms of execution speed. But English isn't my native language and you're better at describing coherences. So, while it's nothing new to me, I am glad you take the time to write such articles. Maybe it will help more!

But there's one concept that I run against: "Keep graphics consumption low at all cost". I don't think that is necessary at all, and here's why:
1) In Flowstone, audio always comes first. If there is a conflict between audio calculation and graphics drawing, the former will be executed. So you really can experiement a lot and do much more than just a standard bitmap knob on a one-color-background.
2) The Windows graphic rendering works on demand. When there is a lot to do, the CPU load will have a short peak, but then falls back to idle. So, unless you're planning on a fully-animated 1080p GUI with 20 scopes in parallel, it is all fine.
3) Music producers have high quality PCs. I am guest on quite some musician forums, and whenever there's some kind of survey, the result is always the same. Their PCs are just as powerful as gaming PCs are (which currently is the most demanding area for PCs). Professionals currently use an i9, hobbyists an i7. This means a lot of power. Yes, there will be more than one plugin active, but rarely do you see more than 2 open/active GUIs. So the number of plugins that a user might use, only affects audio, not graphics.

I challenge you to use my spline class for some kind of scope and show me that it is too demanding, although full vector graphics. I've put a lot of work into optimizing the draw process, so while every spline is calculated from scratch and drawn in complex ways (I won't explain them here to save on space), it is relatively light weight. Is it as fast as a bitmap? Not at all. But it is much more versatile and allows for realtime reaction, for example.

[trogluddite]

But there's one concept that I run against: "Keep graphics consumption low at all cost".

Agreed; no kind of optimisation should be "at all costs". The primary purpose of a GUI is first and foremost to make it as easy as possible for the musician/producer to make the plugin do what they want. It's also worth taking into account how easy the code/schematic is to work with - when optimisation starts to make it hard to put a project together, it has almost certainly gone too far.

Music producers have high quality PCs.

They might well do - but I don't!

My target audience is anyone who wants to have a go at making music (or plugins), including folks who might just be experimenting for the first time on their crummy laptop. My own main PC these days is an off-the-shelf i5 laptop that's about 7-8 years old - and I just haven't the money to simply throw CPU power at the problem. Of course, I've never aimed anything I've made at "professionals" - so not everyone's requirements will be the same as mine.

Whether the graphics load is a problem or not is a matter of what hardware we have available, how complex we want our GUI animation to be, and what we're prepared to tolerate. FWIW, graphics load HAS been a problem for me with several designs that I've made - even low priority threads have to be served some time. If it's not practical for this to be improved any time soon (and I can well understand why it probably isn't), that's perfectly acceptable; but I am rather tired of being dismissed by being told that I don't really have a problem - my eyes and ears are not that easily fooled! If I'm greedy with how much I want to animate, then, yes, I'm greedy! Only a few days ago, I thought that a downloaded schematic had an audio clipping problem until I deleted the huge scope display that was making it glitch like crazy.

I challenge you to use my spline class for some kind of scope and show me that it is too demanding

I've not got as far as any benchmarking yet, but I'm getting my head around the API a bit. From what I've looked at so far, I like the interface - it's a lot nicer than using the built in bezier splines! I'm getting there slowly, but I don't have a huge amount of time to write test code for a new class that none of my other projects have any need for.

Whether it's "too demanding" or not is a totally subjective opinion, anyway - if I manage to break it, you'll just say that I was expecting too much of my weedy laptop! A fairer test would be to compare it with alternative ways of doing the same thing - seeing how quickly it draws compared to the built-in GDI bezier curves, for example (though they're less versatile, of course, so that's still not a totally fair test.) In any case, it still wouldn't prove any general point about whether graphics CPU load is too high, because there's no agreed upon definition of "too high" - I'm sure many other people consider it a lot less annoying than I do!

[Matth23u]

I'm right into dev in the current moment...
I'm reading thoroughly, i'm half done.

So, i could combine multiple knobs with slides into one single bitmap in an aligned grid?

The way i work is that i transmit 1x bitmap to ALL knobs with wireless. So... Could i transmit the result out the knob to a renderer square and position them according to their Midi CC value?

Further into reading: Whoa, the "Area Union" example is amazing (Still reading)
(Looking at the schematic) Tho, i barely understand what's going on in that schematic. I "See" what's going on, i see the wiring... I feel like it's erasing previous position and draws new position...
I'm lost I'll keep reading further.

--> I realize that simply removing background made animation So Much Faster! I'll simply "bake" the background onto the knobs and have no physical background at all!

(And i'll read further and wait and see if i could combine all bitmaps into one single bitmap, controlled by an array of knobs)

[Spogg]

@tulamide
I didn’t ask my question very well; it was too vague. I was really wanting to understand why you would need such a prim. But thanks for the reply sir!

@trog
As always, such a good and thorough response and I’m grateful for you taking the time to do this. The worked example is excellent.

Now, I must confess that I’ve come upon this ghost image issue several times in my development, and my solution was just to keep hitting that good old redraw trigger pin. Now I have what looks like a much better solution for such situations.

Cheers

Spogg