Это зависит от множества факторов. Если вы получаете доступ к пиксельным данным по одному байту за раз, выравнивание не будет иметь значения в подавляющем большинстве случаев. Для чтения / записи одного байта данных большинству процессоров совершенно не важно, находится ли этот байт на 4-байтовой границе или нет.
Однако, если вы обращаетесь к данным в единицах размером больше байта (скажем, в 2-байтовых или 4-байтовых единицах), то вы обязательно увидите эффекты выравнивания. Для некоторых процессоров (например, для многих процессоров RISC) доступ к невыровненным данным на определенных уровнях совершенно незаконен: попытка прочитать 4-байтовое слово по адресу, который не выровнен по 4 байту, приведет к созданию исключения доступа к данным (или исключения хранения данных) ) на PowerPC, например.
На других процессорах (например, x86) доступ к невыровненным адресам разрешен, но это часто сопровождается скрытым снижением производительности. Загрузка / сохранение памяти часто реализуется в микрокоде, и микрокод обнаружит не выровненный доступ. Обычно микрокод извлекает правильное 4-байтовое количество из памяти, но если он не выровнен, ему придется извлечь два 4-байтовых местоположения из памяти и восстановить желаемое 4-байтовое количество из соответствующего байты двух локаций. Извлечение двух ячеек памяти, очевидно, медленнее, чем одного.
Это только для простых загрузок и магазинов. Некоторые инструкции, например, в наборах команд MMX или SSE, требуют, чтобы их операнды памяти были правильно выровнены. Если вы попытаетесь получить доступ к невыровненной памяти с помощью этих специальных инструкций, вы увидите что-то вроде исключения недопустимой инструкции.
Подводя итог, я бы не особо беспокоился о выравнивании, если бы вы не писали очень критичный для производительности код (например, в сборке). Компилятор вам очень поможет, например добавляя структуры так, чтобы 4-байтовые величины были выровнены по 4-байтовым границам, а на x86 ЦП также помогает вам при работе с не выровненными обращениями. Поскольку данные о пикселях, с которыми вы имеете дело, имеют размеры 3 байта, вы почти всегда будете делать однобайтовые обращения в любом случае.
Если вы решили, что вместо этого хотите получить доступ к пикселям при единственном 4-байтовом доступе (в отличие от 3 1-байтовых обращений), было бы лучше использовать 32-битные пиксели и выровнять каждый отдельный пиксель по 4-байтному граница. Выравнивание каждой строки по 4-байтовой границе, но не по каждому пикселю, будет иметь небольшой эффект, если таковой будет.
Исходя из вашего кода, я предполагаю, что это связано с чтением формата растрового файла Windows - для растровых файлов длина каждой строки развертки должна быть кратна 4 байтам, поэтому настройка буферов пиксельных данных с этим свойством имеет свойство, которое вы можете просто прочитать во всем растровом изображении одним махом в свой буфер (конечно, вам все равно придется иметь дело с тем фактом, что строки развертки хранятся снизу вверх, а не сверху вниз, и что данные пикселей - BGR вместо RGB). Это, на самом деле, не слишком большое преимущество - его не так сложно прочитать в растровом изображении по одной строчке за раз.