Растяжение и размножение

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

А свою миссию вижу прежде всего в том, чтобы открывать глаза на те или иные факты, явления и закономерности, а также делиться своими субъективными воззрениями на все это с людьми творческими, вполне самостоятельными, способными анализировать, экспериментировать, оппонировать, не принимать ничего на веру просто так, без какого бы то ни было осмысления. И меньше всего с этой стратегией соотносится тактика разжевывания чего бы то ни было «шаг за шагом».

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

Консерваторам, лелеющим табличную верстку, не следует забывать о том, что таблицы отображаются многими браузерами (среди коих в первую очередь IE) только после полной загрузки, поэтому не стоит «загонять» всю страницу в одну-единственную таблицу — там, где здравый смысл позволяет, лучше ее разбить на несколько следующих подряд друг за другом таблиц. Скажем, области «шапки» и «подвала» во многих случаях вполне могут быть организованы как самостоятельные таблицы, не заставляя пользователей подолгу томиться, наблюдая перед глазами пустое белое (или какое там) поле окна браузера. CSS-верстка, ясное дело, от подобного недостатка избавлена.

Для всех картинок, связанных со страницей при помощи тега <img>, необходимо обязательно указывать ширину и высоту. При помощи CSS-свойств width и height, разумеется, ибо одноименные атрибуты HTML, будучи визуальными, вне закона!

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

Как вы понимаете, мы можем указать в значениях свойств width и height как фактические, так и отличные от реальных, совершенно произвольные размеры картинки в пикселях, тем самым сжимая или растягивая ее.

Так вот, растягивать изображения таким способом вполне можно, а вот сжимать — ни под каким предлогом нельзя. Ибо в первом случае мы выигрываем, занимая маленькой и легковесной картинкой большую площадь, а во втором — с точностью до наоборот. Если изображение нужно уменьшить, сделать это лучше всего при помощи графического редактора. При этом, сократив линейные размеры, удастся значительно «урезать» и объем файла.

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

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

Предположим, на странице требуется горизонтальная полоска оттенения высотой 10 пикселей и шириной 600. Для этого подготавливаем градиент с фактическими размерами 1×10, после чего растягиваем его при помощи CSS-свойства width до требуемых 600 пикселей. В значении свойства height указываем, разумеется, фактическую высоту.

Другой возможный вариант — подчеркивание растра (в оформительских целях) или демонстрация того или иного изображения в увеличенном масштабе, как это было сделано в практическом приложении к позапрошлой моей колонке. Но хорошие результаты это дает только в том случае, когда в значениях свойств width и height указаны величины, кратные реальным ширине и высоте растягиваемого изображения. Ресэмплированная картинка, увеличенная в нецелое число раз, выглядит крайне неряшливо.

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

Не следует забывать, однако, что существуют еще в России пользователи, для которых трехгигагерцовые четвертые «пентиумы» с гигабайтами памяти на борту существуют лишь в мечтах. Дайте себе труд, попробуйте разыскать какой-нибудь Pentium-100 с восемью мегабайтами «оперативки» (а такие машины — отнюдь не редкость в отечественных провинциальных офисах) и посмотрите, сколько времени подобный компьютер будет отрисовывать такое вот фоновое изображение. Мораль напросится сама собой: картинка, которая будет множиться в фоне страницы, должна иметь размер не менее 50—100 пикселей по меньшей стороне.

В связи с фонами вспомнилась и противоположная по характеру история из не столь далекого прошлого. К счастью, в наше время она уже вряд ли актуальна, ибо при помощи CSS-свойств background-position, background-attachment и, в особенности, background-repeat можно управлять расположением фона весьма вольготно.

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

А хотелось, конечно, большего. В частности, хотелось жестко закрепленного фона без каких-либо повторений. По крайней мере видимых. Требуемый эффект достигался при помощи фоновых «полотен» размером эдак 2000×2000 пикселей, содержавших что-то осмысленное лишь ближе к левому верхнему углу.

Такая картинка (к примеру, размытая фотографичная текстура), сохраненная в JPEG, могла весить вполне пристойно — килобайт тридцать. Но рендеринг! Я, конечно, побоюсь авторитетно утверждать, что сей процесс требовал 12 Мбайт оперативной памяти (какая цифра получается, если умножить количество пикселей в изображении на 24 бита, коими представлен цвет в режиме True Color), но это весьма похоже на правду, ибо, во всяком случае, упомянутый выше подопытный Pentium-100 под воздействием такого фона способен был повиснуть насмерть…