C / C++ / MFC

17-Dec-02 3:45

Hi All,

I'm having a serious performance issue and I'm hoping I can get some help here. Here's what I have:

I have a C++ dll that creates a dialog box for displaying graphics. This dll uses STL vectors and maps to maintain the data passed in. I then use OpenGL to generate the graphics that are displayed in the dialog window.

At the moment I am generating a WM_TIMER message to pump the dll with data. But, the application is a CPU HOG, and pins the CPU when ever I start pumping messages WTF | :WTF:

. This is not acceptable as I'm sure you may know. In addition, I NEED to be updating the screen at a rate of 30-50 frames per second, and I don't think a WM_TIMER message will allow me to update at that rate. Eek! | :eek:

Any ideas? Any suggestions? Comments?? Confused | :confused:

I'm really stumped with this one.

Thank you in advance.

KaЯl17-Dec-02 4:00

KaЯl

17-Dec-02 4:00

Instead of WM_TIMER, what about a separate thread to manage the data when another thread manages the display ? it would suppress the "synchronization" between data managment and display.
You may also use some OpenGL tricks to improve the framerate, as the use of resident textures for example. However, if the framerate must raise a certain limit, it would be perhaps more careful to test first if it's possible according to the available hardwares, or it could get strange on graphically slow computers.

HTH,

I hurt so bad inside
I wish you could see the world through my eyes
It stays the same
I just wanna laugh again

will138317-Dec-02 4:15

17-Dec-02 4:15

KaЯl wrote:
Instead of WM_TIMER, what about a separate thread to manage the data when another thread manages the display ? it would suppress the "synchronization" between data managment and display.

Currently, even though the dialog is in a dll, I am using MFC MDI as a wrapper around the whole thing.

So in essence what you are saying is; Instead of using the WM_TIMER message, create a thread that just performs a basic loop, getting the data and updating the display, and the update rate will be what ever the CPU slice is for that particular thread?

KaЯl wrote:
You may also use some OpenGL tricks to improve the framerate, as the use of resident textures for example.

What kind of tricks can I use in OpenGL?? I'm not super familiar with it. What do you mean by using resident textures?? What other tricks would help improve frame rate? I should be able to figure them out if I have a direction to head in.

KaЯl wrote:
However, if the framerate must raise a certain limit, it would be perhaps more careful to test first if it's possible according to the available hardwares, or it could get strange on graphically slow computers.

I always test, but in this case I did not write this code base. I was only left to deal with it. Roll eyes | :rolleyes:

Once again, thank you.

Dan Willis

Gary Kirkham17-Dec-02 4:40

Gary Kirkham

17-Dec-02 4:40

You didn't say what operating system you where using...it makes a difference. Here is a good article on Windows timing

http://www.codeproject.com/system/simpletime.asp

Gary Kirkham

A working Program is one that has only unobserved bugs

will138317-Dec-02 4:49

17-Dec-02 4:49

Sorry,

I am using NT-based Operating systems. I.E. NT 4.0, Win2k, XP (home & Pro)

Dan Willis

Nitron17-Dec-02 5:07

17-Dec-02 5:07

groover4life wrote:
So in essence what you are saying is; Instead of using the WM_TIMER message, create a thread that just performs a basic loop, getting the data and updating the display, and the update rate will be what ever the CPU slice is for that particular thread?

wait, wait, wait... Use the loop in the thjread for data mainpulation only, and pump custom messages out of the thread to the UI thread and handle the redraw and stuff in the UI thread as a message handler. I've had very bad experiences when trying to access stuff outside of my own little thread, but the PostMessage thing works very well. NT should get you pretty accurate down to around 10ms or so, so that is about a 100Hz refresh. (You'll need to do a Sleep(10) or whatever to delay the thread.) Make sure you aren't doing very time consuming stuff here either, as that will begin to affect your performance. Remember, NT is not an RT OS, so you are at the mercy of other higher priority things on the PC. There are some articles around here about using multimedia timers for better precision, but I haven't used any of them yet.

- Nitron

"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb

will138317-Dec-02 5:37

17-Dec-02 5:37

Nitron,

This seems like a viable solution to my performance issue. I believe I will take this approach, then go back into the OpenGL code and see what I can do to optimize there. At least I don't need it to be real time as Windows is not a RTOS, but it should give me the refresh rate which I need.

Also, Do you think it will hurt having to access my document object to dump the data into? I don't have to manipulate the data alot.

do you think this will also help my CPU HOG issue as well? I may have some more questions once I design and implement this method (will take me most of the afternoon as the application is pretty complex in nature).

Thank you so much for the suggestions and comments. Keep 'em coming! Whoo Hooo!

Dan Willis

KaЯl17-Dec-02 5:20

KaЯl

17-Dec-02 5:20

groover4life wrote:
create a thread that just performs a basic loop, getting the data and updating the display, and the update rate will be what ever the CPU slice is for that particular thread?

My idea is this one: One thread updates the data periodically (using an infinite loop with a call to SleepEx in it, to allow the OS to activate another thread, especially important with Win9X OSs), another thread displays these data periodically too (with a timer for example), but asynchronously with the first one. Data protection is then required between the two threads, for example by using a mutex.
It enables to smooth the CPU consumption.

groover4life wrote:
What kind of tricks can I use in OpenGL??
There are plenty technics, you should perhaps refer to the OpenGL Red and Blue Books. You may also find some rules to follow on this page[^]

FYI, I call resident textures bitmaps you may "upload" in the video memory of the video card. Using this instead of standard RAM may fasten a lot the rendering, according to the capacity of the video card and the use of textures by the application.

groover4life wrote:
I always test, but in this case I did not write this code base. I was only left to deal with it
What I meant was that you should be careful the end users of your application may have a computer less powerful than yours, so you should probably have to envisage this case.

HTH,

K.

I hurt so bad inside
I wish you could see the world through my eyes
It stays the same
I just wanna laugh again

will138317-Dec-02 5:27

17-Dec-02 5:27

KaЯl wrote:
I always test, but in this case I did not write this code base. I was only left to deal with it
What I meant was that you should be careful the end users of your application may have a computer less powerful than yours, so you should probably have to envisage this case.

LOL! Thanks! But I doubt that my company's clients will have a machine slower than a P-3 450 which is what I'm using for my development. Laugh | :laugh:

Dan Willis

ExtTextOut drawing landscape...

KaЯl17-Dec-02 7:09

KaЯl

17-Dec-02 7:09

When dealing with OpenGL, GPU is often more important than CPU Smile | :)

Following the video card, the framerate may vary considerably (i've still experienced a variation from 1.5 fps to 50 fps !)

I hurt so bad inside
I wish you could see the world through my eyes
It stays the same
I just wanna laugh again

Braulio Dez17-Dec-02 3:27

Braulio Dez

17-Dec-02 3:27

Hi,

I need to draw some text rotated 90º in the screen, for that, what I did is to transform the normal font, and call ExTextOut...

...But I have a problem, with multiline text... with DrawString was now problem give a rect and make the text fit there... but it seems that DrawString doesn't work for rotated text, and does ExTextout support this ?

Thanks in advance, Greetings
Braulio

Re: ExtTextOut drawing landscape...

Nitron17-Dec-02 3:32

Resizing CFormView with Status Bar and Toolbar

17-Dec-02 3:32

Try here[^].

- Nitron

"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb

Jonah Bishop17-Dec-02 3:28

Jonah Bishop

17-Dec-02 3:28

I have a CFormView class and I'd like to automatically resize the window when the user turns off the toolbar or status bar. In other words, I don't want the blank area of the form view (usually hidden by the toolbar or status bar) to show up when the user toggles the status of either bar.

I haven't seen any source that does this, so any help would greatly be appreciated.

Thanks!

Jonah Bishop
Visit JGB Productions
http://www4.ncsu.edu/~jgbishop

Nitron17-Dec-02 3:36

17-Dec-02 3:36

Use SetWindowPos()

i.e.:

WINDOWPLACEMENT wp;
GetWindowPlacement(&wp);

wp.rcNormalPosition.left    = rectNewRect.left  ;
wp.rcNormalPosition.right   = rectNewRect.right ;
wp.rcNormalPosition.bottom  = rectNewRect.bottom    ;
wp.rcNormalPosition.top     = rectNewRect.top   ;

wp.showCmd = SW_SHOWNORMAL;
SetWindowPlacement(&wp);

or something similar...

- Nitron

"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb

Jonah Bishop17-Dec-02 3:58

Jonah Bishop

17-Dec-02 3:58

I see how I would use that, but how do I figure out the new window size when hiding or (more importantly) showing the toolbar or status bar? Is there a call to get the view size (with the toolbar) and also get just the toolbar size (to subtract or add to the view size)?

Thanks! Smile | :)

Jonah Bishop
Visit JGB Productions
http://www4.ncsu.edu/~jgbishop

Nitron17-Dec-02 4:01

17-Dec-02 4:01

int x_size = GetSystemMetrics(SM_CXSCREEN);
int y_size = GetSystemMetrics(SM_CYSCREEN);

int x_max = GetSystemMetrics(SM_CXMAXIMIZED);
int y_max = GetSystemMetrics(SM_CYMAXIMIZED);

int yToolbar = y_size - y_max;

I think...

- Nitron

"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb