Ограничение на количество отображаемых свечей на графиках

им кстати, уже задавали такой вопрос - на что они ответили: переходите на старшие таймфреймы...:)))))))

Полностью поддерживаю это пожелание!

Тем более что квик сейчас вполне способен отобразить на графике как минимум в 100 раз больше свечей - это видно при построении тиковых графиков.

Ладно. не хотите так - вот вам линк-> ask Big Bill

графики в квике - это окна. Чтобы нарисовать свечу в окне нужно одновременно задействовать порядка 10-ти объектов GDI (карандаши, кисти, регионы и т. д. и т. п.). Существует ограничение по числу объектов GDI на один контекст и уж тем более на одно окно-график.
А теперь, умножьте количество объектов GDI на 3000. И это, не говоря про то сколько это сожрёт памяти, а также быстродействия - т.к. оконная функция будет по времени съедать весть "тред" (поток, а в квике, судя по всему, главный поток).

Чтобы как-то исправить данную ситуацию и отказаться от наклёвывающейся потери производительности - разработчики квика со временем отказались от функции показа "хинта" при наведении на тень свечи, скорей всего, банально заменив расчёт региона на расчёт прямоугольника свечи (ptInRgn на ptInRect), а также, при показе всего графика - они не показывают все свечки и, соответственно, не рассчитывают по ним регионы, а делают из, скажем 2-х, 4-х свечей - одну полоску (представленную в памяти, как один логический объект) - это если не все свечи физически могут поместиться на графике (к тому же известно, что минимальная ширина свечи равна 1 пиксель). Можно, конечно и дальше продолжать упорствовать и вдаваться в пространственные обсуждения, что вот мол, де, для того и придумали полосы прокрутки (scrollbox) - но с точки зрения windows и программиста - это ничего не меняет, т.к. отображая даже часть общего количества свечей - надо, как говорится, со сроком "вчера" - уже думать над кешированием новых объектов, а как уже говорилось, время работы оконной процедуры и ресурсы ОС должны быть сведены к минимуму. Отдав/выделив это дело в отдельный поток - графики перестанут быть адекватными (строго говоря, они итак невсегда адекватны), а с ними и стиль торговли, жёстко привязанный к показаниям графиков перестанет отражать реальную рыночную ситуацию. т.к. windows - это не система жёского реально времени и время выделяемое под каждый тред нигде не фиксировано (по документации максимальное время гарантированного переключения между тредами может доходить до 5 сек, а вреальности и того больше)
(говорю максимально усечённо, т.к. тут не форум по программированию, а я в свою очередь, не программист)

таким образом, чтобы не терять в потери производительности - они остановились на этом варианте.


как-то вот так... ;)

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

точные замеры тут не имеют смысла.

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

Добрый день,

Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что реализация пожелания признана потенциально целесообразной. Если по результатам дальнейшего анализа, включающего юридические аспекты, анализ на непротиворечивость с общей политикой компании, никаких возражений не возникнет, мы постараемся включить Ваше пожелание в план доработок при выпуске одной из следующих версий нашего ПО.

Разумному человеку не придёт в голову запускать на компьютере одновременно сотню приложений, если на компьютере всего 1Гб памяти. Есть большая вероятность, что Windows, если не "упадёт", то, как минимум, "зависнет".
Так и с QUIK. Вам дают инструмент, а как его использовать - решаете вы сами. Вы можете наоткрывать кучу таблиц/графиков, но если вы переоцените возможности своего компьютера, то результат будет соответствующий.

поверьте, в современных новомодных операционных системах - не одна сотня процессов/сервисов работает в системе - так что, от этого пока ещё никто не ушёл. А так, - конечно, всегда проще предложить купить более мощный компьютер, зная, что клиенту будет просто некуда деваться.

боюсь, что если это будет сделано - то сделано, как с "авточартистом" - он вроде, как тебе не нужен - но, хрен ты от него избавишься.

а кто сказал, что он статический???
объект - свеча:
имеет координаты
может менять положение
может менять размеры
может реагировать на движение курсора (показ хинта)
может реагировать на клик мышки (ну типа вывод меню или отправка транзакции)
и т. д.

Наверное, все-таки не всех, а только тех, которые видны на графике в данный момент. Обычно это меньше, чем 3000.

Не надо троллить - вы поняли о чём я. Большинство работающих в фоне процессов/сервисов отъедают менее 10Мб ОЗУ и 0% ЦП.

Ну, да, тут вы правы. Но это ничто по сравнению с полигональными моделями в 3D играх, ведь так?
У меня к примеру графики обновляются не чаще 1 раза/сек.
К тому же, возможно я ошибаюсь, но полагаю, что на неактивных вкладках или свёрнутых окнах обновления графиков не происходит.

Если это так, то снятие ограничения в 3000 свечей не должно повлиять на производительность, если только не показан весь график целиком.

я, конечно, бесспорно, могу во многом ошибаться - и с радостью выслушал бы интервью "от создателей":)) но... они почему-то всегда ускользают от подобных тем... :)))