Мой подход. Ядро - Движок. - страница 125

 
Реter Konow:

Так они перерисовываются именно так, как вы сказали.

А нагрузка на процессор возникает при анимации  :

Здесь происходит постоянная переинициализация значений в массиве пикселей. Каждый 16 миллесекунд. Это нагружает процессор до 40%.

Я пытался понять, что именно нагружает. Думал, сохранение ресурса или его чтение. Оказалось, что именно переинициализация массива в цикле рисования.


Также оказалось, что постоянный вызов ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1); (Каждый 16 миллесекунд) тоже нагружает процессор. Примерно на 10%. 

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

В сумме, получается +~50% нагрузки на процессор при анимации.

Извините, не заметил, что речь уже не идет о списке открытых сделок. Исчезли, кажется, 2-3 страницы темы.
 
Vladimir:
Извините, не заметил, что речь уже не идет о списке открытых сделок. Исчезли, кажется, 2-3 страницы темы.

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

 
зачем делать перирисовку 64 кадра с секунду(16 мс), для глаз достаточно 32 кадра в секунду.
 
Nikolai Semko:
зачем делать перирисовку 64 кадра с секунду(16 мс), для глаз достаточно 32 кадра в секунду.

Хороший вопрос. На самом деле, таймер не работает плавно. Бывают пропуски. 16,32,16,16...

Если использовать 32, то пропуски составят 64 мс. А это заметно. К тому же, разные другие вещи тоже нагружают и тормозят рисование. Например, очередь событий OnChartEvent().

Думаю, это влияет на качество анимации. Я пробывал использовать 25 мс. Потом 16, и пришел к выводу, что 16 лучше передает плавное движение.

Позже скину движок с анимацией 16 мс  и 32 мс  и ты сам увидешь. Хотя, может будет нормально....

 
Реter Konow:

Хороший вопрос. На самом деле, таймер не работает плавно. Бывают пропуски. 16,32,16,16...

Если использовать 32, то пропуски составят 64 мс. А это заметно. К тому же, разные другие вещи тоже нагружают и тормозят рисование. Например, очередь событий OnChartEvent().

Думаю, это влияет на качество анимации. Я пробывал использовать 25 мс. Потом 16, и пришел к выводу, что 16 лучше передает плавное движение.

Позже скину движок с анимацией 16 мс  и 32 мс  и ты сам увидешь. Хотя, может будет нормально....

просто на самом деле не 16 мс, а 1000/64=15.625 мс. Поэтому лучше ставить не 32, а 30 мс,  тогда пропусков будет меньше.  Т.е. если паузу между кадрами поставить 33 мс, то реальная пауза будет 15.625×3=46.875 мс. 
И нужно не забывать, что в МТ свой внутренний обработчик обновления чарта, поэтому ChartRedraw будет работать ассинхронно и нет гарантии, что МТ будет отрабатывать их все.

 
Nikolai Semko:
просто на самом деле не 16 мс, а 1000/64=15.625 мс. Поэтому лучше ставить не 32, а 30 мс,  тогда пропусков будет меньше.  Т.е. если паузу между кадрами поставить 33 мс, то реальная пауза будет 15.625×3=46.875 мс. 
И нужно не забывать, что в МТ свой внутренний обработчик обновления чарта, поэтому ChartRedraw будет работать ассинхронно и нет гарантии, что МТ будет отрабатывать их все.

Почему? Просто, интересно. 

 
Алексей Тарабанов:

Почему? Просто, интересно. 

Просто эти выводы сделал после многих экспериментов и метода научного тыка. Если у кого-то найдутся эксперименты, которые опровергнут мои утверждения,  то буду весьма благодарен.
 
Nikolai Semko:
просто на самом деле не 16 мс, а 1000/64=15.625 мс. Поэтому лучше ставить не 32, а 30 мс,  тогда пропусков будет меньше.  Т.е. если паузу между кадрами поставить 33 мс, то реальная пауза будет 15.625×3=46.875 мс. 
И нужно не забывать, что в МТ свой внутренний обработчик обновления чарта, поэтому ChartRedraw будет работать ассинхронно и нет гарантии, что МТ будет отрабатывать их все.

Хорошо, учту.

Снижение частоты таймера, конечно, уменьшит нагрузку на процессор. Если это не ухудшит качество анимации, то отлично. Нагрузка на процессор может снизиться до 30 процентов, но все равно будет.

Придется с этим мириться.

Правда, если бы рисование распределить между разными потоками, (например часть анимации рисует советник, а часть движок), то нагрузка бы почти снялась бы. Надо подумать...

 

Увы, мое предположение не подтвердилось.

Сейчас проделал эксперимент, - поставил один советник на два графика. Советник нагружает процессор на 50 процентов. 

Оказалось, что даже работая на разных графиках, нагрузка на процессор суммируется, и общая нагрузка на процессор со стороны МТ, достигла более 90 процентов.

Значит, даже разделение рисования между разными советниками не поможет. Нагрузка суммируется!

 
Реter Konow:

Увы, мое предположение не подтвердилось.

Сейчас проделал эксперимент, - поставил один советник на два графика. Советник нагружает процессор на 50 процентов. 

Оказалось, что даже работая на разных графиках, нагрузка на процессор суммируется, и общая нагрузка на процессор со стороны МТ, достигла более 90 процентов.

Значит, даже разделение рисования между разными советниками не поможет. Нагрузка суммируется!

Если это МТ4, то да. 
МТ5, как я понимаю, поддерживает полноценно многоядерность и многопоточность в отличии от МТ4.