::Help with timers and Directx::

Discussion in 'Tools and Software' started by pixelshader, Nov 28, 2006.

  1. pixelshader


    Nov 21, 2006
    Likes Received:
    I have a 800 X 600 window. Different regions of the windows are updated at different instances.
    I means u can think of it as a number of subwindows each getting updated at different FPS.
    Problem is that each of these subwindows maybe updated at FPS as high as 60 - 100.

    I tried to find a solution by starting different multimedia timers for each subwindow( cant use simple timers because it cant generate inturrupts at 100 fps ). But i found that with 4 subwindows it works fine at low FPS. But when i increase the FPS only 3 windows get updated.

    For such kind of application whats the best way to move ahead
  2. Graham

    Graham Hello :-)
    Moderator Veteran Subscriber

    Sep 10, 2005
    Likes Received:
    Bend, Oregon
    When I was doing something like that in my existing codebase, it would function something like the following:

    Thread A intercepts the windows idle message, this is a C#/MDX thing to figure out when is the best time to think about rendering again. This will trigger off a check to see if any render targets need updating.

    During the check, each render target figures out if it requires an update by comparing the current tick count to an internal value that stores when it should render next (which then gets incremented if a consistent framerate is desired).

    They are all put into a queue, and handed off to the processing task (on another thread!). The processing thread runs through each render target, and collects all the details of what needs to be rendered, and then hands those off (one by one) to the DX renderer task (on another thread!). The DX renderer thread works a bit like a queue, as you should only be rendering one render target at once (even though others might be processing their to-render list).

    There is some tricky work involved in synchronising these threads, and making sure you don't get out of sync by, say, putting 15 request to render the same render target in a queue.

    Now of course this is a tad overkill for your situation (I'd expect? - especially the threading, but hey I like pain) but it may give you an idea of how to go about a potential solution. The problem is everyones source code is different, and everyones design ideas and methods differ, so if I simply said 'use threads!' that may not be so helpful. However getting an idea of how someone else solves the problem in a different way may be enough prodding needed to see a good solution for your own problem :)

    If that makes sense


    Have fun

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.