CHARTEVENT_CHART_CHANGE в MQL5 - страница 5

[pivalexander]

Slava #:

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

ChartSetInteger(0, CHART_EVENT_MOUSE_WHEEL, false);
ChartSetInteger(0, CHART_EVENT_MOUSE_MOVE,  false);

К сожалению ни как не повлияло, в этом примере -> https://www.mql5.com/ru/forum/383101/page4#comment_26351874

[Slava]

pivalexander #:

К сожалению никак не повлияло, в этом примере -> https://www.mql5.com/ru/forum/383101/page4#comment_26351874

Насколько активен график? В смысле поступления тиков

[Slava]

И я не увидел в комментарии характеристики тормозящего компа. 386DX?

И одновременно работающих программ. Defender?

[Slava]

Частота? Сколько ядер? Физических. Гипертрединг? Сколько оперативы?

[pivalexander]

Slava #:

И я не увидел в комментарии характеристики тормозящего компа. 386DX?

А зачем? сравнение идет же не с каким то эталоном, а в рамка одной системы 

[Nikolai Semko]

Ilyas #:
Вы меня удивляете, без лока нельзя гарантировать консистентность/целостность прочитанных данных

Цена такой гарантии слишком высока. 
В результате самый высокопроизводительный терминал МТ5 воспринимается многими юзерами, как лагающий из-за лагов пользовательской графики. Это факт.
На 100% уверен, что это легко исправить, т.к. таких лагов нигде не встречал. Даже в браузере более медленный JS при ресайзе окна вообще не выдает лагов.

Позвольте мне пофантазировать как можно решить вопрос гарантии консистентности/целостности прочитанных данных.

1. Не генерировать общее событие  CHARTEVENT_CHART_CHANGE для потока GUI терминала и для потока эксперта с его пользовательским GUI, а для эксперта генерировать синтетический  CHARTEVENT_CHART_CHANGE только после прихода реального CHARTEVENT_CHART_CHANGE в GUI терминала и заполнения shared memory необходимой структурой характеристик чарта.
2. Если по какой-то причине первый вариант не реализуем в вашей имплементации, то, например, чтобы не создавать проблемы существующим программам можно в MQL5 добавить:
    - новую структуру данных (скажем MqlChartInfo)
    - и функцию GetChartInfo(long  chart_id, int   sub_window=0), которая возвращает эту структуру из shared memory.
   И пусть в документации будет указано, что данная функция не гарантирует актуальность данных и программисту нужно позаботиться об этом.
   В таком случае, я, как разработчик MQL5 кода, могу создать собсвенную библиотеку с генерацией собственного пользовательского CHARTEVENT_CHART_CHANGE, контролируя изменения структуры MqlChartInfo  через таймер. Такой вариант все равно будет дешевле существующих асинхронных функций на несколько порядков ( думаю в 10000 раз). И у меня, как программиста, теперь хоть появляется возможность создать нелагающий пользовательский интерферс. Сейчас такой возможности нет.
   Более того, в этом случае можно решить еще одну проблему - сепарации события  CHARTEVENT_CHART_CHANGE. На форуме часто слышал жалобы программистов, что событие  CHARTEVENT_CHART_CHANGE слишком обобщенное и требует разделения. Ведь, например, если у меня мой пользовательсткий GUI не имеет привязки к цене чарта, и приходит событие  CHARTEVENT_CHART_CHANGE, то я не знаю - пришел новый бар или произошол ресайз окна, и мне приходится все равно перерисовывать весь свой GUI даже в том случае, когда это вовсе не обязательно. 
   
   

ЗЫ Я недавно на одном форуме, где в основном тусуются американские и англоязычные трейдеры, запостил одно видео(ссылку на пост сброшу Вам в личку), в котором использовал свой канвасный индикатор и в котором не видно было, что за платформа использовалась. За сутки этот пост собрал почти 200 комментариев и многие пишут, что ничего подобного не видели и спрашивали  в личке, как я это сделал и что это за инструмент. 
Это стало благодаря тому, что MQ действительно создало крутую среду разработки. Но без лагов ChartGet функций это бы было заметнее круче. 
Короче - для более успешного продвижения вашей платформы нужно решать эту проблему тормознутых ChartGet функций и тогда раскроется весь скрытый потенциал.

[Ilyas]

Перепроверил код

Подавляющее большинство свойств своего чарта (чарта на котором работает эксперт), запрашиваются в обход очереди сообщений эксперта

Ниже список свойств, которые в любом случае запрашиваются через очередь:

• CHART_WINDOW_IS_VISIBLE
• CHART_HEIGHT_IN_PIXELS
• CHART_WINDOW_TOP 
• CHART_FIRST_VISIBLE_BAR
• CHART_PRICE_MIN (при условии, что задано не нулевое подокно)
• CHART_PRICE_MAX (при условии, что задано не нулевое подокно) 

[Vitaly Muzichenko]

Ilyas #:

Перепроверил код

Подавляющее большинство свойств своего чарта (чарта на котором работает эксперт), запрашиваются в обход очереди сообщений эксперта

Это обобщённо эксперт, или только советник? Основное рисование идёт в индикаторах, в советниках наверное только в утилитах.

Вам не сложно провести тот-же тест, но в индикаторе и выявить тормозные функции? Спасибо!

[Ilyas]

Vitaly Muzichenko #:

Это обобщённо эксперт, или только советник? Основное рисование идёт в индикаторах, в советниках наверное только в утилитах.

Вам не сложно провести тот-же тест, но в индикаторе и выявить тормозные функции? Спасибо!

Только для совертиков и скриптов и только при условии, что в очереди нет асинхронных комманд ожидающих выполнения, например выставление свойства чарта или свойства объекта на нём.

Индикаторы и сервисы только через очередь сообщений

[Nikolai Semko]

Ilyas #:

Только для совертиков и скриптов и только при условии, что в очереди нет асинхронных комманд ожидающих выполнения, например выставление свойства чарта или свойства объекта на нём.

Индикаторы и сервисы только через очередь сообщений

Ах!

Я конечно же имел имел ввиду индикатор.

Это хорошие новости и, к своему стыду, в советнике ещё не пробовал использовать пользовательский ГУИ.  Точнее начал писать один проект только несколько дней назад. Был уверен, что работа Chart get функций везде одинаковая.

Сегодня это перепроверю.

Этот факт сильно меняет дело.

Собственно уже давно понял, что индикаторы мне не нужны, а только эксперты в силу одного процесса. Как я сразу не додумался это проверить. Ах!