Перейти к содержимому
Compvision.ru
вф1

Можно ли сделать чтобы информация выводимая поверх постоянно обновляемого jpeg не мигала?

Recommended Posts

Программа считывает и выводит постоянно обновляющийся jpeg-файл. Поверх собственно изображения выдается некая служебная инфа (цифры, фигуры). Так вот эта инфа периодически подмаргивает. Не всё время, т.е. это никак не связано с тем что jpeg постоянно считывается/обновляется. Можно ли что нибудь сделать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Использовать двойную буферизацию. В билдере точно есть. Включается так:

Form1->DoubleBuffered = true; // форма

DrawGrid1->DoubleBuffered = true; // компонент на котором рисуем

В VS можно почитать тут: http://msdn.microsoft.com/en-us/library/system.windows.forms.control.doublebuffered.aspx

и здесь: http://www.ucancode.net/Visual_C_MFC_Example/draw_double_buffer_gdiplus_vc_example_article.htm

http://stackoverflow.com/questions/3506661/c-double-buffer-and-memory

http://www.gamedev.net/topic/509755-double-buffering-mfc-help/

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При ручной буферизации сначала формируем полное изображение в памяти (выводим на него кадр, затем поверх кадра рисуем.пишем GDI шными средствами) и BitBlt - или что нибудь в этом духе. Если я вопрос правильно понял.

Если встроенная как в билдере, то просто надо рисовать в событии компонента onPaint и отключить автоотрисовку компонента (не помню навскидку как называется, но по названию понятно что это оно :) ).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну я так понял, что в GDI например линия рисуется "поверх" картинки, т.е. не в память картинки.

не знаю как текст.

вообще есть какая то разница рисовать прямо в память или поверх как то в 2 слоя все выводить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В GDI всё рисуется на контексте устройства - HDC. А в памяти или не в памяти - не важно.

Рисование в памяти с двойной буферизацией позволяет:

1. Избежать мерцания при перерисовки большого числа объектов. Я думаю, понятно почему оно возникает.

2. Ускорить процесс прорисовки. Тут можно остановиться немного подробней. Дело в том, что некоторые операции имеют аппаратное ускорение, а некоторые - нет. Например, BitBlt (вывод на экран изображения) использует аппаратное ускорение, поэтому выполняется очень быстро. А рисование линии - нет. Поэтому рисовать линию в видеопамяти нежелательно, лучше делать это в системной памяти, а после копировать результат через BitBlt.

  • Like 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

смысл двойной буферизации в том чтобы сформировать N фигур в одной памяти, а потом сразу скопировать это в выводимую память?

лучше делать это в системной памяти

что это значит? т.е. мне надо транслировать линии в картину и выводить потом эту картинку через BitBlt?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

смысл двойной буферизации в том чтобы сформировать N фигур в одной памяти, а потом сразу скопировать это в выводимую память?

Да.

что это значит? т.е. мне надо транслировать линии в картину и выводить потом эту картинку через BitBlt?

Системная память - это обычная оперативная память или кэш процессора. Ты на буфере в ней рисуешь все фигуры, которые надо, а после одним пакетом и очень быстро отправляешь в видеопамять на вывод.

Есть и альтернативный подход, более быстрый: использование процессора видеокарты, то есть OpenGL или Direct3D. В этом случае аппаратное ускорение будет использоваться на всех участках рисования, а не только при выводе. Распространению такого подхода способствует развитие CUDA, OpenCL и т.п. Фактически на видеокарту переносятся все вычисления, результаты сразу же без задействия CPU выводятся на OpenGL или Direct3D текстуру, там же на GPU происходит вывод всевозможных примитивов. Причём работать можно не в абсолютных world-координатах, а в привычных пиксельных! (В Direct3D создаются вертексы определённого типа. В OpenGL не знаю.)

Ещё плюс: декодирование многих форматов видео аппаратно поддерживается. То есть и здесь снимается нагрузка с CPU, а также сокращается время на копирование очередного кадра в видеопамять (сжатые кадры на порядки меньше декодированных).

К полностью аппаратному выводу уже давно перешла Майкрософт, выпустив Aero. Qt может выводить свою графику через OpenGL (а, значит, KDE делает тоже самое). Unity 3D в последней Ubuntu тоже его используют. И, наконец, все мобильные платформы стараются использовать аппаратное ускорение везде, где только можно для снижения энергопотребления.

P.S. Думаю, что GDI надо оставить прошлому. А Брезенхама (Брезенхема или Брезенхейма) мы всё равно никогда не забудем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

P.S. Думаю, что GDI надо оставить прошлому. А Брезенхама (Брезенхема или Брезенхейма) мы всё равно никогда не забудем.

От ГДИ не уйти, это унификация всего вывода графики.

Тут надо отделить мух от котлет, для чего нужен ГДИ и для чего нужны Директы и ОпенДЖеэли

Если первый предоставляет простой механизм для вывода графической информации неважно на какое либо устройство, то вторые это мощные средства для обработки аудио и видио

кратко как то так

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

От ГДИ не уйти, это унификация всего вывода графики.

Тут надо отделить мух от котлет, для чего нужен ГДИ и для чего нужны Директы и ОпенДЖеэли

Если первый предоставляет простой механизм для вывода графической информации неважно на какое либо устройство, то вторые это мощные средства для обработки аудио и видио

кратко как то так

Отделить надо и это уже делается. Сейчас GDI в Windows оставлен только для совместимости. Я не уверен, что в Windows 8 полностью от него не откажутся. Он в какой-то степени удобен, но уже устарел.

Мы же сейчас говорим о быстром выводе видео и всевозможных примитивов? Тогда GDI для этого не применяется уже давно: все плейеры его не используют. Он уже ушёл из этой области.

Если говорить о пользовательском интерфейсе, то и тут GDI сдал свои позиции Aero (а это полигоны + текстуры). На Линуксах, как я уже писал постом выше, тоже давно отказываются от двумерной графики для пользовательских интерфейсов, обрабатываемой CPU, а выводят её с помощью OpenGL. Хочешь ещё примеры? Браузеры (!!!) используют аппаратное ускорение для рендеринга страниц.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я все таки не понял, мы говорили про случай, если картинка постоянно меняется, а примитивы мы выводим путем копирования в bitmap(какой функцией? или способом), а потом выводим картинку с примитивами с помощью BitBlt.

или это вообще справедливо для любой комбинации картинка меняется\не меняется примитивы меняются\не меняются?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Двойную буферизацию лучше применять всегда.

Каким способом выводить примитивы значения не имеет. Можно хоть самому их в памяти рисовать. Для работы с памятью см. CreateCompatibleBitmap, SetDIBits, SetDIBitsToDevice, GetDIBits).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Отделить надо и это уже делается. Сейчас GDI в Windows оставлен только для совместимости. Я не уверен, что в Windows 8 полностью от него не откажутся. Он в какой-то степени удобен, но уже устарел.

Мы же сейчас говорим о быстром выводе видео и всевозможных примитивов? Тогда GDI для этого не применяется уже давно: все плейеры его не используют. Он уже ушёл из этой области.

Если говорить о пользовательском интерфейсе, то и тут GDI сдал свои позиции Aero (а это полигоны + текстуры). На Линуксах, как я уже писал постом выше, тоже давно отказываются от двумерной графики для пользовательских интерфейсов, обрабатываемой CPU, а выводят её с помощью OpenGL. Хочешь ещё примеры? Браузеры (!!!) используют аппаратное ускорение для рендеринга страниц.

Если говорить о непосредственной обработке и выводе графики на монитор, тогда конечно ГДИ - это динозавр, но что бы распечатать, то теже самые Директы и ОпенДЖэли будут пользовать ГДИ.

Мы об одном и томже только с разных сторон :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте учётную запись или войдите для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать учётную запись

Зарегистрируйтесь для создания учётной записи. Это просто!

Зарегистрировать учётную запись

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас


  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу

×