Альтернативные реализации стандартных функций/подходов - страница 13
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вот так выглядит начало блока:
Насколько я тебя понял, ты создал свой язык интерпретатор.
Примерно так?
И еще глупый вопрос:
каждое сформированное окно с различными элементами - это один ресурс или множество?
ЗЫ Хотя наверное лучшей аналогией был бы язык HTML
Как я раньше говорил - твоему детищу нужен графический конструктор. Что-то вроде, как у Андрея Баринова.
А еще видеоролики у тебя слишком длинные. С 45 минут их нужно сократить до 5 мин, а лучше до 3
А самостоятельно не пробовали найти ответ на вопрос?
Подсказка: в строке поиска google указать "DBL_MANT_DIG 53 52"
Ага, спасибо. Нашел.
1. Насколько я тебя понял, ты создал свой язык интерпретатор.
Примерно так?
2. И еще глупый вопрос:
каждое сформированное окно с различными элементами - это один ресурс или множество?
ЗЫ Хотя наверное лучшей аналогией был бы язык HTML
Как я раньше говорил - твоему детищу нужен графический конструктор. Что-то вроде, как у Андрея Баринова.
А еще видеоролики у тебя слишком длинные. С 45 минут их нужно сократить до 5 мин, а лучше до 3
1. Да, оказывается определение "интерпретатор" лучше всего подходит к тому, что я создал (хотя, в процессе создания я не имел понятия, что это такое).
2. Каждое сформированное окно, - это несколько канвасов (ресурсов). Первые два, - это платформа окна. Раньше я использовал другой метод рисования и потому некоторые детали были полупрозрачными и через них был виден график. Чтобы этого избежать, я добавил еще один канвас на задний план. Потом технология улучшилась, но канвас на заднем плане так и остался. Он "врос" в технологию и сейчас от него сложно избавиться. Но в конце концов, я уберу его, и платформа окна будет состоять из одного канваса.
Также, "поля" (переключаемые вкладками изображения), это самостоятельные канвасы. Они содержат уже готовые изображения и потому переключение происходит максимально быстро. Если бы я рисовал все на одном канвасе, неминуемо, переключение изображений было бы медленнее. Приходилось бы заново перерисовывать. В общем, подумав я пришел к выводу, что это оптимальный вариант.
3. Визуальный графический конструктор, - был и остается моей целью. Я подобрался очень близко к началу его реализации. Есть понимание его устройства. Есть все необходимые для реализации концепции. Я знаю как его сделать. Нужно только время.
ЗЫ. Особенностью моей разработки является стихийность. Я не был знаком ни с интерпертаторами, ни с языком HTML, и не знал, как они работают. Однако, это ничуть не мешает творить и создавать похожее. Думаю, если это хорошо получается, то так и буду продолжать. :)
На первый взгляд у тебя очень расточительно используется память. Хотя, возможно, я ошибаюсь.
И, как мне видится, в идеале для твоей задачи должен быть только один канвас c поддержкой прозрачности над графиком цены.
Производительности MQL5 должно быть достаточно, чтобы формировать весь интерфейс на лету, не имея готовых блоков в памяти, если грамотно кодить.
Хотя и не исключаю, чтобы для громоздких интерфейсов для увеличении производительностью придется жертвовать ресурсами памяти.
В твоем подходе вижу пока одно большое преимущество:
Тебе будет легче создать полноценный графический конструктор, т.к. легче сгенерировать разметочный код, а не сам MQL код.
Но это слоновая задача.На первый взгляд у тебя очень расточительно используется память. Хотя, возможно, я ошибаюсь.
И, как мне видится, в идеале для твоей задачи должен быть только один канвас c поддержкой прозрачности над графиком цены.
Производительности MQL5 должно быть достаточно, чтобы формировать весь интерфейс на лету, не имея готовых блоков в памяти, если грамотно кодить.
Хотя и не исключаю, чтобы для громоздких интерфейсов для увеличении производительностью придется жертвовать ресурсами памяти.
В твоем подходе вижу пока одно большое преимущество:
Тебе будет легче создать полноценный графический конструктор, т.к. легче сгенерировать разметочный код, а не сам MQL код.
Но это слоновая задача.Относительно небольшой перерасход памяти все же имеется. Ты прав. Такие объекты элементов как текст или иконка, "незаслуженно" получают ряд из 235-ти свойств в ядре, в то время, как их собственных свойств в несколько раз меньше. Главный объект элемента, а именно основание, должен иметь все 235 свойств, но объекты иконок и текстов имеют меньше свойств. Это создает перерасход памяти.
По идеи, если добавлю еще 60 ячеек к ряду главных объектов элементов, то смогу поместить в них свойства текста и иконки. Это сделает ядро "шире", но можно будет убрать две трети объектов.
Будет отличная экономия памяти и выйгрыш в скорости построения ядра. Однако, технически это трудно выполнимо. Нужно много переделывать. Пока, расход памяти и время построения вполне приемлимы. Но, нет предела совершенству...
Использовать один канвас не очень хорошая идея. Да и какой смысл? Значительно проще использовать один канвас для каждого окна, и один канвас для каждого поля. Общий канвас перерисовывать нужно значительно чаще. На каждом переключении изображения, или на каждом сдвиге окна. На прокрутке... Нужно принять во внимание, что перерисовка не всегда быстрая. Дело не в алгоритмах, а в "навороченности" графики. Объясню:
Если ты рисуешь простую прямоугольную метку (квадрат, например), то это один цикл по массиву пикселей с инициализацией нужных ячеек нужным значением (цветом).
Если ты рисуешь квадрат с рамкой, то это два цикла по массиву пикселей.
Если ты рисуешь квадрат с рамкой и иконкой, то это три цикла.
Если ты рисуешь квадрат с рамкой, у которого есть градиент поверхности и иконкой у которой есть тень, то это четыре и более цикла по массиву пикселей.
Таким образом, чем круче графика, тем больше нужно "утюжить" этот массив пикселей в циклах, создавая нужно изображение. Поэтому, чем меньше необходимость в перерисовке, тем лучше.
Один канвас на все изображения, заставит перерисовывать все беспрерывно. Поэтому, это не подходящее решение.
ЗЫ. Задача конечно слоновая, но я справлюсь. Хотя и не откажусь от помощи.))
ЗЫЫ. Спасибо за видео, вдохновляет! :)
А у тебя размер окна меняется с помощью мышки?
Если да, то красный квадратик появляется?
А у тебя размер окна меняется с помощью мышки?
Если да, то красный квадратик появляется?
Я не понял о каких квадратиках речь.
Размеры динамичного окна меняются с помощью мышки. А как иначе?
ЗЫ. Динамичное окно изначально имеет размер полного экрана. Далее, оно "обрезается" до нужных размеров. То есть, вся его динамичность реализуется в заранее установленном максимальном пространстве уже созданного битмапа.
В продолжение темы о округлениях.
Я тут узнал, что оказывается в современных процессорах Intel, поддерживающих расширенный набор системы команд SSE4.1 есть команда округления ROUND{PS, PD}. Наверняка и у AMD что-то подобное есть.
https://ru.wikipedia.org/wiki/SSE4#SSE4a
http://o-ili-v.ru/wiki/SSE4
Это что же получается - компилятор MQL5 не использует данную команду на уровне процессора? Т.к. мой процессор Intel Kaby Lake поддерживает этот набор.
А там много еще чего есть, даже скалярное умножение векторов.