Re: How to save processing when repeating unchanged images?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Paul Roussin wrote:
Play a DirectX game and see what is possible. There is no way you will come even close to producing the work load these games have. If what you have is fast enough then why do something else? Is what you are doing fast enough? DirectX will be much faster than what you need but you have to learn an awful lot about it and should work up through the tutorials from beginning to end.

I don't think you can just ask for people to solve your problems with solutions or sample, you can only ask for guidance, but you have to do the work. I would take six months to a year off your current project and go to work learning. If what you have is fast enough then all the work will be for no gain.

DirectX can do what you want and do it very fast.

Best regards,
Paul



"Capt Laser Man" <CaptLaser@xxxxxxxxxxxxxx> wrote in message news:F42CCA0B-6E1F-446C-9C59-DCE4E2E0693B@xxxxxxxxxxxxxxxx
Maybe one of you can suggest the best way to go here. My D3D code is simple
and draws simple colored triangles and lines. The content of each scene may
only change once in a while so I don't want to do all the work each time I
need to repaint.
Why? Is it drawing too slow? GPUs are screaming fast. There's nothing
wrong with asking it to redraw the scene each time the window needs
refreshing.
The reason why is because I may have to render 100 or so (maybe more, maybe less) mini screens on the monitor at one time. I add a thumbnail view of the selected laser file in a scrolling window so that the user can choose the one the want. When the users scrolls the window, each control has to repaint so 100 or more mini screens have to update at once. In GDI+, it was faster to paste 100 bitmaps during an update than to redraw 300,000 lines. Maybe DirectX can handle it? I have not tried, yet. Also, I am not even sure I can have 100 seperate DirectX windows open at one time since each needs a Device handle. Is that possible? I'm just looking for the fastest way to draw and am open to suggestions.



With all due respect, your answer is unresponsive to Capt Laser Man's question, as is Richard's.

Both of you are saying the problem doesn't exist or shouldn't exist. GPUs are screaming fast, and games place heavy demands on them, but not all applications are games, so concluding that an approach used for playing games is universally appropriate to all applications is erroneous.

For example, I have customers who construct air traffic control animations. At any given point in time, there may be upwards of 5,000 aircraft on the screen. On a fast CPU with really good graphics hardware, such animations can run at the monitor's refresh rate, e.g., 60Hz. Exploiting shader version 3 instancing is necessary for optimal performance. However, on lesser machines (typically laptops) 60Hz. performance is impossible, even when paying the utmost care to using techniques such as shader 3 instancing. Things can bog down to 30Hz., 20Hz, or even 15Hz., which looks really bad.

Now the interesting question is "How complex can the backdrop over which the planes fly be?" Is 100,000 triangles too complex? 200,000? 300,000? Clearly, at some level of complexity, if the entire backdrop is drawn every frame, the hardware's capabilities will be overtaxed.

I have often questioned the possibility of rendering the background to a separate target and Z-buffer and using StretchRect to copy the predigested backdrop to each frame at the outset of construction of each frame. Video memory to video memory copies ought to be extremely fast, so it's entirely possible that for extremely complex backdrops, the alternate approach would be faster than redrawing everything.

Of course, if the camera is moving, there's no choice but to redraw everything, but if the camera is stationary, Plan B is worthy of consideration. I haven't gotten around to trying it, due to a natural tendency to avoid shaking the foundations of my software, and a reluctance to wander into area of the Direct3D tarpit that I haven't yet explored.

So, let me restate Capt Laser Man's question. Assuming the problem exists, and the camera is stationary, what are the pros and cons of Plan B?

Regards,
Jim Henriksen


.

Relevant Pages

  • Re: How to detect a full screen window is using DirectX/OpenGL
    ... a DirectX context switch. ... I think more and more "fullscreen" games actually support, ... auto-hidden taskbar exceeds screen borders by 4 pixels (window border). ... that a maximizable window can be boarderless. ...
    (microsoft.public.win32.programmer.gdi)
  • Re: How to detect a full screen window is using DirectX/OpenGL
    ... There is no noticable performance penalty vs using DirectX, ... I think more and more "fullscreen" games actually support, and now default, ... auto-hidden taskbar exceeds screen borders by 4 pixels (window border). ... that a maximizable window can be boarderless. ...
    (microsoft.public.win32.programmer.gdi)
  • Re: MS Train Simulator Video Problem
    ... > would be to restore back to DirectX 8 on your system. ... >> corruption and the same two games didn't work. ... >>> ask your son-in-law if you could borrow his video card for a day or two ... >>> some corruption in either your DirectX or NVidia driver install. ...
    (microsoft.public.windowsxp.games)
  • Re: Dungeon siege 2 headaches
    ... DirectX Version: DirectX 9.0c ... Sound Tab 1: No problems found. ... Driver Version: 6.14.0010.6497 ... MS Games Help and Support Center: http://support.microsoft.com/?pr=gms ...
    (microsoft.public.games)
  • Re: Nethack screen saver...
    ... Namely games under 15K turns. ... I must say I find it a pity it is a window$ only program, ... probably works less well for a screensaver. ... they'll generate different control codes than ...
    (rec.games.roguelike.nethack)