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
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
Why is this lagging
4 posts
• Page 1 of 1
Why is this lagging
I am building a app with basic flight instruments...
when i run a compile with only one inst visible there is no lag
when i run a compile with both inst visible, there is a lot of lag
what do i do wrong ??
Regards
Frank
when i run a compile with only one inst visible there is no lag
when i run a compile with both inst visible, there is a lot of lag
what do i do wrong ??
Regards
Frank
- Attachments
-
- SERVER_6.fsm
- (396.11 KiB) Downloaded 957 times
- frank-riedel
- Posts: 40
- Joined: Sun Aug 19, 2012 10:36 am
Re: Why is this lagging
Hi Frank,
Have you checked the CPU load on your PC while the displays are running? - use the CPU meter in the Windows task manager, as the FlowStone CPU readout won't show anything for CPU used by the graphics.
I have a feeling that you'll see some very high readings, and possibly max'ing out a CPU core when you have both displays running.
FlowStone uses GDI graphics routines for all the screen drawing, which are always processed by your main CPU without any hardware acceleration from the graphics card. This can really eat CPU if you are animating a large area of the screen, especially when you have so many overlapping layers.
Here's a couple of suggestions for getting the CPU load down a bit...
- All of your bitmaps seem to cover the complete area of the display - so when there is a re-draw, there is a lot of processing being done to work out which pixels will be visible through all of the transparent parts. For many of the smaller readouts on the display, it would be better to use smaller bitmaps that only cover their own little areas, and then position them correctly once you have them inside FS.
This will make laying out the panel a bit more tricky, but will lead to much less layers overlapping, and also only a much smaller part of the screen will get redrawn when a control changes.
- I don't know how quickly your flight data is coming in, but if it is very fast, it could be that the screen is being redrawn too quickly. More than about 25-30 screen updates per second will consume a lot of CPU, and many of those frames won't be picked up by your monitor or by your eyes.
You can find in THIS POST, a little gizmo for controlling the frame rate of animations - it ensures that you always can see the current data, but without showing more frames than are needed by your display.
Have you checked the CPU load on your PC while the displays are running? - use the CPU meter in the Windows task manager, as the FlowStone CPU readout won't show anything for CPU used by the graphics.
I have a feeling that you'll see some very high readings, and possibly max'ing out a CPU core when you have both displays running.
FlowStone uses GDI graphics routines for all the screen drawing, which are always processed by your main CPU without any hardware acceleration from the graphics card. This can really eat CPU if you are animating a large area of the screen, especially when you have so many overlapping layers.
Here's a couple of suggestions for getting the CPU load down a bit...
- All of your bitmaps seem to cover the complete area of the display - so when there is a re-draw, there is a lot of processing being done to work out which pixels will be visible through all of the transparent parts. For many of the smaller readouts on the display, it would be better to use smaller bitmaps that only cover their own little areas, and then position them correctly once you have them inside FS.
This will make laying out the panel a bit more tricky, but will lead to much less layers overlapping, and also only a much smaller part of the screen will get redrawn when a control changes.
- I don't know how quickly your flight data is coming in, but if it is very fast, it could be that the screen is being redrawn too quickly. More than about 25-30 screen updates per second will consume a lot of CPU, and many of those frames won't be picked up by your monitor or by your eyes.
You can find in THIS POST, a little gizmo for controlling the frame rate of animations - it ensures that you always can see the current data, but without showing more frames than are needed by your display.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
Don't stagnate, mutate to create!
-
trogluddite - Posts: 1730
- Joined: Fri Oct 22, 2010 12:46 am
- Location: Yorkshire, UK
Re: Why is this lagging
Thx for Reply
and - yor are right - CPU (1 of the kernels) are MAX loaded !
/Frank
and - yor are right - CPU (1 of the kernels) are MAX loaded !
/Frank
- frank-riedel
- Posts: 40
- Joined: Sun Aug 19, 2012 10:36 am
Re: Why is this lagging
The images are rather large also; FS & SM struggles with fast updating large images.
- infuzion
- Posts: 109
- Joined: Tue Jul 13, 2010 11:55 am
- Location: Kansas City, USA, Earth, Sol
4 posts
• Page 1 of 1
Who is online
Users browsing this forum: Google [Bot] and 61 guests