🔒 Locked

Direct3D processing question

Started by Klaatu Jan 22, 2004 at 9:29 AM 3 replies 350+ views

Original Post

Jan 22, 2004 at 9:29 AM

I''m dealing with some code that, at one point, tries to render a primitive about 8 times consecutively. It does this to change various attributes of the primitive (ie. its color). At the same time, there is various other code executing in the application. I have found that with this much consecutive rendering, it appears like Direct3D stalls or buffers the calls. I say this because I don''t get the complete results of the rendering immediately. I have to execute an application provided "repaint" mechanism to see the final rendering. Can anyone take a guess as to what is happening here? Does Direct3D buffer calls if it gets too many to handle? Am I experiencing some sort of "stall"? What is the best resolution? Gort...Klaatu, Barada Nikto!

Namethatnobodyelsetook

118

Namethatnobodyelsetook

Jan 22, 2004 at 9:36 AM

It''s called double buffering. If your monitor showed what was currently being drawn it would be a mess. You''d see parts that were cleared to a background color, parts where only half the meshes are drawn, etc. Instead you draw to a second buffer that''s off screen. You then tell D3D to present the backbuffer, basically swapping front and back buffers, which will be the mysterious "repaint" mechanism.

Klaatu

Author

Klaatu

Jan 22, 2004 at 9:45 AM

Thanks for the quick reply. I''m not sure I understand the context of your reply. Maybe I should have provided more information. I am using a D3DSWAPEFFECT_COPY when I Present() the back buffer to the front. I would expect that when Present() executes that I would see the front buffer update immediatedly. As I stated, that''s not the case. It''s left me baffled as to what could be causing this. Given the above information, do you still hold to the "double buffeing" explanation? If so, how can I ensure that the back buffer has successfully rendered to the front when I Present() it?

Gort...Klaatu, Barada Nikto!

Namethatnobodyelsetook

118

Namethatnobodyelsetook

Jan 22, 2004 at 9:57 AM

Ok. Yes D3D does buffer commands (so does OpenGL... it''s how modern cards work). With most drivers, D3D can buffer upto 3 frames of rendering calls, so yeah, Present isn''t necessarily going to present right away. It has to wait for drawing to finish, then it might have to wait for vsync, depending on your flags.

It definately doesn''t need to hit a Windows message loop, or a WM_PAINT or anything like that. I''ve written test apps that are a tight loop querying the mouse with GetCursorPos, clearing, drawing, and presenting, and it run and renders fine.

NatasDM

Jan 22, 2004 at 10:11 AM

quote:
Original post by Klaatu
I have to execute an application provided "repaint" mechanism to see the final rendering.

Are you using your own window or a window from someone else's project.

I'm asking because it sounds like retained mode drawing or a GUI style update.

If you rolled your own, then maybe you are updating the frame in the "OnPaint()" Function, which is a bad Idea. Onpaint is for GUI elements of the client (or Non-CLient NCPAINT).

Try putting your present() in a timer function with an elapse time of 0 ms. Or OnIdle()

[edited by - natasdm on January 22, 2004 11:13:09 AM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.