Comments 22
Простите мое невежество, но почему превьюхи изображений стали называть плейсхолдерами?
Я использую этот термин потому, что его другие используют. Думаю вопрос в контексте. Превью — уменьшенное изображение оригинала, а плейсхолдер — нечто, что занимает место оригинала, пока его самого еще нет. Собственно буквально это слово переводится как «удерживающий место». В некоторых случаях все это смешивается, как здесь — в некоторых примерах полученная картинка-заглушка похожа на оригинал.
На самом деле меня смутил заголовок. Быстрый гуглеж по слову placeholder дал вполне ожидаемые результаты для input'а. Svg-placeholder вывел множественные публикации одной статьи с сотней треугольников. И только image placeholder показал искомое.
Есть ощущение, что не я один думал о другом при чтении заголовка.
Для максимально однозначного понимания обычно используют аббревиатуру LQIP (Low Quality Image Placeholder).
А размытые SVG картинки и картинки с большим количеством треугольников не нагружают CPU клиента, мешая ему загружать сайт? Вы не проверяли?
Плюс, как мне кажется, превьюшки могут иметь смысл для каких-то больших картинок. Для картинки на 50 Кб имхо смысла делать превьюшку, усложнять код и перегружать дохлый процессор мобильного телефона смысла нет.
Вы меряли, сколько одна SVG ест процессора, и сколько они едят, если их на странице 30-40?
Плюс, как мне кажется, превьюшки могут иметь смысл для каких-то больших картинок. Для картинки на 50 Кб имхо смысла делать превьюшку, усложнять код и перегружать дохлый процессор мобильного телефона смысла нет.
Вы меряли, сколько одна SVG ест процессора, и сколько они едят, если их на странице 30-40?
Для картинки на 50 Кб имхо смысла делать превьюшку нет
Если превьюшка-заглушка соразмерна картинке то да, но простой прямоугольник (он где-то 150-170 байтов занимает) вполне можно в саму страницу вставлять, особенно если картинки грузятся откуда-нибудь издалека и с задержкой. Не в обязательном порядке, конечно.
А размытые SVG картинки и картинки с большим количеством треугольников не нагружают CPU клиента, мешая ему загружать сайт? Вы меряли, сколько одна SVG ест процессора, и сколько они едят, если их на странице 30-40?
Все, что связано с фильтрами, в больших количествах нагружает что угодно, с этим не стоит злоупотреблять. С треугольниками нагрузка не очень сильная, по всей видимости браузеры умеют это оптимизировать. Те же 30 картинок с треугольниками рендерятся считанные миллисекунды (железо для тестов не самое топовое — пентиум со встроенной графикой).
Что-то у меня подозрение, что половину примеров быстрее и производительнее сделать какой-нибудь гифкой.
Вот, например, с последним примером отлично справляется гифка в 1262 байта (можно ещё слегка накатить CSS3 blur filter для большей красоты, но Хабр не даёт просто) (а ещё Хабр игнорирует высоту картинки, прописанную мной, поэтому она получилась квадратная):
Вот, например, с последним примером отлично справляется гифка в 1262 байта (можно ещё слегка накатить CSS3 blur filter для большей красоты, но Хабр не даёт просто) (а ещё Хабр игнорирует высоту картинки, прописанную мной, поэтому она получилась квадратная):
А если гифке слегка подрезать палитру, то получается вообще 585 байт: jsfiddle.net/7w432nyq
Если в SVG подрезать палитру, то в сжатом виде эта картинка тоже будет около 500 байтов, а фильтры в любом случае нагружают железо при отрисовке. Так что что из этого производительнее — большой вопрос. Но этот пример скорее дополнительный, гораздо интереснее с треугольниками и мозаикой — их гифкой уже не получится повторить.
Мозаика отлично делается той же самой гифкой: jsfiddle.net/7w432nyq/2
А треугольники лично мне просто не нравятся)
А треугольники лично мне просто не нравятся)
Угу. Тот самый момент когда растр побеждает вектор, который хочет быть похож на растр, который забыл что толстеет в зависимости от своей фантазии.
Тут главное не забывать, что SVG, в отличии от растровых картинок, поддается различным манипуляциям. Для дизайнерских сайтов, где грузят большие картинки на весь экран, возможность к примеру «разваливать мозаику с поворотами элементов в разные стороны» или «в случайном порядке растворять треугольники» может быть очень к месту. Да и фильтры можно любые делать, не только размытие — например те же самые «помехи», которые постепенно проявляются в конечную картинку. Понятно, что за это придется платить ресурсами процессора, но все же.
Градиентные сетки были бы тоже интересны, но эти чертяки еще не реализованы.
graphicdesign.stackexchange.com/questions/105403/svg-gradient-implementation
graphicdesign.stackexchange.com/questions/105403/svg-gradient-implementation
"Это один из тех моментов, когда полезно знать, какие математические алгоритмы в нашей области существуют и в чем в них разница."
Вот кстати да: не занимался ли кто-нибудь таким… FAQ или даже может энциклопедией "Математика для программиста"?
Чтобы сжато, по делу, может действительно — ключевые слова для гугла и пример реализации на одном из распространённых языков — по разным областям информатики и программирования. Не только рисование.
В плане примеров реализации — есть каталог rosetta code. Там собирают решения самых разных задач на самых разных языках. А просто список популярных алгоритмов по категориям есть на той же википедии.
А как-же progressive jpeg?
А есть еще такая штука SQIP
Вот неплохой пример использования подхода:
stripe.com/environment
За счет внедрения SVG в код HTML страницы, исключается ситуация пустого фона
stripe.com/environment
За счет внедрения SVG в код HTML страницы, исключается ситуация пустого фона
Sign up to leave a comment.
Генерируем красивые SVG-плейсхолдеры на Node.js