Big CPU Problem in compiled EXE

[Walter Sommerfeld]

But relying on native re-scaling of the bitmap is not "very optimised" within your development environment of choice. The wise developer does not rely on a djinn to grant his wishes - either a different tool must be chosen, or the best possible compromise made with what is available...
- Use the most appropriate input data (i.e. a correctly dimensioned bitmap)
- Use a more efficient process (i.e. crop instead of re-scale the bitmap)
- Perform the intensive process offline (i.e.use other bitmap primitives to rescale the image within the schematic.)
None of these may seem "ideal" to you, but nobody has yet invented an "ideal" programming language or modular environment - so there is a trade between simplicity/familiarity/availability, and the difficulty of learning a new tool.

Ha -big misunderstanding here Mr. Teacher I know how 2 optimize images!

I only dragged and rescaled the bg 4 a test purpose and also mentioned it was my "mistake' - nothing more...
And it's not acceptable that the Redraw of a non transparent real small area over a Background needs so much CPU!
This 'very optimized' was a tribute 2 ur redraw tips and my 6 years of dev time 4 the optimum (4 me) Levelmeter with AM's perfect pixels not shown here...

- I did not use earlier versions of FS, but you say you see a big extra overhead in FS3 compared to earlier versions. If you are on the same machine, and same Windows, then GDI+ has not changed - therefore there may be some changes in FS that make this difference -so I would still advise to share the schematics with the dev's. It may be key to some GDI+ optimisation like you ask for.

We begged 4 this optimizations many Years in the SM forum - i think u know that 2...
The GUI probs and other changes in FS 1/3 over/and SM are significant trigger/(re)draw things that we all tried 2 compensate/optimize with workarounds - here again u are the chief 4 me
Just use my example and see how much CPU this new ruby levelmeters needs - 2 much in my opinion!
Maybe it's only me who needs big Level meters that u can read w/o a magnifying glass because i dev Full screen Progs.

Again - i hoped (starry-eyed) ruby changed this but it's 4 robots and vector drawing not 4 Bitmaps optimized...

[trogluddite]

Hi Walter.
First - sorry if my post seemed too critical. Not personal - I just wrote the answer so that the less experienced user looking at the forum can learn some knowledge of the limitations, and best ways to make the problem as small as possible.
You know already, of course, my own criticism of GDI+ from here and the other forum - it sets the limit beyond which our optimisations cannot take us. Also, of course, it is a barrier to making FS cross-platform, and some day in the future even possible that Micro$oft decide to make a new Windows that does not include GDI+ at all!
All good reasons to change to GPU processed graphics - but this is not without its problems. We are currently adding 3D graphics to some software at work, and already our small team has decided to offer a 'non GPU' alternative in the code - because OpenGL support is so random/buggy on different CPU/GPU combinations. Even on our small number of 'top-spec' PC's, we have many problems to make our graphics engine reliable.
Many things that are simple using GDI+, are much more complex to implement using OpenGL - the developer is required to do much more coding because there is less abstraction than for GDI+. So I feel we must be realistic that for such a small dev team as DSPr, it will not be something that can be delivered quickly, and it is right that making FS3 reliable must be the first priority.
Using GDI+ is not perfect, but it works reliably on all user's PCs, and makes GUI design easy for the novice developer - and I think that this is preferable to a rushed implementation of some other way. OpenGL or whatever should only be done when the dev's have the time and resources to do it well, including equivalents of all the nice abstractions that we have gotten used to (for back-compatibility), otherwise we could have many broken schematics.

[Walter Sommerfeld]

No problem at all Trog...

It's only my frustration about transfering my GUI animation parts into ruby w/o success which made me a little sensible ...
I will PM u later...

cu
Walter