Graphics speed: Display vs cpu

[pshannon]

Hey Everyone,

For FS I am a little bit of a novice on the graphics side. I am not a novice to graphics at all, but just with FS. So looking for opinions on screen speed, cpu and complexity. I will share some of my thoughts below:

I have been reverse engineering other modules or peoples design modules on graphics. I have been trying to learn the methodology for how graphics work and the mouse interactions for FS. It looks like ruby is quite easy and works very well with speed, cpu and low complexity to achieve your goal. When I look at the designs people put together for prims, at first it looks fine until you get some complex ones and dive deeper into it. Trying to take apart so many deeper dives and many screens later you almost get lost on where you are. Once you figure out something you click on another module deep inside and it takes you to a whole another world. I start to scratch my head and think is this the best way? I started messing more with the ruby lately and started dropping the lower prim stuff because of it. I think I can get more done with it and more features, but I am curious what the other more veterans would say? Old school days we were forced to create our own code to access the graphic card memory back buffers for paging and flipping the page to the screen for speed and no flicker. Today it looks like it is all taken care of for us with all the API calls. Plus there are many brilliant graphic/game engines out there. I know long winded, thanks for any responses.

[deraudrl]

The first rule of real-time programming is, "Don't waste time optimizing low-priority threads." Unless/until it's obvious that any given chunk of a schematic is using an unwarranted percentage of the available resources, use the easiest available method for implementing it. (As a corollary, I once spent the better part of a week talking a mid-level manager out of spending $75K of a $90K R&D budget on a software tool to automate the easiest 10% of the development effort.)

Mind you, I say that as someone who thinks the current "standard" modules/methods have an obscenely high amount of needless complexity, especially as regards the interaction between the preset manager and the GUI. I'd like to fix what I see as an "elegance deficit", but I can't quite convince myself it's worth the trouble: sometimes it's better to embrace the suck, accept that it works, and view it as a black box. Then again, I'm also saying that as someone who has exactly zero intention of ever fielding a commercial product developed on FS, so reducing the CPU/GPU usage of a schematic is not a priority...I can always buy a faster computer if it really matters to me.

[pshannon]

The first rule of real-time programming is, "Don't waste time optimizing low-priority threads." Unless/until it's obvious that any given chunk of a schematic is using an unwarranted percentage of the available resources, use the easiest available method for implementing it. (As a corollary, I once spent the better part of a week talking a mid-level manager out of spending $75K of a $90K R&D budget on a software tool to automate the easiest 10% of the development effort.)

Mind you, I say that as someone who thinks the current "standard" modules/methods have an obscenely high amount of needless complexity, especially as regards the interaction between the preset manager and the GUI. I'd like to fix what I see as an "elegance deficit", but I can't quite convince myself it's worth the trouble: sometimes it's better to embrace the suck, accept that it works, and view it as a black box. Then again, I'm also saying that as someone who has exactly zero intention of ever fielding a commercial product developed on FS, so reducing the CPU/GPU usage of a schematic is not a priority...I can always buy a faster computer if it really matters to me.

Thanks for your insight and I agree with your thoughts. I really didn't have plans on making a commercial product. My goal is to get a tool out fast, but have good frame rates on the graphics. Dancing leds or graphs. I have moved towards ruby code using arrays and loops to display to the screen. It is very fast, but when I take an led as one module and duplicate it to 40+ the system takes a serious hit. I am pretty sure it is all the refreshes for each individual led bmp, however, I get your point, stick with what works for me. Thanks

[trogluddite]

It is very fast, but when I take an led as one module and duplicate it to 40+ the system takes a serious hit. I am pretty sure it is all the refreshes for each individual led bmp

Yes, you're right on track.
Graphics rendering for both primitives and Ruby is all handled by the Windows GDI+ component. Not only is this rather ancient, but it runs entirely in the main CPU with no GPU hardware acceleration. So the CPU hit for animations, especially if there are lots of individual, layered items can get pretty steep, more so still if there's a lot of text or complex vector elements to render.

As you've suggested; using loops, again either Ruby or primitive Redraw Loops, to redraw bunches of GUI parts from a single redraw can offer some good savings, so long as the total redrawn area doesn't get too large (and short, wide areas generally draw substantially faster than narrow, tall ones). From what you've written, I'd guess that the rest will come pretty naturally; prefer unscaled bitmaps that can just be blitted where you can, don't go too mad with the layering, redraw only what and where you really need to, etc.

Also, if you think you have what should fairly optimal redrawing, but you're seeing some odd glitches here and there, give the schematic a go as an export. The FS workspace itself commands quite a lot of redraws when generating the workspace and navigator thumbnails, and every once in a while it makes an otherwise good optimisation look like it's not working properly.

I say that as someone who thinks the current "standard" modules/methods have an obscenely high amount of needless complexity

You're not the only "someone". The toolbox GUI modules are terribly designed, IMHO, and the previous generation all-primitive ones in SM were no better - it's a very long-standing tradition! The controls with the additional module layer that seems to serve no purpose other than to stop you from sensibly resizing the thing drive me nuts. However, like you, I'm always on the verge of cleaning them up, but can never quite convince myself to be bothered.

[Spogg]

Yes, I found out just by accident years ago that a schematic in FS could start to respond and re-draw horribly slowly as it grew in size, but when exported as a plugin the same design would work a lot more smoothly. So when I make anything with animations, I always test them in a DAW as I go, and am often pleasantly surprised. But it doesn’t hurt to get it as fast as possible in FS first.

Also it’s well worth reading trog’s trigger tutorial. I still get things wrong, but it gives a handle on how to reduce triggers and thus speed up the responsiveness and reduce CPU load.

I’m no Ruby expert, but I understand that a system in Ruby can reduce the trigger issue when compared with the identical function made with green prims. Obviously this is really only relevant to complex functionality.

Cheers

Spogg

[pshannon]

Thanks again for all the replies and insights. I kept thinking, am I the only one who sees it this way? Clearly plenty of people see it, but just deals with the cards they are handed to make things better.

[wlangfor@uoguelph.ca]

Avoid strip animations for knobs and use rotate instead and then figure out the best way to keep the rotation axle true. I've seen one by acrobat worth trying.

I prefer redraw area sometimes, but it doesn't react well to image backgrounds. assuming the background is a solid colour, or simple it might.

Redraw is the best but it affects graph and meter readouts especially for knobs and meters.

[trogluddite]

Unless you need extremely fine resolution of the rotation, bitmap animation strips will be far more efficient than rotating them. Even if the frame needs resizing (which should also be avoided if possible), the rotation of the frame will be recomputed every single time you redraw it, and that's a lot a calculations. OTOH, drawing a pixel-aligned frame at its native size is simply a memory copying operation ("blitting").

[tulamide]

Unless you need extremely fine resolution of the rotation, bitmap animation strips will be far more efficient than rotating them. Even if the frame needs resizing (which should also be avoided if possible), the rotation of the frame will be recomputed every single time you redraw it, and that's a lot a calculations. OTOH, drawing a pixel-aligned frame at its native size is simply a memory copying operation ("blitting").

What trog says!

Basically, whenever you use bitmaps, don't do any runtime calculations for frames.

If you absolutely need runtime animations, for example for a responsive interface that zooms, resizes, rotates on user input, or a graphical envelope editor, etc., omit bitmaps completely and switch to "vector"-drawing - runtime-drawing your elements through the use of Ruby. That way you only draw where needed and thereby mitigating the consequence of a higher cpu load in favor of runtime graphics.

[Spogg]

...If you absolutely need runtime animations, for example for a responsive interface that zooms, resizes, rotates on user input, or a graphical envelope editor, etc., omit bitmaps completely and switch to "vector"-drawing - runtime-drawing your elements through the use of Ruby. That way you only draw where needed and thereby mitigating the consequence of a higher cpu load in favor of runtime graphics.

So is it reasonable to conclude that using Ruby for vector-type animations is “better” than using the drawing prims?
Take a simple example: A line that changes length in response to a float value (like a bar graph display from a mono to float prim). Or is there a complexity break-point where Ruby takes over in the drawing efficiency stakes?

Cheers

Spogg