Canvas vs Labels - страница 7

Новый комментарий
 
Mihail Matkovskij:

А есть ли в где-нибудь информация, где можно об этом почитать подробнее? Хоть мне всё и так понятно, но всё же, тема довольно интересная! Осталось теперь сделать вариант с контролем обновлений битмапа и протестировать. Буду удивлён, если битмап окажется быстрее лейблов. 

Я вполне допускаю, что при небольшом количестве Label, их использование имеет преимущества по скорости перед канвасом, так как BitMap заполняется на C++, а не на MQL5. Хотя нет, скорей вряд-ли, формирование текста должно происходить аналогично и в канвасе, ведь формирование текстового BitMap выполняется win - функциями в обоих случаях. Думаю в случае с Label эти объекты ещё обвешиваются событийным свойствами(их же вроде можно мышкой перетаскивать) и это в конечном счете утяжеляет их конструкцию. 

 

По скорости Канваса вопрос.


Встроенная в CPU видеокарта.


Запускаю такой код.

#include <fxsaber\Usage\Usage.mqh> // https://www.mql5.com/ru/code/33875

void OnInit()
{  
  USAGE::MinInterval = 100 * 1000; // 100 ms.
  
  EventSetMillisecondTimer((int)USAGE::MinInterval / 1000);  
}

void OnTimer()
{
  _USAGE // Расчет нагрузки.

  USAGE::GraphCreate(1200, 900, 200); // Вывели график нагрузки.
}

void OnDeinit( const int )
{
  USAGE::GraphDelete(); // Удалили график нагрузки.
}

Вкратце, он замеряет, сколько времени выполняется OnTimer каждые 100 мс. При этом строит внутри OnTimer график замеров. Получается такой результат.

Отъедает 15-20%. Видимо, тормозная видеокарта. Но вопрос в другом. Если мышкой начинаю дергать ценовой график (при зажатой ЛКМ двигать влево-вправо), то нагрузка возрастает в два раза. На анимации выше это отлично видно. С чем связана такая особенность?


Еще раз повторяю. OnTimer выполняется в два раза дольше, если двигать мышкой ценовой график.

 
fxsaber:

По скорости Канваса вопрос.


Встроенная в CPU видеокарта.


Запускаю такой код.

Вкратце, он замеряет, сколько времени выполняется OnTimer каждые 100 мс. При этом строит внутри OnTimer график замеров. Получается такой результат.

Отъедает 15-20%. Видимо, тормозная видеокарта. Но вопрос в другом. Если мышкой начинаю дергать ценовой график (при зажатой ЛКМ двигать влево-вправо), то нагрузка возрастает в два раза. На анимации выше это отлично видно. С чем связана такая особенность?


Еще раз повторяю. OnTimer выполняется в два раза дольше, если двигать мышкой ценовой график.

Скорей всего в Ваших библиотеках стоит контроль CHARTEVENT_CHART_CHANGE для того чтобы в случае необходимости(если изменился размер чарта) изменить размер канваса, но чтобы это узнать нужно выполнить жутко тормозные (до сих пор) асинхронные функции ChartGet.. 
Это и приводит к тормозам.
Логичнее было бы MQ сепарировать событие CHARTEVENT_CHART_CHANGE, и сделать отдельно, наприме, CHARTEVENT_CHART_SIZE_CHANGE. Уж больно много в событие CHARTEVENT_CHART_CHANGE напихано: приход нового бара, скролинг баров, изменение масштаба цены по вертикали, изменение размеров окна.

 
Nikolai Semko:
Я вполне допускаю, что при небольшом количестве Label, их использование имеет преимущества по скорости перед канвасом, так как BitMap заполняется на C++, а не на MQL5. Хотя нет, скорей вряд-ли, формирование текста должно происходить аналогично и в канвасе, ведь формирование текстового BitMap выполняется win - функциями в обоих случаях. Думаю в случае с Label эти объекты ещё обвешиваются событийным свойствами(их же вроде можно мышкой перетаскивать) и это в конечном счете утяжеляет их конструкцию. 

Действительно, лейблы могут быть быстрее. Смотря, сколько их в чарте... Сделал контроль обновлений и, действительно, был удивлён результатами. Ограничение взял из минимальной частоты кадров, приятной для глаза, 24 fps, если не ошибаюсь. Получилось, примерно, 41 миллисекунда. Поставил ограничение для Канваса и, о чудо, я был удивлён. Он просто летает, по сравнению с беспощадным обновлением лейблов! Но когда я поставил такое же ограничение для дисплея на Лейблах, то он стал работать еще быстрее дисплея на основе Канваса. Но не буду забегать наперед, все результаты тестирования представлю позже.

 
fxsaber:

Если мышкой начинаю дергать ценовой график (при зажатой ЛКМ двигать влево-вправо), то нагрузка возрастает в два раза. На анимации выше это отлично видно. С чем связана такая особенность?

с событийной моделью Windows - даже если быстро перемещать мышку, то начинает возрастать нагрузка на процессор, не важно какое приложение было в фокусе

ЗЫ: проверил в диспетчере задач Вин10... почему то не показывает увеличение нагрузки на процессор, в Вин7 точно на этом же П возрастала нагрузка если быстро двигать мышей - сомневаюсь, что Вин10 кардинально поменяли событийную модель, скорее всего диспетчер задач по другому работает 

 
Nikolai Semko:

Скорей всего в Ваших библиотеках стоит контроль CHARTEVENT_CHART_CHANGE для того чтобы в случае необходимости(если изменился размер чарта) изменить размер канваса, но чтобы это узнать нужно выполнить жутко тормозные (до сих пор) асинхронные функции ChartGet.. 
Это и приводит к тормозам.
Логичнее было бы MQ сепарировать событие CHARTEVENT_CHART_CHANGE, и сделать отдельно, наприме, CHARTEVENT_CHART_SIZE_CHANGE. Уж больно много в событие CHARTEVENT_CHART_CHANGE напихано: приход нового бара, скролинг баров, изменение масштаба цены по вертикали, изменение размеров окна.

Ничего этого нет в коде выше.

 
Igor Makanu:

с событийной моделью Windows - даже если быстро перемещать мышку, то начинает возрастать нагрузка на процессор, не важно какое приложение было в фокусе

ЗЫ: проверил в диспетчере задач Вин10... почему то не показывает увеличение нагрузки на процессор, в Вин7 точно на этом же П возрастала нагрузка если быстро двигать мышей - сомневаюсь, что Вин10 кардинально поменяли событийную модель, скорее всего диспетчер задач по другому работает 

Спасибо, не знал. Удивило, что мышка способна в два раза тормозить MQL-программу.

ЗЫ Такой результат только у меня?
fxsaber:

Отъедает 15-20%. Видимо, тормозная видеокарта.

 
fxsaber:

Спасибо, не знал. Удивило, что мышка способна в два раза тормозить MQL-программу.

Тогда закономерно возникновение лагов с тикам и прочим. HFT с такой событийной моделью, как минное поле.

 
fxsaber:

Ничего этого нет в коде выше.

Да, не увидел, что это внутренний чарт.
Ну судя по профилированию источник тормозов, когда происходит скролинг чарта, вот в этой строке:

Профилирование с активным скролингом:

Профилирование с активным движением мышки без скролинга(без нажатой ЛКМ):

ЗЫ: Поэтому источник тормозов все же не канвас, а объекты.

 
Mihail Matkovskij:

Можно было проверить и на чарте. Однако я посчитал, что в тестере это будет сделать проще.

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

Получается, как Вы сказали, на отрисовку текста в лейблах уходит больше времени чем на отрисовку OBJ_BITMAP_LABEL.

Я этого не говорил.

Я указал на очевидные ошибки и объяснил как работает система отрисовки.

1234567891011121314...18
Новый комментарий