Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Graphics speed: Display vs cpu

For general discussion related FlowStone

Re: Graphics speed: Display vs cpu

Postby tulamide » Tue Mar 17, 2020 2:26 pm

Spogg wrote: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.
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Graphics speed: Display vs cpu

Postby pshannon » Wed Mar 18, 2020 3:41 am

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.
User avatar
pshannon
 
Posts: 144
Joined: Fri Jan 02, 2015 3:08 am

Re: Graphics speed: Display vs cpu

Postby deraudrl » Wed Mar 18, 2020 4:08 pm

pshannon wrote: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?
I keep a pair of oven mitts next to my computer so I don't get a concussion from slapping my forehead while I'm reading the responses to my questions.
deraudrl
 
Posts: 236
Joined: Thu Nov 28, 2019 9:12 pm
Location: SoCal

Re: Graphics speed: Display vs cpu

Postby tulamide » Wed Mar 18, 2020 5:13 pm

deraudrl wrote:
pshannon wrote: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.
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Graphics speed: Display vs cpu

Postby pshannon » Wed Mar 18, 2020 5:41 pm

tulamide wrote:
deraudrl wrote:
pshannon wrote: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 ;)
User avatar
pshannon
 
Posts: 144
Joined: Fri Jan 02, 2015 3:08 am

Re: Graphics speed: Display vs cpu

Postby wlangfor@uoguelph.ca » Thu Mar 19, 2020 2:57 pm

trogluddite wrote: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.
My youtube channel: DSPplug
My Websites: www.dspplug.com KVRaudio flowstone products
User avatar
wlangfor@uoguelph.ca
 
Posts: 912
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada

Previous

Return to General

Who is online

Users browsing this forum: No registered users and 42 guests