Обнаружение Ретины

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

Наиболее животрепещущий вопрос — подготовка изображений для Ретины.

Напомню, что Ретина — технология Эпл, ставшая уже нарицательной, заключающаяся в примерении экранов высокого разрешения (например, на моём ноуте это 2560×1600) с отображением на нём обычной графики так, как бы это выглядело на экранах вдвое низкого разрешения. При этом шрифт смотрится просто великолепно, как на бумаге, а вот с картинками беда.

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

Пока ещё не у всех Ретины, хочется, чтобы клиенты, у которых её нет, не грузили лишнего. К сожалению, загвоздка в том, что браузеры пока не научились сообщать серверу, что мы имеем дело с таким (пока) необычным экраном и есть только клиенские способы выяснить это.

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

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

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

А пока, у меня такое решение. Используем старые-добрые «печеньки» и mod_rewrite.

На стороне клиента первой строкой каждой нашей страницы ставим проверку по «ретиновые» экраны с установкой «печенья»:
<script>if(window.devicePixelRatio>=2)document.cookie='retina=1'</script>
Этот скрипт выполнится первым и все дальнейшие запросы на сервер будут содержать строку «retina=1», если мы имеем дело с Ретиной. Все изображения, для которых у нас есть две копии — обычная и «ретиновая» (в два раза большая) называем одинаково, но с постфиксом «@2x» для большей, при этом в коде указываем данные разрешения для более мелкой картинки:
<img src="/images/owl@2x.jpg" width="400" height="560" alt="Совушка">
Сейчас, конечно, Апач теряет популярность, но я воспользуюсь синтаксисом mod_rewrite, желающие могут переделать в Энжин Икс или какой-то другой синтакис:
RewriteEngine On

RewriteCond %{HTTP_COOKIE} !retina=1
RewriteRule (.*)@2x\.(gif|jpe?g|png|webp) $1.$2 [L,NC]
Этот код означает, что если не установлено «печенье» «retina=1», то нужно убрать постфикс «@2x» из имени картинки.

В итоге, если у нас Ретина, «печенька» ставится в самом начале, все дальнейшие запросы к серверу идут с ней и картинки грузятся как указано в коде — например, если указано «owl@2x.jpg», то эта картинка и грузится.

Если у нас обычный экран, «печеньки» нет, запросы к серверу идут без неё и из картинок вырезается постфикс «@2x», т.е. картинка «cat.jpg» грузится по своему имени, а вместо «owl@2x.jpg» загрузится «owl.jpg».

Voilà!
23 мая 2013 21:33

Бабаев Александр (bealex.moikrug.ru)
23 мая 2013, 22:31

Если @2 заменить на @2x, то будет вообще отлично. Почему так? Без особой причины, просто при разработке приложений для iOS используется похожий принцип, когда кладется две картинки рядом и, если у нас ретина, iOS выбирает ту, в которой приписан суффикс @2x. Ну, типа, унифицированно.

А так — классная идея, действительно классная.

Андрей Ситник (инкогнито)
23 мая 2013, 22:32

Со всей этой магией с определением ретины, есть очень интересный нюанс.

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

Есть ещё более сложный вопрос. Как минимум картинки оформления сайта лучше заинлайнить в ЦСС. Но тут уже надо делать магию с загрузкой разных ЦСС в зависимости от кук.

В итоге, мне кажется, что проще не определять тип экрана и всегда отдавать картинки для ретины.

hshhhhh (hshhhhh.name)
23 мая 2013, 23:04

как бы это выглядело на экранах вдвое низкого разрешения.
на экранах с разрешение вдвое меньше?

petya (инкогнито)
23 мая 2013, 23:25

А как по дефолту отображаются на ретине сайты, где размеры сетки, шрифтов и картинок указаны в пикселях? Наверное, все равно какое-то масштабирование имеет место?

artuska (инкогнито)
23 мая 2013, 23:28

А почему отрицание «НЕ»? Ну, как-то человечнее всё же размышлять «если есть ретина, то делаем то-то и то-то»

    RewriteCond %{HTTP_COOKIE} retina=1

, не? Или вот сюда — $1.$2 [L,NC] — проблематично вставить символ «@»?

Leonya (инкогнито)
24 мая 2013, 00:10, ответ предназначен petya

Так же отображаются, у ретина-экранов в 4 раза больше физических пикселей, а логических - столько же, сколько было раньше.

Евгений Степанищев (bolknote.ru)
24 мая 2013, 06:14

Давайте я всем сразу отвечу, а не по одному комментарию :)
Если @2 заменить на @2x, то будет вообще отлично. Почему так? Без особой причины, просто при разработке приложений для iOS используется похожий принцип, когда кладется две картинки рядом и, если у нас ретина, iOS выбирает ту, в которой приписан суффикс @2x. Ну, типа, унифицированно.
Ага, я постфикс неправильно вспомнил :) Думаешь, это так важно?
Большинство экранов, где нет «ретины» — имеют хорошее подключение к Интернету. Низкая скорость обычно у телефонов, который как раз имеют ретину. В итоге, те, кому действительно надо трафик экономить нуждаются в ретине.
Можно же опеределять, что подключение плохое, особенно на «Андроидах»: http://bolknote.ru/2011/07/21/~3341/
Есть ещё более сложный вопрос. Как минимум картинки оформления сайта лучше заинлайнить в ЦСС. Но тут уже надо делать магию с загрузкой разных ЦСС в зависимости от кук.
Не, тут не надо. Можно просто сделать media queries и делать @import в этом условии.
на экранах с разрешением вдвое меньше?
Не понял в чём вопрос.
А почему отрицание «НЕ»? Ну, как-то человечнее всё же размышлять «если есть ретина, то делаем то-то и то-то»
Потому что серверной стороне надо как-то знать какие картинки готовы для Ретины, а какие — нет. Серверная сторона узнаёт это по постфиксу.

Toz (инкогнито)
24 мая 2013, 07:03

У лебедева про jpeg немного неверно проиллюстрированно. И если остановить загрузку посередине, то картинка будет гораздо более худшего качества чем если бы она была с вдвое меньшим разрешением. Можно убедиться на медленных соединениях, что картинка даже перед самым последним "проходом" загрузки оставляет желать лучшего.

rodem (инкогнито)
24 мая 2013, 07:03

Seeing the World Through High DPI - Google I/O 2013
https://www.youtube.com/watch?v=alG-UwRWV_U
Небольшой доклад в тему с Google I/O 2013.

Евгений Степанищев (bolknote.ru)
24 мая 2013, 07:10, ответ предназначен Toz

Можно убедиться на медленных соединениях, что картинка даже перед самым последним "проходом" загрузки оставляет желать лучшего.
Я уже давно не видел медленного соединения, потому и не помню уже как это выглядит :) Если будет время, поэксперементирую.

Евгений Степанищев (bolknote.ru)
24 мая 2013, 08:24, ответ предназначен rodem

Небольшой доклад в тему с Google I/O 2013.
Ничего себе маленький — 40 минут! Гелекси Эс IV — 441 dpi! Божежьмой!

rodem (инкогнито)
24 мая 2013, 11:24

Кстати, вот же ещё srcset:
http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/
Того и гляди скоро появится кругом.

Евгений Степанищев (bolknote.ru)
24 мая 2013, 12:01, ответ предназначен rodem

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

А пока даже border-width нельзя сделать в один физический пиксель толщиной!

Бабаев Александр (bealex.moikrug.ru)
24 мая 2013, 12:39, ответ предназначен Евгений Степанищев (bolknote.ru):

Ага, я постфикс неправильно вспомнил :) Думаешь, это так важно?
Если будет единый стандарт, тогда проще будет менять скрипты, на него будут рассчитывать и так далее. А сейчас самый массовый вариант именно на Айфонах и с @2x. На Андроидах все рассовывается по папкам, но это, как мне кажется, чуть менее наглядно получается. Труднее видеть, что заретинено, что нет. Поэтому я для себя бы выбрал именно Айфонный вариант.

(это все размышления, конечно же все это ерунда и главное, чтобы выглядело красиво)

petya (инкогнито)
25 мая 2013, 12:15, ответ предназначен Leonya

Так же отображаются, у ретина-экранов в 4 раза больше физических пикселей, а логических - столько же, сколько было раньше.
Ну тогда весь этот сыр-бор просто не нужен. Гоняться за особенностями каких-то девайсов - неблагодарное занятие. Увеличивать размер страниц и итоговый трафик, добавлять серверный код для обработки изображений, учитывая при этом все возможные действия с этими изображениями, и всё это только ради того, чтобы где-то на ретине картинка выглядела чуть лучше (и не исключено, что для этого обычному человеку понадобится микроскоп)? Не вижу смысла...

Un1oR (инкогнито)
25 мая 2013, 12:52

http://pepelsbey.net/pres/clear-and-sharp/

Евгений Степанищев (bolknote.ru)
25 мая 2013, 15:42, ответ предназначен petya

Ну тогда весь этот сыр-бор просто не нужен. Гоняться за особенностями каких-то девайсов — неблагодарное занятие. Увеличивать размер страниц и итоговый трафик, добавлять серверный код для обработки изображений, учитывая при этом все возможные действия с этими изображениями, и всё это только ради того, чтобы где-то на ретине картинка выглядела чуть лучше (и не исключено, что для этого обычному человеку понадобится микроскоп)? Не вижу смысла…
Это нормально — не видеть в этом смысла, обычные люди в будущее не смотрят.

Евгений Степанищев (bolknote.ru)
25 мая 2013, 15:43, ответ предназначен Un1oR

http://pepelsbey.net/pres/clear-and-sharp/
Простите, а вы с какой целью привели эту ссылку? Там есть решение лучше, чем предложенное мною или что?

petya (инкогнито)
25 мая 2013, 19:24, ответ предназначен Евгений Степанищев (bolknote.ru):

Это нормально — не видеть в этом смысла, обычные люди в будущее не смотрят.
Будущее должно быть лучше настоящего, а ресайз графики под клиента - это тупиковый путь. Раньше в веб-дизайне считалось очень дурным тоном вставлять картинку на страницу, насильно масштабируя ее атрибутами, а теперь вот некоторые (тот же пепелсбей!) советуют именно так и делать, заставляя клиента при открытии каждой фотки выполнять двумерную интерполяцию!
Кроме того, новые технологии должны облегчать жизнь, а не усложнять. Одно дело - это когда есть технология Х, которая поддерживается клиентами на уровне стандарта, а другое - это когда для поддержки нужно изобретать велосипеды, а потом еще и самостоятельно поддерживать и допиливать эти велосипеды.

Максим Зотов (maxim-zotov.livejournal.com)
25 мая 2013, 23:40

Не думаю, что костыли под ретину, это будущее.
 
Будущее за полным отказом от пикселей (когда отдельный пискель станет значительно меньше разрешающей способности глаза), векторной графикой и фотоформатом, приспособленным под произвольное разрешение. Из совсем утопического - фрактальное сжатие, из более реального - насколько я помню, для вейвлет-кодирования выходное разрешение не очень важно, картинка будет гладкой в любом случае, результат лучше, чем у масштабированного jpeg.

Евгений Степанищев (bolknote.ru)
26 мая 2013, 09:05, ответ предназначен petya

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

Времена меняются и как было раньше никого не волнует, кроме историков.
Будущее должно быть лучше настоящего, а ресайз графики под клиента - это тупиковый путь… Кроме того, новые технологии должны облегчать жизнь, а не усложнять. Одно дело — это когда есть технология Х, которая поддерживается клиентами на уровне стандарта, а другое — это когда для поддержки нужно изобретать велосипеды, а потом еще и самостоятельно поддерживать и допиливать эти велосипеды.
Простите, а вы вообще вёрсткой занимаетесь? Большая часть того, что сейчас появляется, лишь усложняет жизнь — начиная с «дивной» вёрстки.

Евгений Степанищев (bolknote.ru)
26 мая 2013, 09:11, ответ предназначен Максим Зотов (maxim-zotov.livejournal.com):

Не думаю, что костыли под ретину, это будущее.
Конечно не это будущее. Будущее — костыли для тех, у кого не Ретина. Чуть более далёкое будущее — отказ от неретиновых экранов
Будущее за полным отказом от пикселей (когда отдельный пискель станет значительно меньше разрешающей способности глаза), векторной графикой и фотоформатом, приспособленным под произвольное разрешение. Из совсем утопического — фрактальное сжатие, из более реального — насколько я помню, для вейвлет-кодирования выходное разрешение не очень важно, картинка будет гладкой в любом случае, результат лучше, чем у масштабированного jpeg.
Чудесное будущее, но пока недостижимое. Фрактальное и вейвлетное сжатие нас не спасут, нет у них этих чудесных свойств, на которые вы рассчитываете. Нас мог бы спасти ИИ, который смог бы перерисовывать любое фото в любое разрешение, но смысла в этом нет — у глаза конечные возможности, 250 точек на дюйм это для него совсем не предел, конечно, но стоит поднять это вчетверо и глаза уже не различат где 1000, а где 2000 dpi.

Konstantin (инкогнито)
26 мая 2013, 09:15

Главная проблема ретины - об ее поддержке задумываются только те, кто покупает себе макбук с ретиной. :)

Евгений Степанищев (bolknote.ru)
26 мая 2013, 09:32, ответ предназначен Konstantin

Главная проблема ретины — об ее поддержке задумываются только те, кто покупает себе макбук с ретиной. :)
Главная проблема Ретины в том, что люди думают, что она только в технике Эпл. Ретина, конечно, торговая марка Эпл, но люди вокруг зовут ретинами любые экраны с большими dpi.

Теперь посмотрите на картинку:

Снимок экрана 2013-05-26 в 10.28.08.pnghttp://fotki.yandex.ru/users/bolknote/view/466034/?page=2

Это кадр из выступления на Google I/O, ссылку на которую мне дали выше. Естественно, это не вся техника с большим dpi, пожалуй, сейчас труднее найти смартфоны без ретины, чем с ретиной. На очереди планшеты, раз Эпл там сделал Ретину, то появятся (если ещё не появились) ретиновые планшеты других производителей. Ноутбуки будут появляться медленнее всего (всё-таки это дорого), но шаг уже сделан — на картинке представлен Хроумбук с ретиной.

petya (инкогнито)
26 мая 2013, 10:31, ответ предназначен Евгений Степанищев (bolknote.ru):

Раньше считалось дурным тоном в хорошем обществе иметь загар и заниматься зарядкой, а теперь, смотрите-ка, все наоборот!
Извините, но аналогия неудачная. Вы говорите о каких-то древних предрассудках, а я говорю о том, что было совсем недавно, и имело под собой вполне здравые и логичные основания.
Простите, а вы вообще вёрсткой занимаетесь? Большая часть того, что сейчас появляется, лишь усложняет жизнь — начиная с «дивной» вёрстки.
Занимаюсь, причем очень давно, иначе бы не писал на эту тему. Насчет дивной верстки - она базируется на нормальной поддержке браузерами CSS (второй версии), и когда эта долгожданная поддержка повсеместной, она сильно УПРОСТИЛА жизнь верстальщика.

Евгений Степанищев (bolknote.ru)
26 мая 2013, 10:41, ответ предназначен petya

…что было совсем недавно, и имело под собой вполне здравые и логичные основания.
Имело — хорошее слово. Раньше смысла масштабировать картинку не было, это было вредно — лишний трафик и никакой пользы. Теперь есть очевидная польза.
Насчет дивной верстки — она базируется на нормальной поддержке браузерами CSS (второй версии), и когда эта долгожданная поддержка повсеместной, она сильно УПРОСТИЛА жизнь верстальщика.
И как только верстальщики стали её повсеместно использовать, оказалось, что во многих случаях она не делает то, что нужно — не даёт поменять страницу как хочется, а так же не даёт гибко задавать layout. И полезли всякие флексбоксы, vw/vh и прочее.

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

Сверстать таблицами мог любой дурак 10 лет назад, сейчас нормально сверстать дивами что угодно, порой, задача нетривиальная.

petya (инкогнито)
26 мая 2013, 16:38, ответ предназначен Евгений Степанищев (bolknote.ru):

Раньше смысла масштабировать картинку не было, это было вредно — лишний трафик и никакой пользы. Теперь есть очевидная польза.
Давайте рассмотрим этот вопрос на примере "обычного" сайта. Допустим, это блог, куда заливаются картинки размером 800*600 точек. Возьмем три ситуации: 1) картинка заливается и вставляется на страницу в своем реальном размере 800*600 (предварительно обработанная в редакторе, либо же обработка происходит автоматически во время загрузки); 2) картинка заливается в размере в 2 раза больше (1600*1200), а вставляется как 800*600; 3) происходит определение разрешения экрана пользователя (как в вашем варианте), сервер отдает нужную версию картинки, а вставляется все равно как 800*600.
В случае 1 ситуация такая - все *получат* и почти гарантированно *увидят* одно и то же изображение, на сервере один файл, лишнего кода нет.
В случае 2 ситуация такая - все *получат* (но вряд ли *увидят*!) одно и то же изображение, на сервере один файл, лишнего кода нет. Что *увидят* пользователи сайта, зависит от браузера, а если точнее - от алгоритма ресемплинга изображений, который будет применен для отображения картинки в "неродном" разрешении. И этот алгоритм будет *точно* не самым лучшим по качеству, иначе страницы бы открывались по несколько секунд с полной загрузкой процессора! Скорее всего, это будет какая-нибудь билинейная интерполяция, чтобы побыстрее. И результат будет явно хуже варианта 1. Кроме того, 99% юзеров видят сайт на обычном мониторе, и они никаких эффектов, кроме ухудшения картинки, увеличения времени загрузки и тормозов браузера при прокрутке страницы, не увидят.
В случае 3 ситуация такая - на сервере N изображений, которые отдаются клиенту в зависимости от его разрешения, каждый *получит* свою версию, хотя все версии все равно будут вставляться на страницу в одном размере, и если этот размер *не* родной для конкретного файла, то см. выше о ресемплинге. Ну и еще лишний код и на сервере, и на клиенте.
Так где же "очевидная польза"? В том, что обладатели экранов с высоким разрешением, возможно, получат картинку чуть лучше (хотя они ее скорее всего не просили)? Мне кажется, игра не стоит свеч.

Евгений Степанищев (bolknote.ru)
26 мая 2013, 18:01, ответ предназначен petya

1) картинка заливается и вставляется на страницу в своем реальном размере 800×600 (предварительно обработанная в редакторе, либо же обработка происходит автоматически во время загрузки); 2) картинка заливается в размере в 2 раза больше (1600×1200), а вставляется как 800×600
В случае 1 ситуация такая: все получат и почти гарантированно увидят одно и то же изображение, на сервере один файл, лишнего кода нет.
В случае 2 ситуация такая: все получат (но вряд ли увидят!) одно и то же изображение, на сервере один файл, лишнего кода нет. Что увидят пользователи сайта, зависит от браузера, а если точнее — от алгоритма ресемплинга изображений, который будет применен для отображения картинки в «неродном» разрешении.
Вы какую-то ерунду, простите, сейчас говорите, что выдаёт незнание вами предмета.

В случае №1 масштабированное изображение увидят пользователи Ретины — картинка 800×600 при указанных размерах 800×600 растянется до 1600×1200. В случае №2 ровно наоборот — пользователи Ретины увидят всё нормально, а пользователи без Ретины увидят смаштрабированное изображение.
И этот алгоритм будет точно не самым лучшим по качеству, иначе страницы бы открывались по несколько секунд с полной загрузкой процессора!
Вы, похоже, не представляете на что способны современные процессоры. Скажите, вы вообще замечаете, что у меня сайт сделан под Ретину и только под неё?
Скорее всего, это будет какая-нибудь билинейная интерполяция, чтобы побыстрее.
Сейчас многие браузеры позволяют переключать алгоритм, а те, которые не позволяют, используют метод ближайших соседей.
Так где же «очевидная польза»? В том, что обладатели экранов с высоким разрешением, возможно, получат картинку чуть лучше (хотя они ее скорее всего не просили)?
Да вы просто никогда не видели как смотрятся обычные изображение на Ретине. Это просто «мыло», если выбирать из двух сайтов  — сделанный для Ретины и нет, то я ни секунды не колеблясь, выберу первый.

petya (инкогнито)
26 мая 2013, 21:29, ответ предназначен Евгений Степанищев (bolknote.ru):

Вы какую-то ерунду, простите, сейчас говорите, что выдаёт незнание вами предмета.
Я думаю в первую очередь о подавляющем большинстве пользователей, у которых обычные мониторы. То, что 1% пользователей с ретиной (а может, и меньше) увидят картинки в большем разрешении, меня мало радует в сравнении с появляющимися минусами. Может, вы живете в другом мире, в котором ретины у каждого второго, но я отталкиваюсь от своей статистики. Причем я даже уверен, что по вашему сайту статистика будет сильно отличаться от средней по рунету, сюда зайдет весьма узкий контингент.
Вы, похоже, не представляете на что способны современные процессоры.
Представляю, но не вижу смысла тратить вычислительные ресурсы на манипуляции с картинками на веб-страницах, с заведомо плохим результатом.
Скажите, вы вообще замечаете, что у меня сайт сделан под Ретину и только под неё?
Для меня вопрос не в вашем сайте, а в самом этом подходе в применении к некоему среднестатистическому сайту.
Сейчас многие браузеры позволяют переключать алгоритм, а те, которые не позволяют, используют метод ближайших соседей.
Многие - это какие? Сижу на десктопе под виндой, ни в одном таких настроек не вижу. Кроме того, как вы думаете, какой процент обычных пользователей сможет переключить алгоритм ресемплинга в браузере? А метод "ближайших соседей" - это жуть...
Да вы просто никогда не видели как смотрятся обычные изображение на Ретине.
В какой-то мере это так, но не совсем - у меня эппловских устройств нет, да и не хочется, но в руках держал разные ноуты и планшеты, а насчет отображения картинок на сайтах - просто не обратил внимания, надо будет проверить. Но если картинки "замыленные", то как раз вероятно, что это результат работы не самых лучших алгоритмов масштабирования при растягивании.

petya (инкогнито)
26 мая 2013, 21:39, ответ предназначен Евгений Степанищев (bolknote.ru):

Сейчас многие браузеры позволяют переключать алгоритм
Кстати, если вы имели в виду не настройку браузера, а обработку css-свойства "image-rendering", то это тоже не вариант, т.к. реально используемый алгоритм остается загадкой.

Евгений Степанищев (bolknote.ru)
26 мая 2013, 21:46, ответ предназначен petya

Нет, не остаётся. В стандарте (http://dev.w3.org/csswg/css-images/) написано, в частности:
pixelated
When scaling the image up, the "nearest neighbor" or similar algorithm must be used, so that the image appears to be simply composed of very large pixels. When scaling down, this is the same as ‘auto’.
У Эксплорера же выпиленная сейчас фича прямо указывала алгоритм в названии: -ms-interpolation-mode:bicubic и -ms-interpolation-mode:nearest-neighbor;

Евгений Степанищев (bolknote.ru)
26 мая 2013, 22:02, ответ предназначен petya

Я думаю в первую очередь о подавляющем большинстве пользователей, у которых обычные мониторы. То, что 1% пользователей с ретиной (а может, и меньше) увидят картинки в большем разрешении, меня мало радует в сравнении с появляющимися минусами. Может, вы живете в другом мире, в котором ретины у каждого второго, но я отталкиваюсь от своей статистики.
Я вам ещё раз говорю: сейчас смартфоны без ретины встречаются реже, чем с оной. Планшеты подтягиваются, ноутбуки на очереди. Смотреть надо в будущее и учиться работать с ретиной заранее.
Представляю, но не вижу смысла тратить вычислительные ресурсы на манипуляции с картинками на веб-страницах, с заведомо плохим результатом.
Вы мне так и не рассказали чем результат плох.
Для меня вопрос не в вашем сайте, а в самом этом подходе в применении к некоему среднестатистическому сайту.
Вы утверждали выше, что сайт с картинками для ретины будет тормозить, а сами даже не замечаете, что мой сайт как раз сделан под ретину.
Многие — это какие? Сижу на десктопе под виндой, ни в одном таких настроек не вижу. Кроме того, как вы думаете, какой процент обычных пользователей сможет переключить алгоритм ресемплинга в браузере? А метод «ближайших соседей» — это жуть…
Многие — это вебкит, опера, файрфокс и ИЕ (версии 9 и ниже).
В какой-то мере это так, но не совсем — у меня эппловских устройств нет, да и не хочется
Да причём тут Эпл-то? Ретина, как я уже сказал, — уже общее название всех экранов с большим dpi.
но в руках держал разные ноуты и планшеты, а насчет отображения картинок на сайтах — просто не обратил внимания, надо будет проверить. Но если картинки «замыленные», то как раз вероятно, что это результат работы не самых лучших алгоритмов масштабирования при растягивании.
А с чего им быть не замыленным-то? Картинка вдвое увеличивается, она не может остаться качественной с любым алгоритмом.

petya (инкогнито)
26 мая 2013, 22:20, ответ предназначен Евгений Степанищев (bolknote.ru):

А у файрфокса вот что: Since version 1.9 (Firefox 3.0), Gecko uses *bilinear* resampling (*high quality*). https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering
Так что насчет ФФ я угадал... :)
Насколько я понимаю, у других под high quality подразумевается либо bilinear, либо bicubic, которые очень далеки от совершенства.

petya (инкогнито)
26 мая 2013, 23:25, ответ предназначен Евгений Степанищев (bolknote.ru):

Вы мне так и не рассказали чем результат плох.
Алгоритмами, которые просто не могут дать хорошего результата.
Вы утверждали выше, что сайт с картинками для ретины будет тормозить, а сами даже не замечаете, что мой сайт как раз сделан под ретину.
Да у вас картинок-то и нет практически, и в оформлении графики нет, а я говорю о сайтах, где на одной странице идет пара-тройка десятков больших фото в неродных разрешениях. Вот там и начинаются тормоза. А если возможностей процессора хватает, чтобы не тормозить, это все равно можно увидеть по его загрузке. У меня в трее всегда висит монитор системных ресурсов, и при заходе на такие страницы я вижу это невооруженным глазом. Есть и другие факторы, которые реально потребляют очень много ресурсов, когда используются бездумно - тени, прозрачность, и т.д.
Ретина, как я уже сказал, — уже общее название всех экранов с большим dpi.
Хорошо, пусть будет так, если "люди вокруг зовут ретинами любые экраны с большими dpi". Только вот devicePixelRaatio у них будет разным, из чего следует, что картинки для "ретин" надо генерировать либо отдельно для разных коеффициентов, либо делать одну большущую для самого большого (я так понял, что на данный момент это 3), а остальные "ретины" будут делать даунскалинг.
А с чего им быть не замыленным-то? Картинка вдвое увеличивается, она не может остаться качественной с любым алгоритмом.
Если исходное изображение качественное, то есть каждый пиксель несет информацию, то при качественном масштабировании в 2 раза на экране с такой плотностью точек, как у Ретины, этого вообще не должно быть заметно. Конкретно: для 21.5 дюймового экрана с разрешением 1920×1080 ppi составляет 102, у вашего макбука - 227, поэтому, если мы посмотрим на какую-то картинку, то на экране Ретины она будет все равно визуально меньше, даже при ее увеличении в 2 раза!

Мохов Олег (o-mokhov.ya.ru)
29 мая 2013, 06:53

Я, когда в своё время ковырял эту тему, нашел идеальное решение, которое, пока, нигде не работает – это использование content: attr(<uri>, url). Сейчас мы используем замещение через JavaScript, когда картинка грузится без src, а дальше через js замещается на src-x1 или src-x2

Евгений Степанищев (bolknote.ru)
29 мая 2013, 08:08, ответ предназначен Мохов Олег (o-mokhov.ya.ru):

Ты, кажется, где-то писал про это. Но не работающих вещей много, интереснее то, что работает :)

Валерий (инкогнито)
24 августа 2014, 19:54, ответ предназначен Евгений Степанищев (bolknote.ru):

Евгений, добрый день. Описанный вами способ обнаружения ретины очень удобен, но вот проблема: некоторые браузеры не применяют куку "retina" к запросам текущей страницы (например, последний firefox). Сначала нужно обновить страницу или перейти по ссылке, тогда уже кука будет отправлена на сервер.

Евгений Степанищев (bolknote.ru)
25 августа 2014, 06:09, ответ предназначен Валерию

Вы в этом полностью уверены? Я сейчас провёл эксперимент — стёр куку в FF и обновил страницу моего блога. Картинки прилетели именно для «ретины».

Валерий (инкогнито)
25 августа 2014, 12:04, ответ предназначен Евгений Степанищев (bolknote.ru):

Странно, спасибо, буду ещё экспериментировать.

Валерий (инкогнито)
28 августа 2014, 00:40, ответ предназначен Евгений Степанищев (bolknote.ru):

Евгений, подскажите, почему вы не указываете path и domain для куки? Получается, что в браузере будет храниться столько кук, сколько страниц пользователь посетил на сайте:)

Валерий (инкогнито)
28 августа 2014, 01:43, ответ предназначен Евгений Степанищев (bolknote.ru):

Евгений, на счёт FF - протестировал, не работает. Пробовал такой вариант ещё:

htaccess:
RewriteEngine On
RewriteCond %{HTTP_COOKIE} !retina=1
RewriteRule (.*)@rr\.(gif|jpe?g|png) $1@1x.$2 [L,NC]
RewriteCond %{HTTP_COOKIE} retina=1
RewriteRule (.*)@rr\.(gif|jpe?g|png) $1@2x.$2 [L,NC]
html:
<html>
<head>
<script>if(window.devicePixelRatio>=2)document.cookie='retina=1'</script>
</head>
<body>
<img src="./test@rr.png" width="50" height="50" alt="test">
</body>
</html>
В FF картинка для ретины показывается только после рефреша, в остальных браузерах - всё ОК.

Евгений Степанищев (bolknote.ru)
28 августа 2014, 07:42, ответ предназначен Валерию

Хм, интересно. А какая ОС?

Евгений Степанищев (bolknote.ru)
28 августа 2014, 07:44, ответ предназначен Валерию

Евгений, подскажите, почему вы не указываете path и domain для куки? Получается, что в браузере будет храниться столько кук, сколько страниц пользователь посетил на сайте:)
Мой промах :)

Валерий (инкогнито)
28 августа 2014, 12:33, ответ предназначен Евгений Степанищев (bolknote.ru):

Тестировал FF 31.0 на Mac OS 10.9.4 (с ретиной) и Windows 8 (без ретины).
Ещё опытным путём было проверено, что куку не отправляет IE 11.
Для тестирования видоизменил код следующим образом:

htaccess:
RewriteEngine On
RewriteCond %{HTTP_COOKIE} retina=y
RewriteRule (.*)@rr\.(gif|jpe?g|png) $1@2x.$2 [L,NC]
RewriteCond %{HTTP_COOKIE} retina=n
RewriteRule (.*)@rr\.(gif|jpe?g|png) $1@1x.$2 [L,NC]
html:
<html>
<head>
<script>document.cookie='retina='+(window.devicePixelRatio>=2?'y':'n')</script>
</head>
<body>
<img src="./test@rr.png" width="50" height="50" alt="test">
</body>
</html>
Ну и, соответственно, картинки называются test@1x.png и test@2x.png

Так вот, в FF и IE картинка не грузится при первом заходе (так как кука не приходит на сервер), после рефреша всё ок. В Опере, Хроме и Сафари всё работает с первого раза как надо. Пока никак не могу понять, в чём дело.

Валерий (инкогнито)
28 августа 2014, 12:35, ответ предназначен Евгений Степанищев (bolknote.ru):

Причем, фишка в том, что если заменить код:
<img src="./test@rr.png" width="50" height="50" alt="test">
на:
<script>document.write('<img src="./test@rr.png" width="50" height="50" alt="test">');</script>
то всё заработает без проблем в FF и IE.

Евгений Степанищев (bolknote.ru)
28 августа 2014, 14:55, ответ предназначен Валерию

Последнее вполне понятно. А вот поведение FF с cookie больше похоже на последствие какой-то оптимизации.

Валерий (инкогнито)
28 августа 2014, 22:06, ответ предназначен Евгений Степанищев (bolknote.ru):

Если придумаете решение - поделитесь, пожалуйста:)

Евгений Степанищев (bolknote.ru)
29 августа 2014, 07:47, ответ предназначен Валерию

Поделюсь, конечно :) Только надо как-то придумать как повторять баг. У меня под «Маком» он не повторяется.

Валерий (инкогнито)
3 сентября 2014, 17:12, ответ предназначен Евгений Степанищев (bolknote.ru):

http://tmp.figaroo.ru/retina/ - Евгений, можете проверить? Красный квадрат - картинка для не-ретины, зелёный квадрат - картинка для ретины. Если картинка не загрузилась - значит, куки нет. /* Этот комментарий после прочтения можно удалить. Если боитесь переходить по левым ссылкам - могу выложить исходный код примера. */ У меня в FF (включая 32-ую версию) под MacBookPro Retina 15 (старшая модель, 2012 г.) сначала картинка не грузится (т.к. нет куки), после рефреша показывается зеленый квадрат. В FF под виртуалкой (Parallels Desktop) в Win 8 сначала картинка не грузится, после рефреша показывается красный квадрат. В остальных браузерах сразу показывается зеленый или красный квадрат. P.S.: простите, если надоел вам с этой проблемой:)

Евгений Степанищев (bolknote.ru)
3 сентября 2014, 17:37, ответ предназначен Валерию

Хм. У меня тоже не загрузилась картинка.
P.S.: простите, если надоел вам с этой проблемой:)
Нет, не надоели, что вы.

У меня мысль возникала — что если в скрипте, где ставится куки, попробовать использовать document.open(); document.write('test'); document.close(); не изменится ли поведение FF?

Валерий (инкогнито)
3 сентября 2014, 20:38, ответ предназначен Евгений Степанищев (bolknote.ru):

Попробовал. Результат остался тем же...

Евгений Степанищев (bolknote.ru)
4 сентября 2014, 06:49, ответ предназначен Валерию

Видимо, это какая свежая оптимизация в FF. На их собственном сайте (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script) написано следующее:
Scripts without async or defer attributes, as well as inline scripts, are fetched and executed immediately, before the browser continues to parse the page.
В реальности, как мы видим, это теперь не так. Видимо, они применили какую-то новую оптимизацию. Возможно она как-то выключается. Вопрос в том — как. Я предположил, что если писать в содержимое страницы, это затормозит парсер, но нет.

А у вас нет наблюдений когда это произошло с FF? На какой версии?

Валерий (инкогнито)
5 сентября 2014, 14:14, ответ предназначен Евгений Степанищев (bolknote.ru):

Скачал FF 20.0 и 28.0 версий, потестил в них - картина не изменилась. Может быть, это не глюк FF, а я что-то не так делаю?

Евгений Степанищев (bolknote.ru)
6 сентября 2014, 11:16, ответ предназначен Валерию

Cомневаюсь. А у меня на странице работает нормально или тоже для Ретины картинки со второго раза появляются?

Валерий (инкогнито)
6 сентября 2014, 13:56, ответ предназначен Евгений Степанищев (bolknote.ru):

У меня в FF на вашем сайте грузятся картинки для ретины в независимости от того, с какого компьютера я зайду (с ретиной или без). За исключением аватарки, конечно:)

Евгений Степанищев (bolknote.ru)
6 сентября 2014, 17:05, ответ предназначен Валерию

Совсем странно. И перезагрузка страницы не помогает?

Валерий (инкогнито)
6 сентября 2014, 20:34, ответ предназначен Евгений Степанищев (bolknote.ru):

Нет. Кука R = 0, картинки для ретины.

Евгений Степанищев (bolknote.ru)
6 сентября 2014, 21:33, ответ предназначен Валерию

А как вы узнали, что картинки для ретины?

Евгений Степанищев (bolknote.ru)
6 сентября 2014, 21:34, ответ предназначен Валерию

У меня вот таким скриптом кука выдаётся:
document.cookie='R='+~~(!/mobile/i.test(navigator.appVersion)&&window.devicePixelRatio>=2)+';domain=.bolknote.ru'
Он у вас не срабатывает?

Валерий (инкогнито)
6 сентября 2014, 23:22, ответ предназначен Евгений Степанищев (bolknote.ru):

Я зашел через FF с другого компьютера (Win 8, не ретина). Посмотрел значение куки через firebug. Через него же посмотрел разрешение картинок. Кука R = 0, картинки высокого разрешения. Могу скриншот прислать))

Евгений Степанищев (bolknote.ru)
7 сентября 2014, 12:00, ответ предназначен Валерию

Нет, не надо. Лучше посмотрите что код выше у вас выдаёт под Ff, не работает он что ли?

Валерий (инкогнито)
8 сентября 2014, 17:36, ответ предназначен Евгений Степанищев (bolknote.ru):

Код-то работает, кука выставляется правильно. А вот картинки отдаются так, как будто бы кука всегда = 1.

Евгений Степанищев (bolknote.ru)
8 сентября 2014, 19:43, ответ предназначен Валерию

Странно, что-то поломалось, видимо. Разберусь потом, у меня сейчас большой проект идёт, не до этого совсем.

Евгений Степанищев (bolknote.ru)
8 сентября 2014, 20:12

Ларчик просто открывался — у меня перестали что-то значить файлы .htaccess. Видимо хостер что-то поменял в настройках.

Евгений Степанищев (bolknote.ru)
8 сентября 2014, 20:33

Так и есть. Пишу deny from all — никакой реакции. Придётся как-то иначе выкручиваться или консультироваться у хостера что это такое.

vkirkizh (kirkizh.ru)
9 сентября 2014, 00:20, ответ предназначен Евгений Степанищев (bolknote.ru):

Понятно. А я продолжу разбираться с FF.
// Это Валерий, я обзавёлся OpenID :)

Ваше имя или адрес блога (можно OpenID):

Текст вашего комментария, не HTML:

Кому бы вы хотели ответить (или кликните на его аватару)