Comments 28
Пятиминутка ненависти.
— Какое у тебя зрение?
— Минус два
— Ты понимаешь, что минус два — это диоптрии для очков, которые ты носишь?
— Что? О чем ты? Какие ещё диоптрии?
— Вот приходишь ты к окулисту и видишь таблицу. Сколько там строк видишь? Вот это и есть твое зрение.
— Да ладно тебе, я к окулисту пришел, он мне сказал: «зрение минус два».
Для того, чтобы определить остроту зрения (аналог разрешения камеры), используются таблицы Снеллена — ряды букв разного кегля, где размер и ширина знака подбраны так, чтобы стянуть угол в 1 минуту дуги на определенном расстоянии.
— Какое у тебя зрение?
— Минус два
— Ты понимаешь, что минус два — это диоптрии для очков, которые ты носишь?
— Что? О чем ты? Какие ещё диоптрии?
— Вот приходишь ты к окулисту и видишь таблицу. Сколько там строк видишь? Вот это и есть твое зрение.
— Да ладно тебе, я к окулисту пришел, он мне сказал: «зрение минус два».
Сколько там строк видишь?
Ни одной (без очков).
Мне доктор показывает пальцы, подходя ко мне, пока я не смогу разглядеть, сколько он показывает. Но на глаз оценить расстояние, на котором он при этом находится, я без очков не могу. Поэтому на вопрос
— Какое у тебя зрение?
Я просто и смело отвечаю
— Минус восемь.
Кстати, Microsoft считает, что dp = 1/96 дюйма, то есть для них dp — это просто некая физическая величина. Хочется заметить, что, если уж использовать абсолютные физические значения, лучшей практикой было бы использование миллиметров, как производную от основной единицы СИ.
Это с какой такой радости? Не знаю как там было в Windows 3.11, но в Windows 7 Microsoft считает, что px = dp / DPI, а DPI по умолчанию 96. dp при этом не физическая, а абстрактная величина, коэффициент масштабирования (DPI) можно изменить в панели управления.
В вебе, к сожалению, тоже пришли к какому-то печальному решению:
1)
2) Все абсолютные величины —
3) Реальный физический размер экрана не доступен из веба
1)
px — теперь не физический пиксель, а window.devicePixelRatio пикселей.2) Все абсолютные величины —
cm, mm, ..., тоже не имеют с реальными единицами измерения ничего общего, а лишь «примерно соответствуют им», исходя из window.devicePixelRatio и некому стандартному количеству пикселю в дюйме (72 или 96 не помню).3) Реальный физический размер экрана не доступен из веба
Ну, как написано в статье, на некоторых мобильных устройствах можно более или менее точно определить размер dp, так как user-agent может отдать например модель устройства. Однако для этого нужно иметь какие-то таблицы диагоналей и разрешений.
misclick post
Разрешение экрана все растёт и растёт, а вот информации на экран помещается все меньше. Мне нравятся старые «пиксельные» интерфейсы, где все было подогнано пиксель к пикселю, и на экран помещалось максимум информации, сейчас сделать такой интерфейс уже не реально. Да и не было «мыла», которое приносит нам вектор.
Кроме того ощущение что ты можешь различить каждый отдельный пиксель своего устройства, грело душу, сейчас курсор навести на нужный пиксель проблематично.
Правда все это в малой степени относится к приложениям win32, т.к. обычно там все контроллы с абсолютным позиционированием, да и сама windows не умеет нормально работать с высоким dpi, поэтому наверное не скоро ноутбуки с windows на ретину перейдут.
Кроме того ощущение что ты можешь различить каждый отдельный пиксель своего устройства, грело душу, сейчас курсор навести на нужный пиксель проблематично.
Правда все это в малой степени относится к приложениям win32, т.к. обычно там все контроллы с абсолютным позиционированием, да и сама windows не умеет нормально работать с высоким dpi, поэтому наверное не скоро ноутбуки с windows на ретину перейдут.
Невидимость пикселей значительно усложняет работу с графикой, например, так как становится сложнее точно подгонять элементы без костылей типа сеток и снаппинга… Интерфейсы как раз сильно абстрагированнее от пиксельной сетки не стали, причина примитивизации — в ёмкостных тачскринах: с ними by design невозможно точное позиционирование (опять-таки, без костылей типа «лапок» для выделения текста). Разрешение повышают исключительно для повышения чёткости — уменьшать размеры экранных объектов, не увеличивая резко нагрузку на зрение, уже давным-давно некуда, разве только в очках виртуальной реальности с призматическими линзами. Так-то и в старых мобильниках с DPI, близким к классическому десктопу (100-120) можно извратиться и сделать мелкие шрифты (например, в MiniCommander), чтобы больше на экран влезало, но постоянно таким пользоваться…
Тёплые, ламповые пиксели :)
Вы как хотите, обсуждайте поддержку HDPI в Windows, и прочите технические особенности, а я буду наслаждаться тем, что прочел крайне интересную статью!
Узнал очень много нового! Спасибо!
Узнал очень много нового! Спасибо!
Спойлер
Я очень сильно люблю технические детали, но эта статья мне очень сильно понравилась тем, что технические детали были размешаны личными размышлениями и биологическо-анатомическими аспектами.
Спасибо за статью, очень интересно. Разрешите я дополню ссылкой на свою статью Сколько мегабит/с можно пропустить через зрительный нерв и какое разрешение у сетчатки? Немного теории
Да, конечно, ваша статья весьма полезна. У нас, правда, немного данные по разрешению сетчатки расходятся, но я думаю это связанно с разной методой расчета активной области
Эта область вообще мутная. До сих пор спорят. Критикуйте, я буду только рад. На самом деле для меня полная загадка запихивания потока с огромным разрешением в узкий пропускной канал зрительного нерва. Я там приводил расчёты.
Кстати, у нас эту таблицу называют таблицей Сивцева.
Не обязательно проверять UA, сейчас производители устройств и браузеров нормально работают с такой штукой как DeviceAspectRatio, который может принять довольно ограниченный диапазон значений, так что вариантов устройств может быть не несколько десятков, а 3 — 4. Но даже и этот параметр не обязательно проверять, движок сам обрабатывает значения максимально комфортно.
Например, мы укажем размер текста 16px. Устройство с экраном 5 дюймов и 1080x1920 будет иметь AspectRatio равный 3, значит по высоте у него будет 640 виртуальных пикселей. Высота текста физически будет равна примерно 4,36" * 16 / 640 = 0,11 дюйма.
Возьмем другой аппарат: 4,5", 720x1280. AspectRatio будет уже 2. Те же 640px высоты. Высота текста около 3.92" * 16 / 640 = 0,1 дюйма.
Т.о. на девайсе, который мы держим чуть дальше от глаз, текст как раз чуть более крупный. В целях улучшения UX можно отловить ширину и AspectRatio и задать индивидуальный размер, это всего 3-5 вариантов. Хотя можно отталкиваться и только от ширины устройства, мне кажется этого достаточно в 95% случаев. Делаем разметку чуток резиновой местами и она будет как влитая.
И да, я за размеры в px. Потому что любые относительные величины все равно пересчитаются движком в пиксели. Любые хаки, хуки и прочие хеки разве что ускорют написание условий типа media queries. Вот в примере задан размер html в пикселях. И у body тоже. Всё дочернее, как бы вы ни описывали, все равно пересчитается в пиксели. И, как видно, эти пиксели индивидуальны для устройств и браузеров. Так что разницы на продакшене нет. Совсем. Только удобство разработки. Хотя и это тоже относительно. Лучше я буду знать, что у меня строка высотой 28px, чем пересчитывать цепочку наследований. И пиксели всё-таки могут быть более понятными. Если я знаю что девайс 540 — 640 пикселей в высоту, я примерно представляю, сколько пикселей выделить тексту. А вот сколько rem? Или dp? Каждый раз для каждого девайса пересчитывать? Нет уж, пиксели гораздо роднее и теплее.
Например, мы укажем размер текста 16px. Устройство с экраном 5 дюймов и 1080x1920 будет иметь AspectRatio равный 3, значит по высоте у него будет 640 виртуальных пикселей. Высота текста физически будет равна примерно 4,36" * 16 / 640 = 0,11 дюйма.
Возьмем другой аппарат: 4,5", 720x1280. AspectRatio будет уже 2. Те же 640px высоты. Высота текста около 3.92" * 16 / 640 = 0,1 дюйма.
Т.о. на девайсе, который мы держим чуть дальше от глаз, текст как раз чуть более крупный. В целях улучшения UX можно отловить ширину и AspectRatio и задать индивидуальный размер, это всего 3-5 вариантов. Хотя можно отталкиваться и только от ширины устройства, мне кажется этого достаточно в 95% случаев. Делаем разметку чуток резиновой местами и она будет как влитая.
И да, я за размеры в px. Потому что любые относительные величины все равно пересчитаются движком в пиксели. Любые хаки, хуки и прочие хеки разве что ускорют написание условий типа media queries. Вот в примере задан размер html в пикселях. И у body тоже. Всё дочернее, как бы вы ни описывали, все равно пересчитается в пиксели. И, как видно, эти пиксели индивидуальны для устройств и браузеров. Так что разницы на продакшене нет. Совсем. Только удобство разработки. Хотя и это тоже относительно. Лучше я буду знать, что у меня строка высотой 28px, чем пересчитывать цепочку наследований. И пиксели всё-таки могут быть более понятными. Если я знаю что девайс 540 — 640 пикселей в высоту, я примерно представляю, сколько пикселей выделить тексту. А вот сколько rem? Или dp? Каждый раз для каждого девайса пересчитывать? Нет уж, пиксели гораздо роднее и теплее.
Производителям мониторов необходимо всегда через драйвера сообщать ОС свой физический размер для приблизительного определения расстояния от экрана.
Через какие еще драйвера? Это стандартная фича, отдается через EDID
Вот к примеру вывод EDID от моего монитора
[ 6.070] (II) intel(0): EDID for output HDMI2
[ 6.070] (II) intel(0): Manufacturer: BNQ Model: 7b26 Serial#: 21573
[ 6.070] (II) intel(0): Year: 2010 Week: 29
[ 6.070] (II) intel(0): EDID Version: 1.3
[ 6.070] (II) intel(0): Digital Display Input
[ 6.070] (II) intel(0): Max Image Size [cm]: horiz.: 53 vert.: 30
[ 6.070] (II) intel(0): Gamma: 2.20
[ 6.070] (II) intel(0): DPMS capabilities: Off
[ 6.070] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
[ 6.070] (II) intel(0): Default color space is primary color space
[ 6.070] (II) intel(0): First detailed timing is preferred mode
[ 6.070] (II) intel(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600
[ 6.070] (II) intel(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329
[ 6.070] (II) intel(0): Supported established timings:
[ 6.070] (II) intel(0): 640x480@60Hz
[ 6.070] (II) intel(0): 800x600@60Hz
[ 6.070] (II) intel(0): 1024x768@60Hz
[ 6.070] (II) intel(0): Manufacturer's mask: 0
[ 6.070] (II) intel(0): Supported standard timings:
[ 6.070] (II) intel(0): #0: hsize: 1024 vsize 576 refresh: 60 vid: 49249
[ 6.070] (II) intel(0): #1: hsize: 1280 vsize 800 refresh: 60 vid: 129
[ 6.070] (II) intel(0): #2: hsize: 1280 vsize 720 refresh: 60 vid: 49281
[ 6.070] (II) intel(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513
[ 6.070] (II) intel(0): #4: hsize: 1280 vsize 1024 refresh: 60 vid: 32897
[ 6.070] (II) intel(0): #5: hsize: 1600 vsize 900 refresh: 60 vid: 49321
[ 6.070] (II) intel(0): #6: hsize: 1680 vsize 1050 refresh: 60 vid: 179
[ 6.070] (II) intel(0): #7: hsize: 1920 vsize 1080 refresh: 60 vid: 49361
[ 6.070] (II) intel(0): Supported detailed timing:
[ 6.070] (II) intel(0): clock: 148.5 MHz Image Size: 531 x 298 mm
[ 6.070] (II) intel(0): h_active: 1920 h_sync: 2008 h_sync_end 2052 h_blank_end 2200 h_border: 0
[ 6.070] (II) intel(0): v_active: 1080 v_sync: 1084 v_sync_end 1089 v_blanking: 1125 v_border: 0
[ 6.070] (II) intel(0): Serial No: X7A00693SL0
[ 6.070] (II) intel(0): Ranges: V min: 50 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 175 MHz
[ 6.070] (II) intel(0): Monitor name: BenQ VW2420H
И физический размер есть и какое у него разрешение поддерживается. В тех же иксах давно интерфейс (DP) рисуется относительно DPI монитора. В windows 7 и далее тоже это все крутится. Но проблема в том что фактически многие старые программы в windows прибиты гвоздями к стандартному DPI. С новыми программами таких проблем уже нет.
Спасибо за EDID. Однако, должен заметить что а) в вебе к этой информации доступа нет и б) виндовый DPI-scaling в основном предназначен для того чтобы решить проблему увеличения ppi монитора тогда как угловые размеры элементов заметно отличаются.
Sign up to leave a comment.
О размере экрана, пикселя и элемента