Всем привет!

Все, что я узнал, я узнал из книги Макса Шлее QT профессиональное программирование на С++.

И так. Вот что я знаю. OpenGL, в рамках QT, можно использовать как альтернативу QPainter и QCanvas, если речь идет о 2-D графике. Работать мне предстоит с огромным масcивом точек в одной плоскости, т.е. как раз 2-D. 

Так же я знаю, что QPixmap класс контекстно-зависимого представления. И как написано в книжке "контекстно-зависимое представление позволяет отображать растровые изображение на экране гораздо быстрее, чем контекстно-независимое...".

Если я всё правильно понял, то перейду к вопросу.

Работать придётся, как я уже говорил, с огромным массивом точек. Надо будет работать с отдельным пикселем изображения. QPixmap мне подходит по своей функциональности. До главы про OpenGL я только добрался, так что не до конца представляю, на сколько мне поможет QGL.

Так вот вопрос. Какое из средств будет работать быстрее QPixmap или средства OpenGL?

OpenGL, если не ошибаюсь, полностью аппаратно укорено, а что насчет QPainter?

Я скажу так, да OpenGL - быстрее, но QPainter - по качеству графики лучше. Тут все зависит от конкретной задачи, если ты говориш что у тебя будет огромное количество точек - то тут я думаю разницы не будет, а разница будет в перерисовке, т.е. зависит от видеокарты. А видеокарты сейчас такие что ты разницу в скорости не заметиш, а заметиш только качество графики.
Ну и если у тебя часто будет идти перерисовка, т.е. точки постоянно меняються - то ту выйграет OpenGL.
А если можно сохранить один раз твой график в QPixmap и не перерисовывать - то QPainter.

всего лишь ИМХО. 

И все таки я за QPainter. Более удобней 

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

Я бы предложил попробовать оба варианта на максимальной загрузке, так чтобы видео-карта не справлялась 
А результаты выложить сюда.

Кстати 2d прорисовка окон аппаратно ускоряется как в винде так и в линуксе благодаря видюхе и драйверам под нее. У меня есть компьютер со встроенной видюхой, где базовые функции аппаратного ускорения работают. Однако мощностей не хватает на NFS:Undeground и UT2004, лагает дико, иногда зависает, перезагружает комп или вываливается в кору. Если же отключить аппаратное ускорение в свойствах рабочего стола, то лагать начинают уже обычные окна, мерцают, долго всплывают и т.п. Точно такая же картина наблюдается в линуксе с драйвером VESA, это единственный драйвер, который согласился работать со встроенной видюхой, остальные 2 как бы предназначенные под нее - не работают даже в обычном режиме. 

Так вот и получается, что и для OpenGL идет ускорение и для обычного окна. Хотелось бы узнать, что же все-таки ускоряется лучше...

А что за видюха? в любом случае - это ненормальная работа. Перезагрузок и т.п. не должно быть.  NFS:Undeground и UT2004 могут не поддерживаться не из-за недостатка мощности, а из-за отсутствия аппаратной поддержки шейдеров и т.д.

Либо на видюхе что-то выгорело, либо материнка лажает. Аналогичная картина была, когда знакомый перепаял кондеры на материнке.


Ускоряется одинаково. Разницы в скорости не должно быть.


Думаю, нужно немного конкретизировать

Я про нее писал в блоге в теме про Ubuntu. Расстраивает то, что в винде оно хоть как-то ускоряется, а в линуксе даже дрова не заводятся.

Спасибо, не ожидал столько ответов. Да, вы правы, надо конкретизировать. Сейчас попробую объяснить подробнее с картинками.

Изначально я пытался реализовать это на C# и GDI+. Тормозит, а при большом кол-ве точек вообще виснет. Да, можно оптимизировать, продумать, но в итоге все равно будет не то.

Вот перешел на С++ и QT.

Посмотрите на картинки.

Есть два изображения. Оба состоят из рандомного набора точек. В одном изображение синие точки, в другом красные.
Эти два изображения начинают двигаться друг на друга. Когда они начинают пересикаться, то какие-то точки начинают "накрывать" друг друга. 

Так вот задача. Когда две точки накрываются, то надо что бы результирующий цвет видимой точки был смешанного, то есть грубо говоря синий + красный = розовый.

Либо есть еще один вариант, когда два изображения изначально наложены друг на друга(тут то же должно учитываться смешивание цвета наложенных точек) и начинают двигаться в разные стороны.





 
Вроде смог объяснить, что надо сделать. 

Вопрос остается тот же.  Даже еще один возник.

1 - Что быстрее будет в этом случае работать. OpenGL или QPainter?

2 - И какие способы посоветуете для реализации этой задачи?

Э-э-э-э.. Из выше приведенного примера понятно что проблема вообще не в языке программирования и не в openGL или qpainter а проблема в алгоримте реализации такой вещи. Тут нужна математика.


прочитай в ассистенте про Alpha-Blended Drawing 

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

если это не решение, тогда всю математику пребираний точек и смешивание цветов вывести в поток после этого сохранить в QPixmap и отрисовать
есть хороший пример в QT "examples\threads\mandelbrot" - может помочь в твоей задаче


Это сообщение отредактировал(а) Elfebet - 25.11.2008, 13:38

Как я понял, Вам нужен вывод на экран двух  наложеных друг на друга текстур с эффектом альфа блендинга.

В  ОпенГл сможете не только наложить друг на друга, но и применить многие эффекты - как, например, наложение под углом.
а также задать способ блендинга.

Если QPainter  может смешивать цвета и нужно "классическое" наложение , то  оба варианта по скорости вывода будут  равноценны.


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




Это сообщение отредактировал(а) mes - 25.11.2008, 13:35

Прозрачность и альфа-блендинг как я понял это одно и тоже?! Но мне прозрачность не подходит. Тот результируюший цвет, что дает смешивание, к примеру, красного и синего, будет отличаться от цвета полученого при наложении с прозрачнастью. И в итоге через стерео очки будет немного другой эффект.




Сперва так и было, но потом я создавал битмап и с ним работал. Проблема особо не решилась. Конечно, в моем случае еще и правильный алгоритм нужен. Но думаю использование QT\C++ против C#\GDI+ даст заметное преимущество.

Это сообщение отредактировал(а) Moby - 25.11.2008, 14:26

Полностью согласен, предлагаю почитать это

Добавлено через 3 минуты и 10 секунд

Ага, нужно "Цветовое наложение". Читаем и смотрим примеры по ссылке

О... Спасиб огромное, ща буду разбираться. Спасибо. 

P.S. Хотя глазами пробежался и вот на такой рисунок наткнулся. 



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

Тут больше похоже на прозрачность. Лано, надо будет почитать.

Это сообщение отредактировал(а) Moby - 25.11.2008, 15:19

нет не одно и то же . Прозрачность - частный случай альфа блендинга.


Да это  наложение, один из вариантов результата. Конечный результат смешивания зависит от формулы смешивания. (по вышеприведеной ссылке : 6.1.1  Факторы источника и приемника )
а еше поишите в гугле уроки от  NeHе   - там много примеров того, что можно получить с помощью OpenGL.

Какой метод может использоваться, если пересекаются красный и черный, причем не важно какой из них сверху или снизу ? В итоге получается черный.

Не смог найти эти уроки. Ссылочкой не поможите?




Это сообщение отредактировал(а) Moby - 25.11.2008, 17:47