Зачем это нужно, и где применить? Есть проекты, разного «калибра», и порой отладка и замеры, во время разработки сложных алгоритмов и технологий. Замерить можно что угодно: используемую память; загрузку процессора; временные затраты на определённый участок программы; и т.п. помогают для принятия решения: приемлемы ли временные затраты на расчёты или слишком затратные, а может рендер перегружен? И т.п.
Также каждый может найти и другое применение, зависящее от ситуации и потребностей в проекте.

И так, что из себя представляет временной график:

Рассмотрим на примере процентной загруженности процессора по времени:

Жёлтым цветом – процентная шкала.
Синим цветом – временная шкала.
Зелёным цветом – ломаная графика.

В данном случае, график постоянно смещается в позиции – влево.
В этом заложен основной принцип реализации графика.
Учитывая в данном примере всего 23 временных участка, обновление данных графика не ведётся каждый цикл, поэтому будет использоваться таймер, по прохождению которого, будет вноситься новое данное, последнего значения. Но т.к. в период от последнего обновления и текущего, проходит больше одного цикла, то нужно вычислить общее арифметическое данное за этот период.

И так, рассмотрим вариант с использованием массива.

Здесь мы немножко увеличим частоту обновления, но и уплотним график.
gLine#[44]
Индекс массива – временной параметр.
Значение переменной – процентный параметр.

Также нам необходимо знать индекс параметра, который мы будем изменять следующим, введём переменную:
gLastL%

И ещё один параметр, который ведёт количество циклов изменений текущего данного:
gTiks%

В примере приведена реализация слежки активности перемещения курсора мыши, по окну приложения:

Поводите мышью по области приложения, в графике будет запечатлена активность перемещения курсора.

И так, за счёт дополнительной переменной (gLastL%), принцип смещения графика был зацикленным. Есть ещё один из способов: смещение массива, в этом способе, все кроме первого, данного в массиве, перемещались на один индекс ранее, а последний, заполнялся новым данным. Такой метод менее шустр, и скорость смещения будет зависеть от количества переменных в массиве. Поэтому пришли к более быстрому способу: заполнять данными следующую переменную от последней изменённой, а рендер производить не от первого в массиве, а от следующего от текущего изменяемого (это будет самым «старым» данным).
Также в этом примере немножко сглажено изменение нового данного, исходя из прошлого.

Общая картинка несёт информацию активности использования мышки, например в РТС, это будет = активности игрока, а в FPS – холеричности игрока. Но подобная информация, в общем, является бесполезной.
Если вы не собираете онлайн информацию, об игроке для анализа. Чтобы вычислить, скучал ли игрок в определённом участке игры; что его тревожит; или, когда он начинает играть активнее, и т.п.
Разработчики из Valve, начиная с Half-Life 2: Episode I, собирали подобную информацию, для анализа поведения игрока. Исходя из совокупной подобной информации, можно вычислить, было игроку слишком сложно, или он был озадачен, в некоторых ситуациях игры. После анализа информации, разработчики могли взять что-то на заметку, и в схожих ситуациях, поступить по другому, добавить Action’а в игру, или заставить игрока «поактивничать», а может и упростить.

Чтож, вот и весь принцип построения временных графиков, статья вышла весьма короткой, и заключается в разборе Кодером, выше приведённого кода.
Почему статья тренировочная? – основной принцип начинающего кодера – найти статейку и сделать игру. Считая что, прочитав комментарии к строкам кода, он поймёт принцип и построение алгоритмов, в то время, заблуждаясь, что Он обучается. Тут же абсолютно бессмысленный кусочек кода, который не внедришь в игру – за не надобностью. Даёт возможность понять принципы построения временных графиков. Вынуждая кодера, самостоятельно разобрать код, и понять его принципы, для построения графиков с ведением уже необходимой для него информации в приложении.

Последующие мои статейки, будут в подобной тренировочной форме.