Beginpaint, Endpaint...
Author
hey folks,
my in-game-profiling tool says
beginpaint & endpaint eats up to 20% of the time,
the message-processing eats once more up to 20% of the time,
and so I ask, how can I increase the speed of both,
can I circumvent the lame beginpaint/endpaint,
or can I kick some messages,
or should I process them within the main game loop and not in an extra func.
thx in advance,
greets tgar
Is this is in a heavy loaded scene? Because in a relatively low-duty application even light-weight function calls might end up high in the list (Imagine a program doing only 'i++'; it would take about 100% of the program's time).
Greetz,
Illco
Greetz,
Illco
Author
uh, an answer, yehaa...
no, i render at the moment about 1 million tris per scene + ~120k tris
thx
tgar
no, i render at the moment about 1 million tris per scene + ~120k tris
thx
tgar
Ok. What kind of message processing do you do? And what do BeginPaint() and EndPaint() do and come from? I don't recall them being basic GL but then again it is over a year since my last GL program.
Author
BeginPaint & EndPaint are the functions from windows to redraw your window if it's invalidated,
and for the messageprocessing i use this:
is this the fastest way or is there a faster one
thx
tgar
and for the messageprocessing i use this:
if(peekmessage(&msg, NULL, 0, 0, PM_REMOVE)){ if(msg.message == WM_PAINT) { BeginPaint(Wnd, &ps); EndPaint(Wnd, &ps); break; } else if(msg.message == WM_QUIT) { Exit; // end the loop } else { TranslateMessage(&msg); DispatchMessage(&msg); }}is this the fastest way or is there a faster one
thx
tgar
Quote:Original post by Thaligar
BeginPaint & EndPaint are the functions from windows to redraw your window if it's invalidated,
and for the messageprocessing i use this:
*** Source Snippet Removed ***
is this the fastest way or is there a faster one
thx
tgar
The best way to deal with WM_PAINT messages if you have an OpenGL window you're continuously updating is to just call ValidateRect(hWnd, NULL); inside your WM_PAINT handler. Passing NULL validates the whole window, and stops Windows from sending any more WM_PAINT messages.
Also, you don't need a break command in an if statement.
Plus, the processing you're doing there is best done inside your WindowProc, not the message loop.
Author
i'll go look for it, thanks iNsAn1tY,
another one ;)
why is "SwapBuffers" so awesome slow, it's even slower then the rest, can i improve performance there,
thx
tgar
another one ;)
why is "SwapBuffers" so awesome slow, it's even slower then the rest, can i improve performance there,
thx
tgar
That'll be because a glSwapBuffers(..) command flushes the pipeline. So it only returns once the GPU has nothing left to do. If you give the GPU a lot to do, that might take some time depending on how you have it all setup.
Author
yeah,
but i heard that after the glswapbuffer i can do much cpu processing while the gpu is busy,
but why then the command lasts so long, i mean, the cpu waits, it should do something or??
greets
tgar
but i heard that after the glswapbuffer i can do much cpu processing while the gpu is busy,
but why then the command lasts so long, i mean, the cpu waits, it should do something or??
greets
tgar
If you switch it around then you can do this. So just before you start rendering, call glSwapBuffers(..). Then render everything, and after this is done do NOT call glSwapBuffers(..). Now perform all your other calculations (AI, gamelogic, etc) while the GPU is busy. Then when you are ready to render again, you'll call glSwapBuffers(..) again just before rendering. This should give you the maximum amount of parallellism.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
