Войти
ПрограммированиеФорум2D графика и изометрия

Зачем нужен padding в данных битмапа? (2 стр)

Страницы: 1 2 3 Следующая »
#15
20:51, 12 сен. 2021

А вопрос, почему в битмапе изображение вверх ногами не возникал?


#16
20:57, 12 сен. 2021

invis
> Хранение данных вверх ногами никого не смущает?
Я не против хранить изображения в декартовой системе.
Главное, чтобы чётко было в документации отражено.

> А цветовые компоненты как BGR вместо RGB?
Причём они их в коде RGB называют.
Впрочем, они не одни такие. Вон .tga тоже BGR.

}:+()___ [Smile]
> У нас два чтения и одна запись — как минимум часть можно сделать выровненными.
Гм, логично. Если спрайт блитается целиком, от хранения его строк выровненными может быть толк.

> Вроде у всех современных процессоров доступ к выровненным данным примерно одинаков, однако раньше был штраф просто за само использование инструкции невыровненного доступа.
Вроде это даже ещё Core2 было, я думал древнее.

#17
21:12, 12 сен. 2021

}:+()___ [Smile]
> На чистом ассемблерном коде разница заметна.
Как-то так?
https://rextester.com/BIKX30496

#18
22:09, 12 сен. 2021

FordPerfect
> Как-то так?
Хмм... всего полтора раза разницы, мне казалось, что было больше.
Кстати, получается, что невыровненная запись дороже.

#19
1:26, 13 сен. 2021

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

#20
(Правка: 6:42) 6:40, 13 сен. 2021

Там же еще требование, что при загрузке в память (не в видеопамять, а в обычную память) начальный адрес битмапа должен быть тоже кратен 4.
Очевидно это просто для скорости работы на 32-битных архитектурах - можно строки передавать словами не парясь, что невыровненный доступ роняет производительность.
Но действительно сейчас это всё уже не особо важно, т.к. кеши-меши читаются строками и замыливают когда то проблему.
А вот зачем строки перевёрнуты - это уже мне лично непонятно. Форматы видеоконтроллеров тех времён с перевёрнутыми строками мне неизвестны и поэтому оно странновато.

#21
6:54, 13 сен. 2021

А, погуглил и таки нашёл: https://computergraphics.stackexchange.com/questions/8859/why-bmp… -line-on-file
Формат BMP разрабатывался MS вместе с IBM. А IBM в своей OS/2 для которой этот формат тоже родной выбрала математическую систему координат как в OpenGL. И во всех функциях Presentation Manager-а было всё снизу вверх по координатам. Поэтому в BMP строки перевёрнуты. Хотя MS в функция GDI выбрала компьютерную систему координат, но BMP приняла как IBM захотели.

#22
7:56, 13 сен. 2021

FordPerfect
У меня как раз core2 quad, обычный core 2 и intel atom, думаю сделать тест на picobench, тестами будут: Копирование картинки в другую по случайным координатам, копирование всего битмапа в другой, применение эффектов на картинке.
Вариации: выровненные, не выровненные, -O0, -O2, -Ofast -march=core2, проверка на x32/64 в винде и x64 в линуксе

#23
13:23, 13 сен. 2021

в этом всём глубойкий смысл. делать это всё столькоже смысла сколько и не делать.

#24
(Правка: 16:23) 16:19, 13 сен. 2021

Итак, я подготовил бенчмарк копирования одной картинки формата RGB0 (не важно, просто WORD), в другую. Размер картинки специально не кратен 4. Тестил на компе с Linux x64 и Windows x32. Проц: Intel Core 2 Quad Q9500 @ 2.83GHz.
Варианты теста: просто цикл; memcpy; с выравниванием строк; с выравниванием начала данных; смешанные варианты. Результаты в архиве, там ещё скрипты чтоб собрать тест и запустить, если коротко то эти все выравнивания быстрее обычного цикла только в -O0, memcpy их всех уделывает, хотя под линуксом x64 в padding + data align + memcpy дают результат лучше чем просто memcpy в 26% - возможно именно от выравнивания, а не от расширения строк, я не проверял.
Идея использовать это не лишена смысла, но на релиз сборке memcpy - норм тема. Как и сказал ИПавлов:
> делать это всё столькоже смысла сколько и не делать
Лично я не буду в пользу простого кода

P.S. в C++ можно только статичный массив выровненный сделать или всякие там #pragma pack, но на динамичной памяти это не работает, там нужны системно-зависимые функции. Выравнивание в 4 не так много прироста даёт, как в 64

#25
5:30, 14 сен. 2021

HPW-Dev
> но на релиз сборке memcpy - норм тема

memcpy просто делает предварительные проверки и прогоняет копирование начала буфера байтами до достижения выровненного адреса, с него переключается на выровненное ядрёное копирование через SSE и опять таки в конце буфера, если нужно, доделывает невыровненный остаток байтами.
При этом ему важно главным образом выравнивание байт на 16, т.к. в SSE понятие aligned и максимально быстрая скорость именно с этим связана.
В линейки кеша вроде тоже рационально попадает.
Т.е. в принципе эти выравнивания справедливы и до сих пор, но на более продвинутом уровне.

#26
14:31, 14 сен. 2021

HPW-Dev
Для выравнивания байтов. Например, чтобы адресация всегда была по 4, 8, 16 байт. Тогда можно применять дополнительные оптимизации, типа SSE. В современных реалиях это полезно не везде.

#27
22:22, 14 сен. 2021

bgr удобно преобразовывать в rgb (например меньшей битности)

#28
10:57, 15 сен. 2021

clc
Можно подробнее?
RGB <-> RBG иногда пригождается, а RGB <-> BGR неочевидно.

#29
12:51, 15 сен. 2021

clc
Ты о

uint32_t B8G8R8toR4G4B4(uint32_t C)
{
    // C=(C-((C>>4)&0x0F0F0Fu)+((C>>7)&0x010101u)+7); // Rounding.
    C=C&0x00F0F0F0u;
    C=((C*0x1001001u)>>16)&0xFFF;
    return C;
}
?
Страницы: 1 2 3 Следующая »
ПрограммированиеФорум2D графика и изометрия