Мой подход. Ядро - Движок. - страница 125
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Так они перерисовываются именно так, как вы сказали.
А нагрузка на процессор возникает при анимации :
Здесь происходит постоянная переинициализация значений в массиве пикселей. Каждый 16 миллесекунд. Это нагружает процессор до 40%.
Я пытался понять, что именно нагружает. Думал, сохранение ресурса или его чтение. Оказалось, что именно переинициализация массива в цикле рисования.
Также оказалось, что постоянный вызов ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1); (Каждый 16 миллесекунд) тоже нагружает процессор. Примерно на 10%.
Этот вызов я использую для сообщения другому советнику, что ему нужно прочитать ресурс с данными анимации.
В сумме, получается +~50% нагрузки на процессор при анимации.
Извините, не заметил, что речь уже не идет о списке открытых сделок. Исчезли, кажется, 2-3 страницы темы.
Да нет, все в порядке. Просто я заговорил о нагрузке на процессор, потому что собираюсь переделать связь между советником и движком, а значит и таблица открытых сделок тоже будет принимать данные иначе.
зачем делать перирисовку 64 кадра с секунду(16 мс), для глаз достаточно 32 кадра в секунду.
Хороший вопрос. На самом деле, таймер не работает плавно. Бывают пропуски. 16,32,16,16...
Если использовать 32, то пропуски составят 64 мс. А это заметно. К тому же, разные другие вещи тоже нагружают и тормозят рисование. Например, очередь событий OnChartEvent().
Думаю, это влияет на качество анимации. Я пробывал использовать 25 мс. Потом 16, и пришел к выводу, что 16 лучше передает плавное движение.
Позже скину движок с анимацией 16 мс и 32 мс и ты сам увидешь. Хотя, может будет нормально....
Хороший вопрос. На самом деле, таймер не работает плавно. Бывают пропуски. 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 мс.
Почему? Просто, интересно.
Почему? Просто, интересно.
просто на самом деле не 16 мс, а 1000/64=15.625 мс. Поэтому лучше ставить не 32, а 30 мс, тогда пропусков будет меньше. Т.е. если паузу между кадрами поставить 33 мс, то реальная пауза будет 15.625×3=46.875 мс.
Хорошо, учту.
Снижение частоты таймера, конечно, уменьшит нагрузку на процессор. Если это не ухудшит качество анимации, то отлично. Нагрузка на процессор может снизиться до 30 процентов, но все равно будет.
Придется с этим мириться.
Правда, если бы рисование распределить между разными потоками, (например часть анимации рисует советник, а часть движок), то нагрузка бы почти снялась бы. Надо подумать...
Увы, мое предположение не подтвердилось.
Сейчас проделал эксперимент, - поставил один советник на два графика. Советник нагружает процессор на 50 процентов.
Оказалось, что даже работая на разных графиках, нагрузка на процессор суммируется, и общая нагрузка на процессор со стороны МТ, достигла более 90 процентов.
Значит, даже разделение рисования между разными советниками не поможет. Нагрузка суммируется!
Увы, мое предположение не подтвердилось.
Сейчас проделал эксперимент, - поставил один советник на два графика. Советник нагружает процессор на 50 процентов.
Оказалось, что даже работая на разных графиках, нагрузка на процессор суммируется, и общая нагрузка на процессор со стороны МТ, достигла более 90 процентов.
Значит, даже разделение рисования между разными советниками не поможет. Нагрузка суммируется!