Re: The Need for speed - C / C++ / MFC Discussion Boards

will138317-Dec-02 3:45

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.

Re: The Need for speed

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

Re: The Need for speed

will138317-Dec-02 4:15

will1383

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

Re: The Need for speed

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

Re: The Need for speed

will138317-Dec-02 4:49

will1383

17-Dec-02 4:49

Sorry,

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

Dan Willis

Re: The Need for speed

Nitron17-Dec-02 5:07

Nitron

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

Re: The Need for speed

will138317-Dec-02 5:37

will1383

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

Re: The Need for speed

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

Re: The Need for speed

will138317-Dec-02 5:27

will1383

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

Re: The Need for speed

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

ExtTextOut drawing landscape...

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

Nitron

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

Resizing CFormView with Status Bar and Toolbar

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

Re: Resizing CFormView with Status Bar and Toolbar

Nitron17-Dec-02 3:36

Nitron

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

Re: Resizing CFormView with Status Bar and Toolbar

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

Re: Resizing CFormView with Status Bar and Toolbar

Nitron17-Dec-02 4:01

Nitron

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

Re: Resizing CFormView with Status Bar and Toolbar

Jonah Bishop17-Dec-02 4:23

Jonah Bishop

17-Dec-02 4:23

Oops. I should have checked a little more thoroughly here at the site...

I found the exact thing I was looking for in this article.

But thanks for your prompt replies, Nitron. They are certainly appreciated! Smile | :)

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

_stdcall question

ns17-Dec-02 3:03

17-Dec-02 3:03

I had in a C dll, that was called by VC++, the following and it worked fine:

#define DllExport   __declspec( dllexport )


DllExport void __cdecl Fusion_Method(int *nalg, int *score, int *fusion_score)
{

I wanted to call this dll in a VB program and am told I need to do _stdcall. I searched the web but dont see how to modify the above to make it stdcall instead of __cdecl. Please help!

Appreciate your help,
ns

Re: _stdcall question

Joaquín M López Muñoz17-Dec-02 3:08

Joaquín M López Muñoz

17-Dec-02 3:08

Just replace __cdecl with __stdcall in the declaration of FusionMethod. That's all you need to do (hopefully).

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Re: _stdcall question

ns17-Dec-02 3:15

17-Dec-02 3:15

Good try. It compiled fine. But the VB callling program stubbornly still says it doesnt know anything about the function from the dll..... Frown | :(

Thanks so much for helping though... Smile | :)

Appreciate your help,
ns

Re: _stdcall question

ns17-Dec-02 3:27

17-Dec-02 3:27

Am I doing this right?

#define DllExport __stdcall( dllexport )

//#define DllExport __cdecl( dllexport )

//DllExport void __cdecl Fusion_Method(int *nalg, int *score, int *fusion_score)

DllExport void __stdcall Fusion_Method(int *nalg, int *score, int *fusion_score)

This wont even compile!

Thanks though, for the input

Appreciate your help,
ns

Re: _stdcall question

Joaquín M López Muñoz17-Dec-02 3:33

Joaquín M López Muñoz

17-Dec-02 3:33

Try this:

#define DllExport __declspec( dllexport )

extern "C" DllExport void __stdcall Fusion_Method(int *nalg, int *score, int *fusion_score)
...

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Re: _stdcall question

ns17-Dec-02 3:44

17-Dec-02 3:44

Compiler says:

c:\pmarmodif\fusionmethod.c(3) : error C2059: syntax error : 'string'<br />

pointing at the extern line.....

Thanks for keeping up with my issue here... Smile | :)

Appreciate your help,
ns

Re: _stdcall question

Joaquín M López Muñoz17-Dec-02 5:54

Joaquín M López Muñoz

17-Dec-02 5:54

Ummm.. I guess fusionmethod is C++ code, so change the extension to .cpp. The fact that you're declaring the function as extern "C" does not have to do with the language you use to implement it.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Re: _stdcall question

Chris Richardson17-Dec-02 14:10

Chris Richardson

17-Dec-02 14:10

The others who respond are correct, I'm only adding on here. One thing I've found when I want to use __stdcall is the need to include a line defining the function in the .def file for the project.

So if your dll project is named "ABC", open "ABC.def", and add the following line to the "EXPORTS" section (it must be on it's own line):

Fusion_Method

Now, build your dll again, and the function should be exported with the correct name.

Chris Richardson

Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.