LINUX.ORG.RU

  1. Создать QImage ARGB32.
  2. Методом bits() получить указатель на данные изображения, записать нужные пиксели по своим смещениям. Поскольку работа идёт напрямую с памятью, не будет накладных расходов.
  3. Нарисовать QImage на виджете с помощью QPainter.
m0xf ()
Ответ на: комментарий от m0xf

Методом bits() получить указатель на данные изображения, записать нужные пиксели по своим смещениям. Поскольку работа идёт напрямую с памятью, не будет накладных расходов.

А у setPixel() такие накладные расходы есть?

EXL ★★★★★ ()
Ответ на: комментарий от EXL

А у setPixel() такие накладные расходы есть?

Можно посмотреть в исходниках Qt. Там есть проверка на выход за границы массива, switch по типу изображения, проверка счётчиков copy-on-write. Ну и сам вызов функции. Просто запись в память в разы быстрее.

m0xf ()
Последнее исправление: m0xf (всего исправлений: 1)

Что такое по Вашему «тормозит» и какую производительность Вы хотите?

При работе напрямую с памятью изображения (как правильно предлагает @m0xf) у меня изображение на 2 мегапикселя строится за .01 сек на ноутбучном CPU в 4 потока, при этом цвет точки вычисляется довольно сложным образом. Правда там не Qt потом а Tkinter и PIL.

AntonI ()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от cppprogger

а может и нет, и вместо того чтобы и дальше играть в «угадайку» можно было бы просто отпрофилировать приложение и уже на основе него делать выводы в каком месте происходит основное ресурсоемкое поведение. Но конечно проще заниматься херней и языком чесать :)

anonymous ()
Ответ на: комментарий от AntonI

Тут есть две стороны монеты - есть i/o и есть расчёт, i/o почти всегда значительно медленнее такого класса расчётов(я не знаю как правильно обозвать класс задачи, но это просто выборка по уже посчитанным координатам и банальная арифметика для каждой точки) и подходить к улучшению производительности улучшая i/o это скорее всего путь к провалу. Как верно заметили выше - хорошее, быстрое решение это QGraphicsScene, которое события отрисовки вне видимой области «ставит в очередь».

pon4ik ★★★★★ ()

OpenGL -> VBO + GL_POINTS в случае показа всех точек зависит от железа, но всё равно будет быстро . В случае увеличения отсечение невидимого лежит полостью на плечах mesa и париться не надо. Подобный тред уже был

LINUX-ORG-RU ★★ ()
Ответ на: комментарий от pon4ik

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

Я правда не знаю какой монитор у ТС, может там 16К…

AntonI ()

Вызвать x11PictureHandle, а потом единым разом отправить миллионы треугольничков на Render-поверхность. Ну очень быстро. Увы и ах, только для X11, угу X'ы фичастые.

anonymous ()
Ответ на: комментарий от pon4ik

На виде «всё» он будет видеть не точки

Почему? Точки, только некоторые сольются.

Вообще конечно еще по постановке вопросы - 2D или 3D? Все точки одного цвета или разных?

AntonI ()
Ответ на: комментарий от EXL

Да и тормозно в сравнении с OpenGL.

«С точки зрения дебила — безусловно».(C) Вызвать один раз функцию или миллионы раз — действительно, ведь нет разницы.

Какой-то особый вид самомазохизма.

Диван попытайся не сжечь, интернет-воен.

anonymous ()

/me мимо проходил

Но ведь миллионы точек рисовать не нужно, т.к. человек ни увидеть, ни помыслить их не в состоянии. Вы не пытались как-то аппроксимировать ваши данные, а затем уже строить график в нужном диапазоне?

ugoday ★★★★★ ()
Ответ на: комментарий от unC0Rr

С разморозкой, аноним! У нас тут 2020, и очень весело.

Ага, для 2D-графики необходимо использовать карту с продвинутым 3D-ускорением. Вместо простого и легкого пути используется сложный и стремный.

anonymous ()
Ответ на: комментарий от ugoday

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

Фактически при этом неявно строится функция распределения с максимально возможной детализацией для визуализации (одна точка - один пиксел).

AntonI ()
Ответ на: комментарий от andalevor

Сначала пользователь должен видеть все, потом уже может зум делать.

Собери пример 40000 Chips, ссылку на который я тебе скинул, поиграйся с ним, там увидишь апроксимацию всех этих 40000 Chips в пиксели изображения. Возможно тебе этот способ подойдёт.

И разъясни задачу более детально. Дай больше информации.

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Вместо простого и легкого пути

/0

Что X11 не так? Это же не фейланд, который не взлетел за 12 лет. (Вероятнее всего, Рэт Гад бросит эту свою игрушку, акционеры IBM — парни суровые, не потерпят дальше тащить разработку этого токсичного актива.) А под X11 поставленная проблема решается просто и изящно.

Да-да-да, если нужна переносимость под винду или гейОС — выхода нет: их графические подсистемы не столь фичастые.

anonymous ()
Ответ на: комментарий от anonymous

необходимо использовать карту с продвинутым 3D-ускорением

3D в графических ускорителях можно в скобочки убрать. Ускоряется именно 2D растеризация. Так что в первую очередь opengl/directX/Vulkan/Metal ускоряют 2D, а к 3D там отношение только из за векторных расчётов vec2/vec3/vec4/mat4/mat3/mat4 и то для 2D vec4 такое же родное как для 3D vec3 позиция и vec4 кватернион. Вершины же все проецируются на 2D просто по принципу соотношения к удалённости по z и к 3D это имеет чисто техническое отношение для расчётов. Так что GPU ускоряет 2D, а не 3D и фрагметная часть вычислений на порядки мощнее и занимает по % больше места на кристалле чем обработка вершин.

Попробуй 1920x1080 на процессоре отрисовывать в 25 кадров в секунду хотя бы. Ничего лишнего просто чёрный фон и пару сотен точек и что бы это можно было бы масштабировать, перемещать и всё такое. Даже если бить на чанки будет печально. А челу надо миллионы точек рисовать, наверняка их мышкой выбирать, вращать, перемещать и прочее. Можно исхитрится и на cpu сделать, но блин разве что на тредрипперах или ксеонах опять же с openmp каким.

Простой и лёгкий путь да. Но тормоза будут привеликие. А если без тормозов и на cpu полностью то будет сложнее чем весь opengl или получится второй opengl.

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

LINUX-ORG-RU ★★ ()
Ответ на: комментарий от anonymous

Так можно использовать X11 но отрисовку делать в Opengl. Опять же если я ничего не путаю Xorg свои примитивы тем же по твоему ненужным 3d акселератором при возможности калякает.

LINUX-ORG-RU ★★ ()
Ответ на: комментарий от anonymous

Рэт Гад бросит эту свою игрушку

Уже бросили. Только не игрушку, а засохший копролит.

Red Hat откажется от разработки X.org в ближайшем будущем

Реальность такова, что X.org в основном поддерживается нами и, таким образом, если мы перестаем тратить на него время, навряд ли будут выпущены новые „мажорные“ релизы и даже, возможно, со временем все придет в упадок.

finita la commedia

EXL ★★★★★ ()
Ответ на: комментарий от LINUX-ORG-RU

Так можно использовать X11 но отрисовку делать в Opengl. Опять же если я ничего не путаю Xorg свои примитивы тем же по твоему ненужным 3d акселератором при возможности калякает.

Путаешь. Треугольнички в Render аппаратно ускорены и не имеют ну ничего общего с примитивами OpenGL.

Еще раз, коротко, тут OpenGL применима только для кроссплатформенности; где графические подсистемы не такие продвинутые, как X11.

anonymous ()

Я когда писал визуализацию множества Мандельброта на D вообще хранил точки в RGB24 в обычном массиве а потом скармливал указатель Cairo. Это все равно жутко тормозило, даже распараллеленное. Так что тут дело про OpenGL говорят, возьми его, процессоры совсем для такого не годятся.

ArkaDOSik ★★ ()
Ответ на: комментарий от EXL

Red Hat откажется от разработки X.org в ближайшем будущем

После этой прекрасной новости я купил себе бутылку дорогого коньяка.

Реальность такова, что X.org в основном поддерживается нами и, таким образом, если мы перестаем тратить на него время, навряд ли будут выпущены новые „мажорные“ релизы и даже, возможно, со временем все придет в упадок.

Реальность такова, что в xorg они пилят исключительно XWayland. Когда будут сваливать (ах, быстрее бы наступило это чудесное время!) пусть не забудут забрать с собой эту недоделку.

finita la commedia

Только во влажных и горячих мриях любителя вялого.

anonymous ()

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

peregrine ★★★★★ ()
Ответ на: комментарий от anonymous

Ну, тут я даже не знаю. Всё что известно от ТС «рисовать мильёны точек» это слишком мало. А если… они там у него движутся? Тут можно вообще придти к чистому GLSL и не ради кроссплатформенности, а что бы просто отобразить смогло более чем 1 кадр в секунду

LINUX-ORG-RU ★★ ()
Ответ на: комментарий от LINUX-ORG-RU

Ну, тут я даже не знаю. Всё что известно от ТС «рисовать мильёны точек» это слишком мало. А если… они там у него движутся?

Да хоть совокупляются. Через Render отрисовка мгновенная.

anonymous ()
Ответ на: комментарий от AntonI

Всего-то 5000x5000. Если выводить на экран то будет примерно 4 fps на целероне 2ghz sandy bridge.

Тормозило разумеется по большей части на просчете функции, но cairo также подтормаживал нехило (я пробовал сохранять пустой массив в PNG, очень медленно: 0.05-0.1 сек если не изменяет память). Ну тут i/o, согласен.

ArkaDOSik ★★ ()