Graphics speed: Display vs cpu

[tulamide]

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?

No.
Both use GDI+, so the raw drawing itself is time-equivalent. But "vector" drawing is much more complex in design than bitblitting some pixelmaps, and here's Ruby's advantage. You can manage your drawing engine a lot easier, and a lot of triggers become unnecessary, replaced by method calls within Ruby's 100 Hz thread. Also, it offers a lot that green doesn't (for example extremely versatile pens and brushes).
The more complex your drawing the more I would go with Ruby. Just drawing a line reacting to a float value is so simple that I doubt you notice any difference.

[pshannon]

This was a good discussion and thanks everyone for the clarity. I have decided to stay with ruby and a partial hybrid of certain prims. for graphics. I have had good results so far working mainly with vectors and not bitblt. Bitblt actually works blazing fast speeds in directx. I do plan on looking deeper into bitblt and FS futher later. I look at it this way, this is more of a sound priority application and graphics would be treated with lesser a priority in comparison.

[deraudrl]

This was a good discussion and thanks everyone for the clarity. I have decided to stay with ruby and a partial hybrid of certain prims. for graphics. I have had good results so far working mainly with vectors and not bitblt.

I'm assuming that "hybrid" in this context is a fixed bitmap background with a moving vector indicator. It just seems like that has to be slower than a straight bitmap solution, given that some subset (all?) of the background must be redrawn at each vector update anyway. Am I missing something?

[tulamide]

This was a good discussion and thanks everyone for the clarity. I have decided to stay with ruby and a partial hybrid of certain prims. for graphics. I have had good results so far working mainly with vectors and not bitblt.

I'm assuming that "hybrid" in this context is a fixed bitmap background with a moving vector indicator. It just seems like that has to be slower than a straight bitmap solution, given that some subset (all?) of the background must be redrawn at each vector update anyway. Am I missing something?

Each view is basically a bitmap (the correct word would be pixelmap, but somehow bitmap has established). If you have one view with the background and another on top with runtime drawing, it's two bitmaps that are transmitted to the final bitmap. In reality we're talking of special memory areas that are created for the sole purpose of quickly calculating bytes. Each pixel is represented by 4 bytes (ARGB) and when combining two bitmaps without a special mode (in drawing programs you might have seen modes like "normal", "darken", "exclude", etc, which are just special bit operation modes like OR, AND, XOR, etc.) each byte of both bitmaps is combined. Non-transparent pixels for example just replace the pixels of the underlying bitmap.
In essence, how much slower it is does not depend on the "hybrid" work, but on how complex the runtime drawing is. Regarding "fixed" background, there is no such thing. Wether you draw at runtime over a background image, or place another image on top of the background image, in both cases the background will be redrawn.

[pshannon]

This was a good discussion and thanks everyone for the clarity. I have decided to stay with ruby and a partial hybrid of certain prims. for graphics. I have had good results so far working mainly with vectors and not bitblt.

I'm assuming that "hybrid" in this context is a fixed bitmap background with a moving vector indicator. It just seems like that has to be slower than a straight bitmap solution, given that some subset (all?) of the background must be redrawn at each vector update anyway. Am I missing something?

Each view is basically a bitmap (the correct word would be pixelmap, but somehow bitmap has established). If you have one view with the background and another on top with runtime drawing, it's two bitmaps that are transmitted to the final bitmap. In reality we're talking of special memory areas that are created for the sole purpose of quickly calculating bytes. Each pixel is represented by 4 bytes (ARGB) and when combining two bitmaps without a special mode (in drawing programs you might have seen modes like "normal", "darken", "exclude", etc, which are just special bit operation modes like OR, AND, XOR, etc.) each byte of both bitmaps is combined. Non-transparent pixels for example just replace the pixels of the underlying bitmap.
In essence, how much slower it is does not depend on the "hybrid" work, but on how complex the runtime drawing is. Regarding "fixed" background, there is no such thing. Wether you draw at runtime over a background image, or place another image on top of the background image, in both cases the background will be redrawn.

Oh boy, I did discover the background is always over written with everything else layered over top. Thanks for giving more insight on the behind the scenes of how this works. This will help me optimize without trial and error to see the results. I have been doing a lot of trial and error lately on seeing what works and what does not. This will I figured I would to vector for what I am trying to do. I am going to see if I can layer a bitmap(pixelmap) over top of a vector with transparency to show the vector underneath and hopefully give the effect I am looking for like a meter.

A good example of a good algorithm in compression like mpeg is in blocks without over writing the whole frame and just the changed areas. This used to also be done with some legacy games/graphics when you needed to save as much cpu/ram. Maybe I can get 60fps someday. haha

[wlangfor@uoguelph.ca]

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").

But a static image that I use fgor knobs is only 32kb's or so for HQ, I also use a draw limiter. I compare to a 1-2 mb image and I'm not sure I agree.

It has to be cached either way to show up so quickly.