Comments 39
Как вариант:
Узнаем jsом ppi и если у пользователя retina дописываем в href всех img «2х» перед расширением.
Узнаем jsом ppi и если у пользователя retina дописываем в href всех img «2х» перед расширением.
0
Если речь об обработке загруженной страницы, то пользователь накажет себя на загрузку неоптимизированных и оптимизированных изображений (т.е. оба комплекта).
+2
Ох, нагородите сейчас, лучше начните использовать css4 image-set, с префиксом оно уже поддерживается в Safari 6 and Chrome 21, для остальных же high dpi устройств и избранных изображений используйте вдвое больше пикселей втиснутых в нужных объём и более агрессивное сжатие, всё
blog.cloudfour.com/safari-6-and-chrome-21-add-image-set-to-support-retina-images/
blog.cloudfour.com/safari-6-and-chrome-21-add-image-set-to-support-retina-images/
+4
А как быть с пользовательским контентом?
0
А это должно быть на стороне CMS при формировании страницы. У вас же кука есть.
И раз вы можете заставить CMS делать две версии картинки, заставьте её отдавать разные линки в /img/.
И раз вы можете заставить CMS делать две версии картинки, заставьте её отдавать разные линки в /img/.
0
А если усложним задачу кэшированием?
0
А так сложно закешировать две версии? =)
Я вообще не знаю, я только на Django пишу, и не вижу никаких препятствий.
В других местах могут быть.
Я вообще не знаю, я только на Django пишу, и не вижу никаких препятствий.
В других местах могут быть.
0
Подумал, в принципе выполнимо. Динамический контент перед кэшированием обработать по выставленной куке и сформировать два кэша не проблема. Но ведь есть еще и статические шаблоны. Как быть с ними? Тоже два комплекта? ИМХО оно получится слишком трудно-управляемым со временем.
0
В Django я б написал шаблонный тег IMG и везде применял бы его.
А для передачи куки в шаблон сделал бы Context Processor, так что тег бы всегда знал что в куке.
А для передачи куки в шаблон сделал бы Context Processor, так что тег бы всегда знал что в куке.
0
Хм, но
В моем случае, при необходимости, в течение пары минут статика перетаскивается на nginx без перекройки всего кода. Если бы удалось уйти от серверного php скрипта только с помощью обработчика в nginx способ стал бы реально универсальным. Есть спецы? Ау?
<img>
это только часть проблемы. Во-первых есть CSS. Во-вторых, есть различные ajax загрузчики контента на сервер, появляется необходимость обработки статических шаблонов и т.д. и т.п. Другими словами, мы либо не покрываем всех картинок либо способ становится неуправляемо интегрируемым со скриптами CMS (что также не очень хорошо, так как лишает гибкости).В моем случае, при необходимости, в течение пары минут статика перетаскивается на nginx без перекройки всего кода. Если бы удалось уйти от серверного php скрипта только с помощью обработчика в nginx способ стал бы реально универсальным. Есть спецы? Ау?
0
Я сделал вот таким образом:
Если запрашивается картинка @2x и ее нет на сервере, то отдается обычная картинка.
Вместо =404 можно написать свой обработчик (например, переслать в php-fpm и тд)
Название куки, которую нужно установить «retina». Соответственно, 1 — ретина, что-то другое — не ретина.
При таком подходе для всех картинок на сайте обязательно указывать width и height. Для через аттрибуты или через css-свойства, а для фоновых картинок нужно указывать background-size: width height.
if ($cookie_retina = 1) { rewrite ^/images/(.*?)\.(jpg|png|gif) /images/$1@2x.$2; } location ~ /images/(.*?)@2x\.(jpg|png|gif) { try_files $uri /images/$1.$2 =404; }
Если запрашивается картинка @2x и ее нет на сервере, то отдается обычная картинка.
Вместо =404 можно написать свой обработчик (например, переслать в php-fpm и тд)
Название куки, которую нужно установить «retina». Соответственно, 1 — ретина, что-то другое — не ретина.
При таком подходе для всех картинок на сайте обязательно указывать width и height. Для через аттрибуты или через css-свойства, а для фоновых картинок нужно указывать background-size: width height.
+1
A на Android планшетах с ретиной это сработает?
-1
Не пробовал, нужно лишь выполнить JS и посмотреть что вернет. Думаю да.
0
JS то ни куда не денется.
Я про css4 image-set.
Я про css4 image-set.
0
Технический приём, связанный с употреблением CSS4 image-set, не может работать почти ни на одной из современных версий системы Android, раз уж о его появлении нам сообщили в августе 2012 года.
Есть ли хоть одна версия Android, появившаяся после августа?
Только одна — 4.1.2, за октябрь 2012 года. (Предыдущая версия, 4.1.1, появилась 9 июля.)
Много ли у кого версия 4.1.2 установлена? (Вопрос риторический, с подразумеваемым отрицательным ответом.)
Сопровождался ли её выход изменениями в коде Android Browser, или производители решили «работает — не трогай!»? (Вопрос не риторический, ответа я не знаю.)
Есть ли хоть одна версия Android, появившаяся после августа?
Только одна — 4.1.2, за октябрь 2012 года. (Предыдущая версия, 4.1.1, появилась 9 июля.)
Много ли у кого версия 4.1.2 установлена? (Вопрос риторический, с подразумеваемым отрицательным ответом.)
Сопровождался ли её выход изменениями в коде Android Browser, или производители решили «работает — не трогай!»? (Вопрос не риторический, ответа я не знаю.)
0
if (file_exists($_GET['img']) && isImg ($_GET['img']))
die (file_get_contents($_GET['img']));
Оригинальный способ отдачи контента. Лучше использовать функцию readfile(), которая не читает в память весь файл перед выводом. А еще лучше сказать веб-серверу, какой файл нужно отдать с помошью специального заголовка. Но такой фокус я знаю только для nginx, не знаю, есть ли в apache что-то подобное.
+1
Тут согласен. Но, readfile() не везде доступна.
А вот по поводу заголовка для nginx можно по-подробнее?
А вот по поводу заголовка для nginx можно по-подробнее?
0
Средствами nginx я немного выше предложил решение
+1
В этом топике для Апача описывали способ.
0
> Разумеется, это изменение увеличило нагрузку на сервер
Разумеется.
Если я вас правильно понял, то убрать весь этот олдскульный огород с прогоном каждой картинки через php+apache вам помогут три строчки на nginx.
Ставите nginx. Всем изображениям в коде сайта добавляете префикс "/2x", если человек с ретины.
Скажем, было /images/pic.jpg, стало /2x/images/pic.jpg
Далее пишете в конфиге:
Оптимизированные изображения, соответственно, заливаете в папку /2x соответственно текущей структуре.
Разумеется.
Если я вас правильно понял, то убрать весь этот олдскульный огород с прогоном каждой картинки через php+apache вам помогут три строчки на nginx.
Ставите nginx. Всем изображениям в коде сайта добавляете префикс "/2x", если человек с ретины.
Скажем, было /images/pic.jpg, стало /2x/images/pic.jpg
Далее пишете в конфиге:
location ~ ^/2x/(.+)$ {
try_files $uri /$1 =404;
}
Оптимизированные изображения, соответственно, заливаете в папку /2x соответственно текущей структуре.
0
Перечитал еще раз задачу. Решение для кук:
1. Аналогично ставите куку перед загрузкой страницы: если ретина, кука retina = 1, если нет, то куки retina нет.
2. Пути к изображениям остаются неизменными, никаких префиксов /2x и т.д.
3. Кладете оптимизированные изображения в папку /2x/… и далее согласно текущей структуре файлов на сайте.
4. Конфиг nginx:
Суть в том, что сервер проверяет наличие куки «retina». Если она есть, перенаправляет файлы на префикс /2x. Далее смотрит: если файл есть в 2x — отдает ретина-версию, если нет — отдает файл по старому пути.
1. Аналогично ставите куку перед загрузкой страницы: если ретина, кука retina = 1, если нет, то куки retina нет.
2. Пути к изображениям остаются неизменными, никаких префиксов /2x и т.д.
3. Кладете оптимизированные изображения в папку /2x/… и далее согласно текущей структуре файлов на сайте.
4. Конфиг nginx:
if ($http_cookie ~ "retina" ) {
set $retina 1;
}
location ~ ^/2x/(.+)$ {
try_files $uri /$1 =404;
}
location ~* ^.+.(jpg|jpeg|gif|png)$ {
if ($retina = 1) {
rewrite (.+) /2x$1;
}
}
Суть в том, что сервер проверяет наличие куки «retina». Если она есть, перенаправляет файлы на префикс /2x. Далее смотрит: если файл есть в 2x — отдает ретина-версию, если нет — отдает файл по старому пути.
+3
Ну почему же, возможно. Вот для постфикса @2x:
В этом случае файлы остаются там же, где и были, просто pic.jpg становится pic@2x.jpg (описанный в вашем посте вариант). По-прежнему проверяем на куку «retina», если есть — отдаем @2x изображения. Пути к картинкам править, опять же, нигде не надо.
if ($http_cookie ~ "retina" ) {
set $retina 1;
}
location ~* ^(.+)@2x.(jpg|jpeg|gif|png)$ {
try_files $uri $1.$2 =404;
}
location ~* ^.+.(jpg|jpeg|gif|png)$ {
if ($retina = 1) {
rewrite ^(.+).(jpg|jpeg|gif|png)$ $1@2x.$2;
}
}
В этом случае файлы остаются там же, где и были, просто pic.jpg становится pic@2x.jpg (описанный в вашем посте вариант). По-прежнему проверяем на куку «retina», если есть — отдаем @2x изображения. Пути к картинкам править, опять же, нигде не надо.
0
Великолепно! Вечером попробую, если все получится, внесу правку в статью для глупого решения с apache и отличного варианта с nginx. Спасибо. Плюсанул бы, но кармы не хватает :)
0
Apache в принципе-то не виноват. Просто в вашем варианте картинки гоняются через php-скрипт, а это большая нагрузка. mod_rewrite апача я уже не помню за давностью, но уверен, что на нем тоже можно реализовать подобную схему проверки существования файла.
0
Странно, в конфиге nginx этот код приводит к тому, что картинки вообще не отображаются. Куку не выставлял, опробовал без нее.
0
Собственно выше это решение было предложено и оно (вместе с вашим) наиболее оптимальное для данной задачи.
0
лучшим способом адаптацииВообще-то он вполне применим.на сегодняшний день является способc background-image в CSS. Но он не применим к обычным изображениямв теге <img>
В вики Stylish излагается вот какой действенный рецепт подмены изображения при помощи CSS:
IMG#идентификаторКартинки {
/* обнуляем размеры имеющейся картинки: */
height: 0 !important;
width: 0 !important;
/* задаём размеры новой картинки: */
padding-left: 125px !important;
padding-top: 25px !important;
/* задаём адрес новой картинки: */
background: url(http://example.com/адрес/иллюстрации) no-repeat !important;
}
Достаточно засунуть этот код внутрь Вашей обёртки
0
Mithgolда, действительно, это вариант, но:
1. В большом проекте мы будем вынуждены картинки background дизайна в css обрабатывать вручную;
2. Способ не подойдет при большом количестве «внедрений» картинок (во всех шаблонах надо указывать id картинки, а если есть генерация лайтбоксов на js — опять же придется перерыть весь код и в части мест внести изменения не удастся, т.к. id тега может быть занятым;
3. Самое главное. Для каждой страницы @media css придется генерировать скриптами. А если на страницу аяксом подгрузится еще картинка — всплывут проблемы.
За способ спасибо, для статики он применим на ура!
1. В большом проекте мы будем вынуждены картинки background дизайна в css обрабатывать вручную;
2. Способ не подойдет при большом количестве «внедрений» картинок (во всех шаблонах надо указывать id картинки, а если есть генерация лайтбоксов на js — опять же придется перерыть весь код и в части мест внести изменения не удастся, т.к. id тега может быть занятым;
3. Самое главное. Для каждой страницы @media css придется генерировать скриптами. А если на страницу аяксом подгрузится еще картинка — всплывут проблемы.
За способ спасибо, для статики он применим на ура!
0
А что, сейчас все экраны с высокой плотностью Ретиной называют?
0
С одной стороны, куки для того и придуманы, чтобы влиять на генерацию контента, но с другой, содержимое «статического» файла будет определяться не только урлом, но и кукой — костыльно выглядит, как минимум всякое кеширование ломается сходу, и далеко не все cdn для статики смогут такие запросы правильно обработать.
Хорошее решение должно оперировать только урлами. Это сложно, не спорю, надо лезть в движок сайта, одними шаблонами с добавленным JS кодом не обойдешься уже… ((
Хорошее решение должно оперировать только урлами. Это сложно, не спорю, надо лезть в движок сайта, одними шаблонами с добавленным JS кодом не обойдешься уже… ((
0
Sign up to leave a comment.
Комплексная подготовка сайта к Retina