Свежие комментарии

Title	Comment
Понесло - потому что интересно. Если я уж до этого места доб	Понесло - потому что интересно. Если я уж до этого места добрался, то надо все попробовать. Уже наступил на множество граблей, радуюсь. Про PBO: ты случайно не помнишь, у тебя улучшалась "синхронная" производительность (от появления кадра в userspace до показа) или же ты просто асинхронно грузил "следующий кадр" пока показывался предыдущий (т.е. имел кольцевой буфер из PBO, по сути)?
Блин, я тупой, конечно ПБО. Кто о чем, а вшивый все о бане.	Блин, я тупой, конечно ПБО. Кто о чем, а вшивый все о бане. А чего тебя вообще в ВБО понесло-то? Чтобы ВБО имело смысл, надо тыщи вертексов иметь, если не десятки тыщ.
Да, double хватает для	Да, double хватает для строки, но если потом сложить тысячи этих double (по числу строк) - то что будет?
Везенье не при чем. Все	Везенье не при чем. Все оценивается, мне кажется. Если, скажем, у вас значения 16-битные (судя по 59 тысячам), а мантисса у float 24 бита, то сумма 2^(24-16) = 2^8 = 256 слагаемых будет вычисляться точно, а дальше... Так что, лучше суммировать вообще в 32-разрядных целых, тогда можно сложить точно до 2^(31-16) = 2^15 = 31768 значений - для одной строки как раз достаточно. Ну, там еще квадраты надо складывать... double для одной строки должно хватать.
Ага, при некотором невезении	Ага, при некотором невезении - жить страшно. Вот я про это писал, как выясняется полтора года назад (а как вчера было): http://blog.lexa.ru/2011/03/14/o_plavayushchei_tochke.html
"А некомпенсированный может	"А некомпенсированный может провираться даже на очень небольших данных (вроде строки)" Вот этого я как-то не понимаю. Даже страшно жить :) Уже сумму пару тысяч чисел подсчитать невозможно...
Для точности - есть	Для точности - есть "компенсированный алгоритм". А некомпенсированный может провираться даже на очень небольших данных (вроде строки)
Ну и что? Само количество	Ну и что? Само увеличение количества проходов ничего не ухудшает.
Я в первую очередь имел в	Я в первую очередь имел в виду проблему точности.
И получится двухпроходный	И получится двухпроходный алгоритм. О чем и речь.
Надо суммы считать по частям.	Надо суммы считать по частям. Например, сначала по каждой строке отдельно, а потом просуммировать суммы строк.
да, я понимаю. Но в том виде,	да, я понимаю. Но в том виде, который я использую (QGraphicsView в QGLWidget), я вижу изрядный оверхед собственно от Qt. Его и хотелось бы померять.
Более менее надежный способ	Более менее надежный способ померять opengl это рендерить в текстуру и потом ее прочитать, хотя бы пиксель. Другой способ это выключить vertical sync, рендерить на полной скорости запоминая при это текущее время и вычетать его из предыдущего. Но тест из этого не сделать.
Извини за занудство, но именно VBO или PBO? Потому что я зн	Извини за занудство, но именно VBO или PBO? Потому что я значимой разницы между VBO и просто передачей (всех 6) вертексов за раз - не вижу. А вот glTexSubImage2D - действительно медленная. Типа, 15мс на 0.7 мегапикселя. Пиксельные буферы еще не пробовал, вот собираюсь.
Угу. Но с пэйнтера можно вытащить трансформ.	Угу. Но с пэйнтера можно вытащить трансформ.
Ну я так и думал. Трансформации, поди, так же? Поворачивать	Ну я так и думал. Трансформации, поди, так же? Поворачивать и все такое - нужно самому? В-общем, мне пока не надо.
opacity? По-моему нет. IMHO, нужно с qpainter брать opacity	opacity? По-моему нет. IMHO, нужно с qpainter брать opacity и самому вмешивать в gl код.
А ерунду - средствами grahics scene	А ерунду - средствами grahics scene
А "на background" - в буквальном смысле. Мне нужно вывести	А "на background" - в буквальном смысле. Мне нужно вывести (здоровый) битмеп, а поверх него всякую ерунду. Проще всего оказалось оный битмеп выводить в QGraphicsScene::drawBackground.
Да, я видел это в примере boxes. Но пока не вижу, куда я бы	Да, я видел это в примере boxes. Но пока не вижу, куда я бы мог это применить. Интересно, кстати, а если nativePainting, то прозрачность (снаружи установленная) работает?
В смысле на background? Если в GraphicsView высталенв вьюпор	В смысле на background? Если в GraphicsView высталенв вьюпортом QGLWidget, то в paint любого айтема можно позвать painter->beginNativePainting, а потом painter->endNativePainting, то между ними можно выдавть свой GL код. При этом у меня для простых вещей даже клиппинг с трансформациями работали.
В-общем, пока не надо. И пока desktop components не допилят	В-общем, пока не надо. И пока desktop components не допилят - буду пользоваться QGrahics* и рисовать на background (отдельные items там тоже можно так рисовать) Но спасибо, положил в бумарки.
Из недокументированного: Если хочется всовывать свой opengl	Из недокументированного: Если хочется всовывать свой opengl код в стандарнтый QML UI, то для этого есть QSGRenderNode, которая только в private APIs и вроде как может поменяться, но т.к. используется в вебките, то скорее всего никуда не уйдёт и сильно меняться не будет. Правда, стандартный QML будет чуть медленнее, т.к. присутствие QSGRenderNode в дереве выключает некоторые отпимизации. Стандартные afterRendering/beforeRendering позволяют отрисовывать свой GL только под QML или поверх него, что не всегда подходит. Подсмотреть как использовать QSGRenderNode можно здесь: https://svn.webkit.org/repository/webkit/trunk/Source/WebKit2/UIProcess/...
Ну я mirror воспринял как	Ну я mirror воспринял как должное. Ну то есть "Y растет вверх" - это я сразу заметил и систему координат перевернул. То что текстуру нужно отдельно переворачивать - воспринял как данность. А до glBindTexture руками - сначала не добрался т.к. у меня оно не заработало (т.к. я опции для масштабирования не задал). Ну тогда пошел в отладчике чтобы весь gl-код который реально исполняется - просто скопировать. И тут же добрался до прекрасного. Понятно, если бы у меня ручное glBindTexture перевернуло бы структуру (относительно того, к чему я привык) - я бы насторожился. При этом, заметим, Qt-шные примеры перевернутую структуру воспринимают как данность и тщательно выписывают перевернутые же текстурные координаты. Но самое прекрасное - все-таки про буфер. Я вообще не могу представить, отчего такое. Т.е. похоже, там где-то при отрисовке scene items проверяется - а нету ли у нас буфера уже. И если есть - то свой не прицепляется. Но в отладчике туда не пойду. При этом текстуры, к примеру, отбинживать не надо.
Про миррор интересно. Вроде	Про миррор интересно. Вроде где то всплывало. Думал в матрицах накосячил.
Ну а у меня все мои сервисы	Ну а у меня все мои сервисы живут на colocation, оттого лично мне проще жить.
ну, если ничего больше не	ну, если ничего больше не надо, то да. а у меня лично дома на канале живет собственная файлопомойка и jabber, и мне очень не хочется чтобы они зависели от какого-либо VPN-проброса. собственно на данный момент они только от оплаченности интернета и живости канала зависят:)
С точки зрения потребителя -	С точки зрения потребителя - не вижу разницы. Ну, серьезно - в обоих случаях не могу ничего сделать, какая разница в чем причина. Для любых разумных извращений - главное чтобы SSH на улицу ходил, а дальше я уже сам.
ну всё же есть разница межу	ну всё же есть разница межу фильтрацией а-ля стрим, когда оно на магистрали у них режется "и ниипет", и тем, что ты не можешь что-то сделать тупо потому, что роутер через час забудет твои настройки. PS: тут кстати подсказывают, что РТшная оптика заводится именно как я описал - WAN+IPTV два порта. а дальше чо хочешь то и делай.
Ну а сейчас я не имею власти	Ну а сейчас я не имею власти над роутером, фильтрацией и т.п. у провайдера. Не вижу принципиальной разницы (кроме лишнего NAT, ну да у меня этих NAT-ов и так мешок и не мешает).

Свежие комментарии

Pages