При использовании свойства CSS zoom, как я могу убедить браузер использовать "ближайший сосед" вместо "билинейный" или любые другие более продвинутые алгоритмы масштабирования?
Моя установка - это div, который содержит холст, и div использует масштабирование с помощью JavaScript равным <div style="zoom:3200%">...</div>, и для получения ближайшего соседа я использую image-rendering: -webkit-optimize-contrast в своем CSS. Приложение доступно здесь ('z' увеличивает масштаб, 'shift-z' уменьшает обратно), и мой css равен здесь
Вот требуемый эффект в Chrome для OSX (для увеличения установлено значение 3200%):
Но в Chrome на Windows 7 происходит то же самое:
В обоих случаях это «ванильный» Chrome (версия 15.x.x) из коробки, никакие экспериментальные флаги не включены.
Как убедить Chrome в Windows использовать ближайшего соседа? Кстати, как я могу убедить все браузеры? Safari также не использует ближайшего соседа (пока приложение работает только в браузерах на основе WebKit)
Свойство CSS image-rendering влияет на Chrome / OSX и дает мне желаемый эффект. Но Chrome / Windows и Safari (5.1) / OSX, похоже, полностью игнорируют это. Что-то подсказывает мне, что мне просто не повезло, но я решил спросить.
Использование zoom в контейнере div очень просто и прекрасно работает в Chrome / OSX, если я должен прибегнуть к внутреннему масштабированию своих полотен, я тоже могу это сделать. Но предпочел бы буквально одну строку кода, если это возможно!
ОБНОВЛЕНИЕ: Я нашел использование image-rendering: optimizeSpeed подсказок. Однако это кажется привередливым в Chrome / Windows. Если я установлю слишком много элементов (я изначально пробовал, мои контейнеры и все холсты), это не вступит в силу. Но если я применю это только к canvas, я получу 98% пути.
Теперь моя проблема - это первый раз, когда я рисую при увеличении, он работает отлично, все остальные последующие действия рисования нечеткие, пока они происходят, а затем возвращаются к правильному ближайшему соседу (мое приложение рисует на холсте с нуля). сначала наносит рисунок на настоящий холст). Есть что-то странное в холсте, где Chrome настаивает на использовании билинейного. Я думаю, что с некоторым копанием я могу решить это.
UPDATE2: Кажется, что image-rendering в Chrome / Windows просто не реализован должным образом и немного глючит. Теперь я могу подтвердить, что значения optimizeSpeed и optimizeQuality не поддерживаются в Chrome / Windows. Если вы установите для них рендеринг изображений, Chrome проигнорирует этот набор. Chrome / Windows распознает -webkit-optimize-contrast, но не использует его последовательно. Chrome будет переключаться между алгоритмом билинейного масштабирования и ближайшим соседом почти случайно. Я не смог последовательно заставить Chrome использовать ближайшего соседа.
Я попытался собрать Chromium 17 на Windows, и он ведет себя так же.
Firefox (8.0.1) выглядит довольно многообещающе, хотя, похоже, он довольно хорошо соблюдает -moz-crisp-edges. Изначально я выбрал Chrome как «идеальный браузер» для этого приложения, я мог бы просто переключиться на Firefox.
В конце концов, похоже, что правильная поддержка image-rendering находится в стадии разработки для Chrome, но пока еще не совсем. Сам WebKit утверждает, что полностью поддерживает все значения рендеринга изображений, но я предполагаю, что сборка WebKit, которую использует Chrome, не совсем обновлена до этого нового исправления.