Sulphide
Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Заметил какое-то странное поведение TStopwatch... Алгоритм работы приложения такой - рисую OGL по таймеру(небольшой шейдер и glDrawElements). В процедуре таймера стоит вызов процедурки display, а в её начале и конце соответственно начинается и заканчивается замер времени на выполнение рисования, результат пишется в глобальную переменную, откуда читается еще одним таймером 10 раз в сек и выводится на форму (чтобы не мешать замеру основного алгоритма)... Так вот, если я ставлю 15 миллисекунд для таймера рисования (~60fps) то получаю 16 миллисекунд по замеру с редкими падениями до 12 или правильных 0 миллисекунд. Если я ставлю 29 миллисекунд для таймера рисования (~30fps), то значения возвращаются к правильному нолику. В реальности около 800 микросекунд, которые я дублем для проверки получаю через QueryPerformanceCounter. Ну и 800 микросекунд TStopWatch округляет до 0 миллисекунд. Соответственно вопрос - что за фигня?)) зы пока писал до меня доперло, что GL в винде ограничен 60 fps и соответственно, если приложение дает больше fps, даже чуть-чуть, то glSwapBuffers вставляет необходимую задержку сам... пардон, может кому тоже пригодится. Надо измерять до glSwapBuffers и ему подобных, а не после или отключать синхронизацию. В итоге получил вообще ~60 микросекунд, что просто супер быстро. зыы а еще такое ощущение, что основной поток зарезан на ~60hz... потому как у меня не получается в нем выводить простенькую сцену GL выше 65 fps, что бы я не ставил в timer interval.. синхронизация GL отключена и в приложении и в дровах невидии.. | Всего записей: 277 | Зарегистр. 20-03-2008 | Отправлено: 04:44 07-08-2018 | Исправлено: Sulphide, 07:45 07-08-2018 |
|