Требуется сделать следующее — есть сигнал который непрерывно поступает в компьютер,
надо его плавно скролируя отображать на экране (похоже на загрузку ЦПУ из TaskManager).
Под сигналом остаются не движущаяся сетка и некоторые надписи. Работает все под Windows XP (Embedded)

После долгих копаний нашел одно решение — график рисуется в Overlay области и накладывается с ColorKey на основную
поверхность.
Плюс решения — полнсотью соответствует формальным требованиям
Минусы: аппаратная зависимость поддержка Overlay режима с RGB имеется только на картах ATI, поддержка ColorKey в overlay также реализована только там. Сейчас Есть желание перейти на другую платформу для встраевоемой системы, чип там попроще и такие выкрутасы не позволяет. Какие есть еще варианты решения задачи.


С уважением, Борис

Забыл сказать, что точка справа должна плавно стать точкой слева за 4 секунды.
На глаз, чтобы небыло дерганья от неравномерной скоторости надо двигать все с синхронно с
вертикальной разверткой.

Здравствуйте, Bravot, Вы писали:

B>Требуется сделать следующее — есть сигнал который непрерывно поступает в компьютер,
B>надо его плавно скролируя отображать на экране (похоже на загрузку ЦПУ из TaskManager).
B>Под сигналом остаются не движущаяся сетка и некоторые надписи. Работает все под Windows XP (Embedded)

B>После долгих копаний нашел одно решение — график рисуется в Overlay области и накладывается с ColorKey на основную
B>поверхность.
B> Плюс решения — полнсотью соответствует формальным требованиям
B> Минусы: аппаратная зависимость поддержка Overlay режима с RGB имеется только на картах ATI, поддержка ColorKey в overlay также реализована только там. Сейчас Есть желание перейти на другую платформу для встраевоемой системы, чип там попроще и такие выкрутасы не позволяет. Какие есть еще варианты решения задачи.


B>С уважением, Борис

Обычный TChart из билдера прекрасно справляется.
Overlay не нужен. Если делать самому то обычный back буфер из битмапа и bitblt на экран.
Вопрос лищь в количестве точек в единицу времени

Здравствуйте, Аноним, Вы писали:

А>Обычный TChart из билдера прекрасно справляется.
А>Overlay не нужен. Если делать самому то обычный back буфер из битмапа и bitblt на экран.
А>Вопрос лищь в количестве точек в единицу времени

Собласен.
Ещё добавлю, что если точек очень много (одна точка по Х содержит несколько точек по У), то их всех рисовать скорее всего не нужно, а нужно рисовать обычно минимальное и максимальное значение на участке (возможен вариант — пик и среднеквадратический пик). Всё это спокойно можно выводить в реальном времени.

Здравствуйте, Dimonka, Вы писали:

D>Здравствуйте, Аноним, Вы писали:

А>>Обычный TChart из билдера прекрасно справляется.
А>>Overlay не нужен. Если делать самому то обычный back буфер из битмапа и bitblt на экран.
А>>Вопрос лищь в количестве точек в единицу времени

D>Собласен.
D> Ещё добавлю, что если точек очень много (одна точка по Х содержит несколько точек по У), то их всех рисовать скорее всего не нужно, а нужно рисовать обычно минимальное и максимальное значение на участке (возможен вариант — пик и среднеквадратический пик). Всё это спокойно можно выводить в реальном времени.

TChart — ОЧЕНЬ МЕДЛЕНО.

Формальные параметры таковы 4-5 графиков занимают прямоугольник на экране где-то 800х600. Кол-во точек действительно много, поэтому для каждой координаты X рисуется вертикальная линия от min до max.
Полностью самая правая точка становится самой левой за 4 секунды. На практике проверено, что если это согласовано с вертикальной разверткой то при чакстоте свыше 50Гц на глаз дерганей (не мельканий) не заметно. И того — 50 раз в секунду перерисовывать экран.

При рисовании из обычого back-буфера надо формировать там изображение, состоящее из сетки (не подвижной), текстовой информации (не подвижной) и движущегося графика — и так накладываем в буфере фон на смещенный и подрисованный график и плюем это на экран — загрузка CPU 100% и никакой равномерности.

Здравствуйте, Bravot, Вы писали:

B>TChart — ОЧЕНЬ МЕДЛЕНО.
Согласен.

B>Формальные параметры таковы 4-5 графиков занимают прямоугольник на экране где-то 800х600. Кол-во точек действительно много, поэтому для каждой координаты X рисуется вертикальная линия от min до max.
И пересчитываются каждый раз все точки?
Если смещать экран на расстояние, пропорциональное расстоянию между исходными точками, то пересчитывать можно будет только появившийся на экране кусок — а остальное — просто сдвигать.

B>Полностью самая правая точка становится самой левой за 4 секунды. На практике проверено, что если это согласовано с вертикальной разверткой то при чакстоте свыше 50Гц на глаз дерганей (не мельканий) не заметно. И того — 50 раз в секунду перерисовывать экран.
Это явный перебор. Достаточно рисовать картинку 4-8 раз в секунду и всё должно быть хорошо видно.

B>При рисовании из обычого back-буфера надо формировать там изображение, состоящее из сетки (не подвижной), текстовой информации (не подвижной) и движущегося графика — и так накладываем в буфере фон на смещенный и подрисованный график и плюем это на экран — загрузка CPU 100% и никакой равномерности.
Потому, что явный перебор с частотой перерисовки. Ну уж если очень хочется — можно сделать 12,5 или даже 25 кадров. Но не 50-же!

С Уважением, Андрей

Здравствуйте, AndreyFedotov, Вы писали:


B>>Формальные параметры таковы 4-5 графиков занимают прямоугольник на экране где-то 800х600. Кол-во точек действительно много, поэтому для каждой координаты X рисуется вертикальная линия от min до max.
AF>И пересчитываются каждый раз все точки?
AF>Если смещать экран на расстояние, пропорциональное расстоянию между исходными точками, то пересчитывать можно будет только появившийся на экране кусок — а остальное — просто сдвигать.
Так и делается. Кстати раньше в DOS версии получили, что перерисовать график гораздо быстрее в общем случае(когда нет шума), чем двигать кусок виделпамяти, даже если это сделано аппаратно.

B>>Полностью самая правая точка становится самой левой за 4 секунды. На практике проверено, что если это согласовано с вертикальной разверткой то при чакстоте свыше 50Гц на глаз дерганей (не мельканий) не заметно. И того — 50 раз в секунду перерисовывать экран.
AF>Это явный перебор. Достаточно рисовать картинку 4-8 раз в секунду и всё должно быть хорошо видно.

B>>При рисовании из обычого back-буфера надо формировать там изображение, состоящее из сетки (не подвижной), текстовой информации (не подвижной) и движущегося графика — и так накладываем в буфере фон на смещенный и подрисованный график и плюем это на экран — загрузка CPU 100% и никакой равномерности.
AF>Потому, что явный перебор с частотой перерисовки. Ну уж если очень хочется — можно сделать 12,5 или даже 25 кадров. Но не 50-же!

Я это смотрел на практике. Если делать 12.5Гц — каждый раз график должен смещаться на ~16 пикселов, при условии что график в общем-то линия тонкая то на глаз получается очень не красивые "прыжки". При 50Гц — смещение идет на 4 пиксела в среднем и это уже не раздражает глаз.
И еще раз — графики занимают практически весь экран 15"монитора.

Здравствуйте, Bravot, Вы писали:

B>Здравствуйте, AndreyFedotov, Вы писали:


B>>>Формальные параметры таковы 4-5 графиков занимают прямоугольник на экране где-то 800х600. Кол-во точек действительно много, поэтому для каждой координаты X рисуется вертикальная линия от min до max.
AF>>И пересчитываются каждый раз все точки?
AF>>Если смещать экран на расстояние, пропорциональное расстоянию между исходными точками, то пересчитывать можно будет только появившийся на экране кусок — а остальное — просто сдвигать.
B>Так и делается. Кстати раньше в DOS версии получили, что перерисовать график гораздо быстрее в общем случае(когда нет шума), чем двигать кусок виделпамяти, даже если это сделано аппаратно.

B>>>Полностью самая правая точка становится самой левой за 4 секунды. На практике проверено, что если это согласовано с вертикальной разверткой то при чакстоте свыше 50Гц на глаз дерганей (не мельканий) не заметно. И того — 50 раз в секунду перерисовывать экран.
AF>>Это явный перебор. Достаточно рисовать картинку 4-8 раз в секунду и всё должно быть хорошо видно.

B>>>При рисовании из обычого back-буфера надо формировать там изображение, состоящее из сетки (не подвижной), текстовой информации (не подвижной) и движущегося графика — и так накладываем в буфере фон на смещенный и подрисованный график и плюем это на экран — загрузка CPU 100% и никакой равномерности.
AF>>Потому, что явный перебор с частотой перерисовки. Ну уж если очень хочется — можно сделать 12,5 или даже 25 кадров. Но не 50-же!

B>Я это смотрел на практике. Если делать 12.5Гц — каждый раз график должен смещаться на ~16 пикселов, при условии что график в общем-то линия тонкая то на глаз получается очень не красивые "прыжки". При 50Гц — смещение идет на 4 пиксела в среднем и это уже не раздражает глаз.
B>И еще раз — графики занимают практически весь экран 15"монитора.

В данном случае по-моему (если производительности хватит в принципе, так как простой тест BitBlt всего экрана у меня даёт около 80..., машина PIII, 1GHz) это сделать так:
— рисовать линии в режиме XORCOPY (когда при рисовании линии её цвет получается как результат операции исключающее или между цветом экрана и цветом линии, причём рисовать — прямо на экране). Перед рисованием нового кадра повторно нарисовать старые линни (они счезнут), после чего нарисовать новые. Если рисовать последовательно двигаясь по оси X (то есть сначала затёрли старый отрезок для данного X, а потом нарисовали новый) — то изменение не будет заметно глазом.

С Уважением, Андрей

Здравствуйте, Bravot, Вы писали:

B>Забыл сказать, что точка справа должна плавно стать точкой слева за 4 секунды.
B>На глаз, чтобы небыло дерганья от неравномерной скоторости надо двигать все с синхронно с
B>вертикальной разверткой.

Попробуй воспользоваться DirectDraw
тогда сможешь нормально привязаться к развёртке.
Ещё вопрос, что у тебя за линии на заднем фоне? Может их как картинку копировать в буффер, а затем по картинке рисовать линии, буффер выкидывать на экран?

Здравствуйте, AndreyFedotov, Вы писали:

AF>В данном случае по-моему (если производительности хватит в принципе, так как простой тест BitBlt всего экрана у меня даёт около 80..., машина PIII, 1GHz) это сделать так:
AF>- рисовать линии в режиме XORCOPY (когда при рисовании линии её цвет получается как результат операции исключающее или между цветом экрана и цветом линии, причём рисовать — прямо на экране). Перед рисованием нового кадра повторно нарисовать старые линни (они счезнут), после чего нарисовать новые. Если рисовать последовательно двигаясь по оси X (то есть сначала затёрли старый отрезок для данного X, а потом нарисовали новый) — то изменение не будет заметно глазом.

AF>С Уважением, Андрей

У данного решения есть ряд минусов:
1. Новый график рисуется чуть левее, старого слева направо, каждый раз стерая предыдущую линию в текущей координате X. В результате, так как шаг примерно 4 пиксела, изображение кривой как бы двоится.

2. При рисовании XOR если сигнал сильно зашумлен, то становится нечетабельная информация, которая стоит под графиком. Также услаждяенся рисование этой информации — так как везде приходится применять режим XOR, который не всегда согласуется с TextOut.

Я такое делал 6 лет назад на видеокарте S3Trio с использованием ее акселератора. При этом удалось решить второй минус путем деления видеопамяти на 8 плоскостей используя аппаратные возможности чипа. Так 4 первых четыре плоскости используются для вывод обычной статической графики давая 16 цветов, а 4 других зарезервированы под рисования графиков, различных сообщений по прерываниям. Тогда используя палитру можно было также настроить цвета так как нужно. Как сделать такое в Windows не знаю. При этом крайне не хочится привязываться к аппаратуре и требовать большой мощности процессора. (последние два года посетили уже все магазины, которые скупають старье в поисках нужных видеокарт). Сейчас решается вопрос о портировании решения на платформу VIA Eden Mini — такая небольшая интегрированная плата, соответствует примерно Celeron 333 под Windows XP Embedded.

И все таки у меня остается такое впечатление, что я не все понимаю и что-то упустил — ведь то что можно было сделать на старом P100 и старой видеокарте наверно можно сделать под мощной операционке на современной платформе?

Здравствуйте, Dimonka, Вы писали:

D>Здравствуйте, Bravot, Вы писали:

B>>Забыл сказать, что точка справа должна плавно стать точкой слева за 4 секунды.
B>>На глаз, чтобы небыло дерганья от неравномерной скоторости надо двигать все с синхронно с
B>>вертикальной разверткой.

D>Попробуй воспользоваться DirectDraw
D>тогда сможешь нормально привязаться к развёртке.
D>Ещё вопрос, что у тебя за линии на заднем фоне? Может их как картинку копировать в буффер, а затем по картинке рисовать линии, буффер выкидывать на экран?
Сзади рисуется сетка миллиметровая и текстовая информация о характеристики кривой.

Да, насчет DirectDraw нашел интересную штуку — если поставить

g_lpdd->WaitForVerticalBlank(DDWAITVB_BLOCKEND    , NULL);

то нагрузка на CPU возрастает процентов на 50-60%.

Здравствуйте, Bravot, Вы писали:

B>Здравствуйте, AndreyFedotov, Вы писали:

AF>>В данном случае по-моему (если производительности хватит в принципе, так как простой тест BitBlt всего экрана у меня даёт около 80..., машина PIII, 1GHz) это сделать так:
AF>>- рисовать линии в режиме XORCOPY (когда при рисовании линии её цвет получается как результат операции исключающее или между цветом экрана и цветом линии, причём рисовать — прямо на экране). Перед рисованием нового кадра повторно нарисовать старые линни (они счезнут), после чего нарисовать новые. Если рисовать последовательно двигаясь по оси X (то есть сначала затёрли старый отрезок для данного X, а потом нарисовали новый) — то изменение не будет заметно глазом.

AF>>С Уважением, Андрей

B>У данного решения есть ряд минусов:
B>1. Новый график рисуется чуть левее, старого слева направо, каждый раз стерая предыдущую линию в текущей координате X. В результате, так как шаг примерно 4 пиксела, изображение кривой как бы двоится.

B>2. При рисовании XOR если сигнал сильно зашумлен, то становится нечетабельная информация, которая стоит под графиком. Также услаждяенся рисование этой информации — так как везде приходится применять режим XOR, который не всегда согласуется с TextOut.

B>Я такое делал 6 лет назад на видеокарте S3Trio с использованием ее акселератора. При этом удалось решить второй минус путем деления видеопамяти на 8 плоскостей используя аппаратные возможности чипа. Так 4 первых четыре плоскости используются для вывод обычной статической графики давая 16 цветов, а 4 других зарезервированы под рисования графиков, различных сообщений по прерываниям. Тогда используя палитру можно было также настроить цвета так как нужно. Как сделать такое в Windows не знаю. При этом крайне не хочится привязываться к аппаратуре и требовать большой мощности процессора. (последние два года посетили уже все магазины, которые скупають старье в поисках нужных видеокарт). Сейчас решается вопрос о портировании решения на платформу VIA Eden Mini — такая небольшая интегрированная плата, соответствует примерно Celeron 333 под Windows XP Embedded.

B>И все таки у меня остается такое впечатление, что я не все понимаю и что-то упустил — ведь то что можно было сделать на старом P100 и старой видеокарте наверно можно сделать под мощной операционке на современной платформе?

Согласен.

Вот что я преложил бы.
Один раз (или редко, не чаще чем 2-4 раза в секунду) рисуем фон — текстовые пометки, линии сетки, всякую прочую статическую ерудну.
Сохраняем этот фон в буфере.
Пририсовании кадра делаем так:
C помошью BitBlt копируем малую часть буфера (не более 16-32 пикселов по горизонтали) на экран. Затем для этих пикселов прямо на экране рисуем линии графиков, потом повторяем это для следующей порции экрана.
При этом за счёт высокой скорости перерисовки мелькание заметно не будет.

Замечание если для рисования используется GDI+:
Для ускорения вывода на экран (как и операций в памяти) формат изображения должен быть CompatibleBitmap
Ширина линии должа быть 1 пиксел (линии большей ширины рисуются в разы медленее)

С Уважением, Андрей

Hello, Bravot!
You wrote on Fri, 14 Nov 2003 09:41:52 GMT:

B> Требуется сделать следующее — есть сигнал который непрерывно поступает в
B> компьютер, надо его плавно скролируя отображать на экране (похоже на
B> загрузку ЦПУ из TaskManager). Под сигналом остаются не движущаяся сетка
B> и некоторые надписи. Работает все под Windows XP (Embedded)

B> После долгих копаний нашел одно решение — график рисуется в Overlay
B> области и накладывается с ColorKey на основную поверхность.
B> Плюс решения — полнсотью соответствует формальным требованиям
B> Минусы: аппаратная зависимость поддержка Overlay режима с RGB имеется
B> только на картах ATI, поддержка ColorKey в overlay также реализована
B> только там. Сейчас Есть желание перейти на другую платформу для
B> встраевоемой системы, чип там попроще и такие выкрутасы не позволяет.
B> Какие есть еще варианты решения задачи.

Обычный ScrollDC пробовал?

Best regards,
Sergey.

Здравствуйте, Bravot, Вы писали:

B>Здравствуйте, Dimonka, Вы писали:

D>>Здравствуйте, Bravot, Вы писали:

B>>>Забыл сказать, что точка справа должна плавно стать точкой слева за 4 секунды.
B>>>На глаз, чтобы небыло дерганья от неравномерной скоторости надо двигать все с синхронно с
B>>>вертикальной разверткой.

D>>Попробуй воспользоваться DirectDraw
D>>тогда сможешь нормально привязаться к развёртке.
D>>Ещё вопрос, что у тебя за линии на заднем фоне? Может их как картинку копировать в буффер, а затем по картинке рисовать линии, буффер выкидывать на экран?
B>Сзади рисуется сетка миллиметровая и текстовая информация о характеристики кривой.

B>Да, насчет DirectDraw нашел интересную штуку — если поставить
B>

B>g_lpdd->WaitForVerticalBlank(DDWAITVB_BLOCKEND    , NULL);
B>

B>то нагрузка на CPU возрастает процентов на 50-60%.

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

Но если сетка тоже ползёт, то лучше скроллировать.