Делаем краудсорсовый проект по Canvas - страница 33
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В том примере обычная частота обновления. Поэтому не тормозит.
В Task Manager вижу Metatrader(32 bit)
И решён ли вопрос с асинхронной обработкой данных?Может ваша причина тормозов, связана с разрядностью системы?
Ведь Metatrader теперь заточен только под x64.
И по словам разработчиков, 32 битные версии больше не релизятся.
В Task Manager вижу Metatrader(32 bit)
И решён ли вопрос с асинхронной обработкой данных?Может ваша причина тормозов, связана с разрядностью системы?
Ведь Metatrader теперь заточен только под x64.
И по словам разработчиков, 32 битные версии больше не релизятся.
Я подтверждаю что указанный мною пример Николая действительно нагружает процессор при перемещении любого из объектов в примере, особенно если это делать быстро. На 35-40% загрузка возрастает. Тест производился на 64-х разрядном процессоре, 7-й винде 64-разрядной и на МТ5 64-х разрядном.
Что подразумевается под асинхронной обработкой данных в нашем обсуждении?
В Task Manager вижу Metatrader(32 bit)
И решён ли вопрос с асинхронной обработкой данных?Может ваша причина тормозов, связана с разрядностью системы?
Ведь Metatrader теперь заточен только под x64.
И по словам разработчиков, 32 битные версии больше не релизятся.
Все эти примеры на МТ4.
МТ5 тянет значительно больше, но при неправильной перерисовке (например стакана) тоже нагружает процессор (проверял). Проблема в частоте и площади перерисовки, которые нужно всеми силами уменьшать. Если нужно перерисовать ячейку, значит - только ее. Иначе - пустой расход ресурсов, (если например, ячейку нужно перерисовывать 10 раз в секунду, то перерисовка всего канваса станет "убийством" процессора, и тормозить будет нереально.). Впрочем, это и так понятно.
Поясню. Ячейка таблицы - это три объекта - основание, текст, значек. Если содержимое ячейки меняется, то нужно сделать 3 цикла по одному участку канваса. На первом цикле перерисовываем основание, на втором - текст, на третьем - значек. Это все равно что мы увеличили площадь ячейки в три раза. Если продолжать перерисовывать в таком духе весь канвас - будет сильное торможение. Поэтому, нужно учитывать количество циклов по перерисовываемой площади канваса. На простых примитивах этого не видно, но на сложных элементах становится очевидно. Некоторые элементы включают в себя 10 объектов (поле ввода с кнопками или вып.список, или платформа окна) и можно посчитать сколько циклов по массиву канваса нужно сделать при их перерисовке. Благо, эта перерисовка не требует высокой частоты повторения.
С асинхронной обработкой вопрос не решен. Были мысли, но решения пока нет.
В общем, если делать GUI на канвасе, то из отдельно-перерисовываемых элементов. Иначе, будет быстро достигнут предел, после которого будет заметно торможение на простых операциях.
Что подразумевается под асинхронной обработкой данных в нашем обсуждении?
Ну как я понимаю простыми словами, асинхронность(гонка за ресурс) или многопоточность(выделенный ресурс).
Код примеров Николая не смотрел, но по причине отсутствия асинхронности и многопоточности в Metatrader, код перерисовки пикселей выполняется синхронно.
А у Petera обработка выводимых данных, скорее всего так же выполняется синхронно. И в обоих случаях, скорее всего всё это дело ещё обрабатывается в циклах.
Из за этого возрастает нагрузка на процессор. Для быстрого отклика с меньшей нагрузкой в моменте, необходимо обработку данных и перерисовку параллелить.
Ну как я понимаю простыми словами, асинхронность(гонка за ресурс) или многопоточность(выделенный ресурс).
Код примеров Николая не смотрел, но по причине отсутствия асинхронности и многопоточности в Metatrader, код перерисовки пикселей выполняется синхронно.
А у Petera обработка выводимых данных, скорее всего так же выполняется синхронно. И в обоих случаях, скорее всего всё это дело ещё обрабатывается в циклах.
Из за этого возрастает нагрузка на процессор. Для быстрого отклика с меньшей нагрузкой в моменте, необходимо обработку данных и перерисовку параллелить.
Не совсем)) Поясню: у меня движок подключается к пользовательской программе через ресурс. То есть, - пользовательское приложение делает свои расчеты в своем потоке, и передает данные в движок (несущий GUI), который может быть на другом графике. Тот обрабатывает события параметров и выводит их в ГУИ. То есть, получается разделение обработки на два потока. Однако, в конструкторе который опубликую этого не будет. Приложение будет включать движок внутрь себя и все будет в одном потоке. Но, нагрузка на процессор будет такой же. Просто, зависимость скорости от последовательности выполнения функций станет больше.
Не совсем)) Поясню: у меня движок подключается к пользовательской программе через ресурс. То есть, - пользовательское приложение делает свои расчеты в своем потоке, и передает данные в движок (несущий GUI), который может быть на другом графике. Тот обрабатывает события параметров и выводит их в ГУИ. То есть, получается разделение обработки на два потока. Однако, в конструкторе который опубликую этого не будет. Приложение будет включать движок внутрь себя и все будет в одном потоке. Но, нагрузка на процессор будет такой же. Просто, зависимость скорости от последовательности выполнения функций станет больше.
опять за старое...обещания,анонсы,трёп
даже уже забылось - "ядро-движок" публиковался как порядочный софт ? или как г-но, в виде аттачей к комментариям
Ну как я понимаю простыми словами, асинхронность(гонка за ресурс) или многопоточность(выделенный ресурс).
Код примеров Николая не смотрел, но по причине отсутствия асинхронности и многопоточности в Metatrader, код перерисовки пикселей выполняется синхронно.
А у Petera обработка выводимых данных, скорее всего так же выполняется синхронно. И в обоих случаях, скорее всего всё это дело ещё обрабатывается в циклах.
Из за этого возрастает нагрузка на процессор. Для быстрого отклика с меньшей нагрузкой в моменте, необходимо обработку данных и перерисовку параллелить.
Любые операции в МТ выполняются строго синхронно и этого реально не изменить пока разработчики не добавят потоки в приложение.
Весьма удивительно что разработчики стараются расширять функционал МТ в плане работы с базами данных, с питоном, с шарпом... но все это предлагают выполнять все в том же одном потоке... Просто удивительно.
опять за старое...обещания,анонсы,трёп
даже уже забылось - "ядро-движок" публиковался как порядочный софт ? или как г-но, в виде аттачей к комментариям
Молодец. В борьбе с такими как ты я черпаю вдохновение, а они всегда проигрывают.)) Ты мне отдаешь энергию и не понимаешь этого.
опять за старое...обещания,анонсы,трёп
даже уже забылось - "ядро-движок" публиковался как порядочный софт ? или как г-но, в виде аттачей к комментариям
Макс, будь сдержаннее.
Не совсем)) Поясню: у меня движок подключается к пользовательской программе через ресурс. То есть, - пользовательское приложение делает свои расчеты в своем потоке, и передает данные в движок (несущий GUI), который может быть на другом графике. Тот обрабатывает события параметров и выводит их в ГУИ. То есть, получается разделение обработки на два потока. Однако, в конструкторе который опубликую этого не будет. Приложение будет включать движок внутрь себя и все будет в одном потоке. Но, нагрузка на процессор будет такой же. Просто, зависимость скорости от последовательности выполнения функций станет больше.
Я понял смысл, приложение отдельно, GUI отдельно.
Но обработка выводимых данных в GUI, всё равно выполняется синхронно.
То есть к примеру приложение отсылает в GUI 10000 элементов, и GUI все эти элементы обрабатывает последовательно.
В этом и проблема. Необходимо в GUI параллелить обработку входящих элементов, и их вывод. Основание, текст, значок.
Тем более, что на одну ячейку выполняется три цикла.