Performane of multiple SPRITES

[Guest Patrick_Waugh]

In implementing 5-level lighting with the gauges requiring parts (like moving cards etc.) I'm doing something like this:MAKE_SPRITE (100% light version)MAKE_SPRITE (75% light version)MAKE_SPRITE (50% light version)MAKE_SPRITE (25% light version)MAKE_SPRITE (day version)MAKE_STATIC (background)which with a gauge that requires move moving parts might look like this:MAKE_SPRITE (100% light version) // PitchMAKE_SPRITE (75% light version)MAKE_SPRITE (50% light version)MAKE_SPRITE (25% light version)MAKE_SPRITE (day version)MAKE_SPRITE (100% light version) // BankMAKE_SPRITE (75% light version)MAKE_SPRITE (50% light version)MAKE_SPRITE (25% light version)MAKE_SPRITE (day version)MAKE_STATIC (background)You get the idea. Each of these has a callback, and with several instruments on the panel, it is beginnig to take a noticable amount of time to change from one level to another (at least on my dinosaur of a computer which barely runs FS X).The callbacks have to HIDE/SHOW the sprite based on the lighting setting.Is there a better way to do this that can increase performance? Should I move stuff to a "gauge" callback?Any thoughts, ideas, pointers appreciated.

[Guest ziporama]

On my pushback gauge (FS9 only) I ended up having to use GDI+ for layering instead of using the default layered images. I only have two bitmaps, no matter what the lighting is (three levels, you have more, but the principle is the same). I also render multiple displays in the same bitmap, so it does look like multiple gauges, but it's really only one.I had a lot of trouble with the default bitmap layers in gauges, and aside from performance, the issue for me was the lack of good compositing support.For performance, what I do is basically render the "composite" bitmaps I need in memory once and only if the bitmap needs to change as a result of a state change (user input, etc...), and keep on re-using that. To FS, it only looks as a couple of bitmaps.Etienne

[Guest Patrick_Waugh]

Yes, I used GDI+ in another project, but is way overkill for what I need here.Turns out that the performance issue was something else (which is why profiling is so important), and it now works fine again.I may still take the code that determines which SPRITE to display and factor it out, but at least I don't have to do that right now.