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

Время загрузки фоточки такого размера с SSD совсем невелико.

Кстати в память карты данные тоже грузятся небыстро.

Выделить память под растровую картинку и использовать что-то вроде:

inline void SetPixel(int32_t *bmp, int width, int height, int x, int y, int32_t color)
{
	if (x >= 0 && x < width && y >= 0 && y < height)
		bmp[y*width + x] = color;
}

Можно ещё отсортировать точки по Y-X и отрисовать их построчно.

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

Для такой проблемы самописное решение будет быстрее всего, потому что иначе будут большие накладные расходы на передачу массива точек. К тому же Mesa не рассчитана под такие задачи.

Фоточка сжата, её разжимать надо. Это долго и дорого.

Дык равки тоже не быстро рисуются.

Для такой проблемы самописное решение будет быстрее всего, потому что иначе будут большие накладные расходы на передачу массива точек

Это зависит от того, сколько у ТСа массивов точек в секунду. Если меньше одного, то какие там расходы... Наверное, с диска их грузить и то дольше.

плюс к этому: рисуй только те, что видит пользователь и не больше, чем нужно для оценки плотности

И Release

Попробовал QGraphicsScene. Не дождался результата, программа выжрала память, пришлось прибить. Добавлял точки как эллипсы, вписанные в квадрат 3х3.

Нет. Координаты точек уже посчитаны. При отрисовке координаты скалируются, чтобы попадали на виджет, а не за пределы.

Да, этот вариант быстрее. Правда такой же подход как с рисованием на виджете приводит к тому, что часть картинки уезжает куда-то вниз, за пределы виджета. Ещё точки мелковаты, но это сносно/можно поправить.

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

Нет. Координаты точек уже посчитаны. При отрисовке координаты скалируются, чтобы попадали на виджет, а не за пределы.

Какая частота тебе нужна? Сколько миллионов точек? Почему не хочешь использовать OpenGL?

Возьмем к примеру 10 миллионов точек и будем рисовать их на CPU с 50 FPS прямо в память в одностороннем варианте(если в пикселе уже нарисована точка то новая точка перезапишет его).
Посчитаем сколько тактов придется на одну точку если будем делать это на одном 2GHz ядре:
2GHz это 50 кадров по 10 млн. точек.
На 1 кадр с 10 млн. точек соответственно 40MHz.
На 1 точку соответственно придется 40MHz/10млн. = 4 такта.
Так что если обработка точки в конвеере укладывается в 4 такта, то на одном ядре 2GHz мы можем рисовать 10млн. точек с 50FPS.

Вот так грубо можешь прикинуть верхний потолок скорости отрисовки точек.

Там мусора много и разбираются они на немного странные структуры для работы с равками, а не для рисования.

-rw-rw-r-- 1   46M Jul  2 15:48 DSCF7761.BMP
-rw-r--r-- 1  3.6M Jun 12  2018 DSCF7761.JPG
-rw-rw-r-- 1  9.4M Jul  2 15:49 DSCF7761.PNG
-

разрешение 4896х3264

Все три ощутимо притормаживают при открытии (в пределах секунды, юзал qiv), png тормозит чуть больше. Как замерить время я не знаю, могу конечно на tkinter набросать аппликуху с замером, но сейчас не до того.

Во-первых, тестировать надо на TMPFS, во-вторых кто сказал что BMP в нативном формате для вьювера. BMP это 1/2/4/8/16/24/32/64 бит на пиксель + всякие костыли, например для 64 бит. А стандартный формат для выювера может быть другим. Ну и мякотка - вювер должен вписать изображение в окно (масштабирование провести), а это бикубическая интерполяция или экстраполяция обычно. А вот это уже не очень быстро.

Добавлял точки как эллипсы, вписанные в квадрат 3х3.

Совет дня - если их анимированными делать так еще сильнее тормозить будет!

У меня ssd.

судя по размеру там в BMP 3 байта на пиксель.

И qiv не вписывает, qiv по дефолту рисует пиксель в пиксель.

Картинка статичная. Нужно отрисовать скопление, чтобы пользователь мог увеличить интересующую часть и проанализировать.

Частота? Картинка статичная. Тормозит перерисовка при изменении размеров окна или попытке увеличить.

Почему не хочешь использовать OpenGL?

Почему не хочу. Хочу. Просто в Qt так много способов сделать одно и то же я сначала взял тот что мне показался проще в исполнении. Попробую и OpenGL. Кстати, что лучше, использовать QPainter для QOpenGLWidget или рисовать OpenGL командами?

Может, лучше использовать программы для визуализации данных, чем самому писать. Например, сгенерить точки и скормить gnuplot или matplotlib.

Там кроме визуализации точек нужно будет потом отрисовать сетку и поля-кнопочки, чтобы пользователь мог настроить параметры сетки. Это можно сделать в qnuplot или matplotlib?

Почему не хочу. Хочу. Просто в Qt так много способов сделать одно и то же я сначала взял тот что мне показался проще в исполнении.

Тогда во первых рисовать точки надо только при изменении размера виджета а не каждый раз при его перерисовке. Для этого создай QImage нужного размера и на нём как уже было сказано выше с помощью QImage::bits() получи указатель на блок пикселей и рисуй напрямую в этот блок. И уже этот QImage отрисовывай на виджете. Можно даже QImage в QPixmap преобразовать тогда Qt должен быстрее его отрисовывать.
Доступ к писелям будут зависеть от того в каком формате ты создашь QImage, но в любом случае в целях оптимизации длина строки в них округляется в большую сторону, поэтому для вычисления начала строки надо иметь размер строки в байтах, например с помощью вызова: QImage::bytesPerLine().
Так запись пикселя будет примерно вот-так: data[(bytesPerLine * y) + (bytesPerPixel * x)] = value;

matplotlib

Давно не использовал. Это либа для питон, придется учить питон. Еще и биндинги к qt, или tkinter, или wx, чтобы рисовать окошки-кнопочки.

google://qt data visualizton

Выдал https://doc.qt.io/qt-5/qtdatavisualization-module.html

Не читал, но осуждаю.

А если так:

0. Аппроксимируем данные чем-нибудь.

1. При показе картинки показываем грубое приближение.

2. Пока пользователь на него смотрит, заменяем его на более точную модель.

3. Повторить вплоть до заданной точности.

Нужно отрисовать миллионы точек.

А каковы типовые размеры окошка/виджета, в которое рисуем? Если 1000x1000, то это всего миллион.

А каковы типовые размеры окошка/виджета, в которое рисуем? Если 1000x1000, то это всего миллион.

А при чем здесь размер области отрисовки в пикселях и количество точек? У меня может быть 500 млн. точек и я могу их отрисовать в прямоугольнике 100 на 100 пикселей.

Смотря на то, делать ли масштабирование самому или делегировать.

Попробуй 1920x1080 на процессоре отрисовывать в 25 кадров в секунду хотя бы.

Это нисколько.

Ничего лишнего просто чёрный фон и пару сотен точек и что бы это можно было бы масштабировать, перемещать и всё такое.

Это нисколько.

Даже если бить на чанки будет печально.

Сообщаю новость. cpu быстрее твоего бичёвого gpu. А единственная проблема cpu - это ты и твой говнокод. Просто у gpu есть специальный фрейворк, который ставит тебе условия специальные и преобразует твой говнокод во что-то вменяемое.

наверняка их мышкой выбирать

Ты собрался выделение мышкой на гпу делать? Как ты себе это представляешь?

Можно исхитрится и на cpu сделать,

Да нет, просто нужно уметь писать не говно. Но это почти невозможно, для вас.

но блин разве что на тредрипперах или ксеонах опять же с

Там и одного ядра хватит на подобную херню.

openmp каким.

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

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

ogl бездарное дерьмо, все эти api бездарное дерьмо и нахрен не нужны.

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

Просто научись писать код, а не бездарное дерьмо.

Мандельброта на D

Писал бездарный говнокод на бездарной скриптухе и получил тормоза? Виноват cpu, кто-то ожидал иного?

Кто-нибудь, унесите царя.

что-то ты зазвезделся, софтовый рендер на cpu до десятков раз медленнее

если не сотен

А уже советовали взять Qwt и не мучаться. Там уже есть все для аппроксимации и прочего.

И да, нет смысла все отрисовывать. Можно просто выбирать , просеивать то что отрисовывать в воответствии с разрешением монитора.

Например, всегда отрисовывать конкретное кол во точек в не зависимости от зума.

Ну, царёк, покажи мне реализацию на С или на асме которая бы рисовала хотя бы 1080p быстро и без использования GPU на 2-ядерном Ivy Bridge без AVX.

Я между прочим GC не использовал, а malloc из libc.

Про производительность я уж совсем наврал: вчера проверил, за 17 сек рисует 5000x5000 на 2 потоках. Но зато в 500х500 быстро (для CPU), если сделать цикл, будет 5 fps. Буду экспериментировать с DCompute, но думаю OpenGL шейдер не обгоню.

Да не реагируй ты на это дерьмо. Он же тот еще чудак на букву «м». У него своя классификация всего, если что-то в его рассуждениях ломается, он придумывает этому новое определение (которое противоречит общепринятому), лишь бы не признавать что он налажал. Какое-то новое определение скриптовым языкам придумал. Я в начале подумал, что чувак шарит, но потом выяснилось, что он просто неадекватный. Рекомендую его игнорировать.

ГЦ тут вообще не причем, большая часть людей, кто критикуют ГЦ сами его и не использовали, тем более в D. ГЦ удобная и полезная штука. А бестолково использовать можно все.

DCompute вряд ли обгонит opengl шейдер хотя бы потому что тоже будет не GPU исполняться

Ну, царёк, покажи мне реализацию на С или на асме которая бы рисовала хотя бы 1080p быстро

Я не занимаюсь подобным, но никаких проблем нет. Лет я помогал пацану ускорить его рисовалку. Там штук 5-10 синусов на пиксель, 1080p и 60+фпс. Ты никогда такое на своей видяхе дерьма за 15 баксов не нарисуешь. Особенно ты.

2-ядерном Ivy Bridge

Ты нищий? Твоя проблема, не моя. Побежал показывать видяху за 15 баксов.

без AVX.

Ты бездарен? Твоя проблема.

Я между прочим GC не использовал, а malloc из libc.

Абсолютно насрать на то, есть там GC или нет. К тому же, ты и тут обгадился. Маллок - признак бездарности.

Про производительность я уж совсем наврал

Абсолютно неважно то, что там намерил очередной студент с помойки на своей бездарной скриптухе.

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

Быстрые видяхи с нормальной памятью существуют, но они не стоят 15 баксов, очевидно.

что-то ты зазвезделся

Зачем очередная анонимная ссыкливая школота с помойки что-то пытается мне кукарекать?

софтовый рендер

Ты обгадился, подобной чуши не существует.

cpu до десятков раз медленнее

Ещё раз, представления домохозяек-поломоев меня волнуют мало. Ты просто нелепое трепло, которое несёт херню.

а PCL не подойдет?

Release, EXL, pon4ik

Попробовал рисовать QImage на QGraphicsScene. Получилось шустро, зум из коробки – радует, можно якорь поставить. И ещё куча фич, которые мне (пока) не нужны. Но есть одна проблемка. Если сильно уменьшить картинку, чтобы попадало всё, то отрисовывается странно. Вот отрисовка одних и тех же точек в QWidget и в QGraphicsScene. Видно что контур тот же, но как-то всё разреженно. Это результат какой-то оптимизации? Можно это как-то пофиксить?

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

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

Блин, снимут скор за ответ на удаленное (кстати я сторонник это убрать), но надо сказать что это очень забавное сообщение, создающее ту самую аутентичную атмосферу winfaq.org.ru

Жаль, что время никого не щадит и многие разбредаются по конфочкам, но посты царя из-под анонима показывают, что пульс еще есть.

Быстро ты обгадился. Кукарекал, кукарекал, а потом обгадившись и несмогшли ничего ответить - начал блеять рандомную херню, лишь бы побыстрее съехать с темы.

А как же маллок? А как же скриптуха? А как же нищие трепло? А как же 15 баксов? А как же avx? Куда весь твой убогий кукретинг делся?

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

Дерьмо опущенное, с чего вдруг ты решило, что можешь мне что-то кукарекать и что-то с меня требовать? Ты опущенное анонимное дерьмо, не более.

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

В общем, похоже, проблема не только в количестве точке, но и размере картинки. На небольшом кусочке, который я взял для тестирования, у меня получилось изображение 9692х12642.

QGraphicsView справляется отлично с такими изображениями даже без OpenGL, но ценой жёстких артифактов при скалировании картинки. Нашёл такую тему. Так что на проблему эту время от времени наталкиваются, ответа там нет, так что я сделал вывод, что в Qt нет возможности крутить качество при скалировании.

QWidget + QImage рисуют всё правильно, но если увеличивать изображение имитируя приближение – всё начинает тормозить. Тут нужно колхозить зум по выделению прямоугольником, чтобы рисовать только в его пределах и как-то реализовывать «смещение картинки» по перетаскиванию рукой и, наверное, как-то оптимизировать рисование до приближения. Если кто-то знает примеры как реализовать такой зум и смещение – буду признателен за ссылку.

С QOpenGLWidget + QImage наблюдал какие-то артефакты при «увеличении». После нескольких увеличений картинка меняет фон на чёрный и теряет все точки.

используй Electron. Стильно, модно, молодежно

QCustomPlot

Посмотрите на него, может зайдёт