Пол-пикселя?

[@ekapinos]

Жесточайший батхерт можно получить при рисовании на Canvas. Необходимо указывать сдвиг в пол пикселя для получения прямой толщиной в пиксель (подробнее на stackoverflow).

Тема еще не раскрыта, но Ваш пост на верном пути!

[@SerDIDG]

Да зачем далеко ходить, при обычном transition opacity двигается на пиксель )

[@bertmsk]

Можно и еще ближе взять — при обычном hover-е на каком-нибудь элементе вся страница в хроме на полпикселя сдвигается.

[@SerDIDG]

Я про хром даже молчу, там всё живёт своей жизнью.

[@Keyten]

Помнится, я для этого извращался со scale.

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

[@hmage]

Такое же в Direct3D.

[@kashey]

Полпикселя, а то и меньше — отличное решение для анти-алисинга или даже «antry-grain». Так что рекомендую курить немного www.antigrain.com/ до наступления эффекта.

[@x256]

Ещё такой нюанс, вот в iPhone 6+ идёт даунсэмплинг из 2208*1242 в 1920*1080, то есть там вообще, как я понимаю, нельзя сделать рендеринг пиксель-в-пиксель никак?

Глянул на симуляторе, действительно, при viewport "width=device-width" края чёткие, CSS не знает про даунсэмплинг. На девайсе будет «размыто».

Кстати, только сейчас увидел, что (при других viewport) Safari на iOS ведёт себя как «идеальный браузер на неидеальном мониторе». Интересно, как обстоят дела в Android.

[@x256]

Не на чем попробовать. Надеюсь, кто-нибудь отпишет.

Я тоже вижу пиксели на 4S, а у 6+ размер пикселя уменьшился всего в 1.5 раза, поэтому downsampling также беспокоит (в теории).

[@Vavius]

Если приглядываться — то видно (особенно на специальных картинках потипу чередующихся черно-белых полос). Видео и игры могут рендериться без даунсемплинга, но когда на экране появляются UI-элементы, то даунсемплинг опять включается.

При повседневном использовании не заметно, но зная о такой фигне всегда подсознательно будешь искать артефакты (и само собой, иногда находить).

Тут подробнее: www.idownloadblog.com/2014/11/20/iphone-6-downsampling-explained/

[@x256]

Я вот как-то не вижу смысла в создании костылей под все возможные варианты.

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

[@x256]

Это была просто агитация за HiDPI мониторы :)

Когда брал ноут с 200+ DPI, большая часть сайтов смотрелись ужасно. Спустя 2 года ситуация получше, но тоже, 99% растровой графики (включая даже хабр частично) до сих пор не адаптированы под high-res.

Будут сайты красиво смотреться — будет стимул у людей покупать нормальные дисплеи и не портить глаза (последнее субъективно).

[@bigfatbrowncat]

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

«Кат» был придуман для того, чтобы не грузить канал юзера лишними данными без его явного согласия. Но даже заголовочная картинка может быть великовата. Да, часто это лечится использованием SVG (которое я лично, например, люто поддерживаю). Но не всегда, увы.

[@kemko]

nnovgorod.rt.ru/homeinternet — сплошные безлимиты
nn.domru.ru/internet — сплошные безлимиты
www.nnov.mts.ru/dom/home_inet/tariffs/nnov/ — аналогично
nn.megafon.ru/internet/options/ — трафика больше, чем дают в подмосковье.

Такое ощущение, что условия у вас всё-таки не совсем обычные.

[@batyrmastyr]

Думаю, речь шла про мобильный интернет рублей так за 200-400.

[@bigfatbrowncat]

Совершенно верно думаете. Дома у меня 10 мегабит.

[@PaulMaly]

Мы с вами видимо в разных Н.Новгородах живём…

[@Sava]

Хорошо, я живу в Омске. У меня гиг на телефоне, три на смарте и пять на свистульке, с которой раздается Wi-Fi на три стационара и планшет дочки, плюс гостевые компы клиентов. Я просто вынужден основной серфинг вести с браузеров с отключенными картинками и подгружать их при необходимости вручную. А проводное подключение ко мне в частный дом обойдется на данный момент порядка 15 тысяч и около тысячи в месяц за 8 Мбит. При этом я живу в ж таком месте, где даже 3G зависит от погоды, новосибирские инженеры Пчелайна удивились, что оно у меня вообще бывает. А в километре в сторону все работает. Мне нет смысла брать безлимитные тарифы, поскольку у жены в квартире есть нормальная проводная связь, все тяжелое я качаю там. И поверьте, что подобных мне в стране миллионы.

[@PaulMaly]

Так, а кто спорит? Я вообще только на НН стриггерил, потому что у нас с оптикой тьфу-тьфу все норм, да и по городу много где LTE есть.

Насчёт частных домов — тестю н живущему в частном доме в одном из городов Нижегородской области недавно предложили провести оптику на всю улицу по 8К на дом, далее по обычным тарифам. И это даже не Нижний Новгород.

Не утверждаю, что по стране у нас все ок, но в крупных региональных центрах уж точно.

[@Sava]

Примерно одинаковые по населению и развитию города: Омск и Нижний, но достаточно разные и условия, и тарифы. А есть места, где и наши условия кажутся чуть ли не раем. Оптику у нас предлагают пока в очень немногих точках, да и качество связи в реальности не слишком высокое.

[@bachin]

Половина черно-белого пикселя кодируется половиной бита!

[@lostpassword]

Простите, а Вы имеете в виду экранные биты или CSS-биты?

[@bachin]

Ну это откуда посмотреть. Когда мы печатаем текст CSS- то получаем CSS-биты. А когда этот CSS рендерится браузером — то из половины CSS-бита полуается половина экранного бита. Есть еще, кстати, клавиатурные половины бита — это если клавишу нажать на половину её хода. Можно даже программы писать полубитами. В одном полубайте восемь полубитов.

[@Milfgard]

И контрольная половинка. У меня всегда сходится.

[@EvilPartisan]

Вы наверное имеете ввиду кубиты?

[@bigfatbrowncat]

Шутите… а знаете, какой самый компактный формат сжатия для ч/б сканов? Мой товарищ в институте экспериментально выявил, что самое компактное — сжимать 1-битный bmp RAR-ом (сейчас, возможно, 7-zip лучше). Этот метод не дает выводить полутона, но для текста это обычно не надо.

[@DolphinSoft]

Ваш товарищ еще больше удивился бы, если перед RAR-ом применил RLE (желательно эвристический).
Насколько помню, это давало степень сжатия выше JPG, без потери избыточности (в цвете).

[@alan008]

Если без шуток, то самый компактный формат сжатия черно-белых сканов, это TIFF со сжатием CCITT Group 4 (Fax 4)

[@FireStorm]

Так DjVu же…

[@v_joker]

Битых 2 часа читал вашу статью, так и и не понял в чем вопрос)

здесь www.w3.org/Style/Examples/007/units.en.html написано что требование к пикселю быть размером 1\96 дюйма относится ко всей печатной продукции, ни про какакие мониторы речи нету.

здесь msdn.microsoft.com/ru-ru/library/ms537660.aspx написано что размер пикселя зависит от устройства, что совпадает с данными из первой ссылки.Здравый разум тоже подсказывает пиксель в CSS всегда был и есть пикселем на устройстве.Его размер зависит от размера и характеристик устройства и включенного графического режима.

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

[@x256]

здесь www.w3.org/Style/Examples/007/units.en.html написано что требование к пикселю быть размером 1\96 дюйма относится ко всей печатной продукции, ни про какакие мониторы речи нету.

Почему я сразу сослался на терминологию Гугла? В ней всё понятно: есть px (CSS pixel), есть dip, они связаны, это разные вещи.

W3C сами запутались, подменяя одно понятие другим. В одном месте стандарта заявляют, что px является absolute length unit и равен

1px is equal to 1/96th of 1in

— никаких исключений про мониторы тут не вижу.

Но далее по тексту, 1px вдруг начинают рассматривать уже в контексте reference pixel, т.е. device-independent:

For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch).

Ну а про это я писал в статье, но возражу ещё раз:

Тоесть пиксель на устройстве это всегда пиксель CSS.

У меня пиксель на устройстве (iPhone 4S) равен 0,08 мм.
Но CSS (при viewport "width=device-width") рисует 1px толщиной в 0,16 мм.

[@a553]

device-width считается в CSS пикселях. Описанное вами поведение верное.

[@x256]

del

[@the_ghost]

Так что же выбрать? px или em?

[@x256]

Общие советы давать трудно. :) У меня есть один проект для iOS на WebKit. Когда адаптировал под iPhone 6 и 6+, самым простым решением оказалось переделать абсолютно все размеры на em, кроме собственного одного (font size), который задаётся в runtime.

[@danilf]

rem

[@iSodeska]

Не удержался

[@Sketch_Turner]

А еще пол пикселя есть в Photoshop. И они прекрасно укладываются в головах дизайнеров и фотографов))

[@ncix]

В одном бите тысяча миллибит.

[@FishDude]

1024, если точнее.

[@bakhirev]

Вывод:

• верстать резиной;
• для ограничений использовать EM;
• убивать магию DPI-багов специальным мета-тегом:
  

  <meta name="viewport" 
      content="width=device-width, height=device-height,
      initial-scale=1.0, user-scalable=no, maximum-scale=1.0"/>
  

  
  

спойлер

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

[@dtestyk]

практические выводы из этой статьи

когда появится поддержка

mediaSource: 'screen'

во всех браузерах,

спойлер

будет еще один isIE флаг

[@Imposeren]

половина экранного пикселя — не бывает.

стоит уточнить, что если известен порядок субпикселей, то вполне бывает 1/3 и 2/3 экранного пикселя. Для некоторых дисплеев также бывает и 1/4 экранного пикселя.