I have written an application which generates a scrolling 2D image with animation. I have a number of different Windows PCs all with 60Hz refresh displays, and the application is generating a 60Hz screen update. I have set the main thread to time-critical / realtime. Initially the application draws smoothly - easily drawing a frame per 16.6ms. But “after a while” it starts to have problems - the drawing code overruns the 16.6ms frame repeat time - and the consequences to the display are obviously horrible.
This occurs on all the platforms I have tried it on.
The scrolling can be enabled & disabled. With the scrolling never enabled, the problem never occurs (well, not within the period of time I’m willing to wait, that is). With the scrolling enabled, the problem occurs after a random (but fairly short) period (or over an apparently random part of the scrolled display, depending upon your point of view). There are different things drawn (& hence a somewhat different sequence of operations drawing “per frame”) as the display scrolls. But given the commencement of the fault doesn’t seem to be triggered by any particular part of the scrolled display, I can’t associate the problem with “this” or “that” particular part of the code.
Once the problem has occured, it appears to be permanent for that run of the application.
The frame display is coded in several service routines. I have used the QueryPerformanceCounter() between these service routines, and between successive frames, to time each of these routines & the frame delta - I have then used these to draw bargraphs across the top of the display so I have a easy to observe dynamic representation of the duration of these functions. Before the problem occurs the whole display generation code takes well under 1ms per frame. When the problem commences all these bargraphs extend significantly, and the display generation code can be seen to exceed the 16.6ms nominal frame delta.
I have used process explorer to monitor what the application is doing. I have noted one of the threads is “nvoglv32.DLl!DrvCppyContext+0x6f10”. Before the problem occurs this is consuming the bulk of the CPU of the application, and my application main thread is another significant CPU user. Once the problem occurs, nvoglv32… is no longer showing any CPU use, and my main thread CPU use shoots up.
I am hypothesising that before the problem, nvoglv32… is responsible for driving the hardware accelaraton features, but that once the problem has started, it has dropped back to generating the whole display in software. This is a guess, but given the huge increase in execution time of the the drawing code, it seems a reasonable one.
I have only investigated to this level on one machine, which happens to have a Nvdia card - other machines which show the problem have other manufacturer’s cards.
I am quite happy to accept it is something my code is doing that is causing this problem, but given I can’t find a specific trigger I’m having trouble identifying what. Any suggestions as to how to investigate this would be gratefully received.