Отрисовать миллионы точек чтобы не тормозило

QGraphicScene?

См. пример 40000 Chips в исходниках Qt.

https://doc.qt.io/qt-5/qtwidgets-graphicsview-chip-example.html

tl;dr - не рисуй их все, рисуй только те, что видит пользователь.

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

QGraphicsScene не умеет рисовать точки, только эллипсы. Не будет ли это тормозить ещё сильнее?

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

Может быть тогда тебе стоит взять QImage::setPixel() ?

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

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

Определить что он видит а что не отдельная история со своими накладными расходами.

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

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

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

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

А может тормозит из-за вычисления координат точек?

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

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

На виде «всё» он будет видеть не точки. Но вот это уже скорее всего достаточно сложно алгоритмически.

А разве в Qt - двойная буферизация такого рода до сих пор автоматом не работает?

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

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

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

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

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

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

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

по моему опыту это медленнее чем расчет для таких объемов

описка, конечно быстрее.

2020

Завязываться на deprecated’нутый X11 в кросс-платформенном фреймворке

Какой-то особый вид самомазохизма. Да и тормозно в сравнении с OpenGL.

Дристни на листок и сфоткай.

просто обновляй экран в том месте куда выводиш точку. Тормозит не будет.

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

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

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

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

миллионы раз

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

выводиш … Тормозит …

Вот Вам мягких знаков «ьььь», не благодарите.

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

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

спасибо, Друг :)

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

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

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

Завязаться на X11 в Qt-приложении

/0

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

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

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

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

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

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

/0

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

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

необходимо использовать карту с продвинутым 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 шейдерные процы пускать в дело, на то их и придумали и сделали.

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

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

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

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

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

finita la commedia

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

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

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

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

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

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

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

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

finita la commedia

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

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

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

Отрисовать миллионы точек чтобы не тормозило (комментарий)

Рисуй шейдерами и всё.

Сколько точек и в каком именно месте тормозило?

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

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

Может попробовать классы из Qt 3D ?

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

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

Ну дык просто изображение 5K^2 нарисовать это будет долго. Просто фоточки такого размера посмотреть, даже с SSD - тупить будет.

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