Использование ближайшего соседа с CSS для увеличения на холсте (и img)

При использовании свойства CSS zoom , как я могу убедить браузер использовать «ближайшего соседа» вместо «билинейного» или других более сложных алгоритмов масштабирования?

Моя настройка - это div который содержит холст, а масштаб div устанавливается с помощью JavaScript на

, а чтобы получить ближайшего соседа, я использую рендеринг изображений: -webkit-optimize-Contrast в моем CSS. Приложение доступно здесь ('z' увеличивает масштаб, 'shift-z' уменьшает масштаб), а мой CSS - здесь

Вот желаемый эффект в Chrome на OSX (масштаб установлен на 3200%):

Но то же самое в Chrome в Windows 7:

В обоих случаях это "ванильный" Chrome (версия 15.xx) из коробки никакие экспериментальные флаги не включены.

Как убедить Chrome в Windows использовать ближайшего соседа? В этом отношении, как я могу убедить все браузеры? Safari также не использует ближайшего соседа (пока приложение работает только в браузерах на основе WebKit)

Свойство CSS рендеринга изображений влияет на Chrome / OSX и дает желаемый эффект. Но Chrome / Windows и Safari (5.1) / OSX, похоже, полностью игнорируют его. Что-то мне подсказывает, что мне просто не повезло, но я подумал, что спрошу.

Использование zoom в контейнере div настолько просто и прекрасно работает в Chrome / OSX, что если мне придется прибегать к внутреннему масштабированию холстов, я тоже могу это сделать.Но предпочел бы буквально одну строчку кода, если это возможно!

ОБНОВЛЕНИЕ: Я обнаружил, что использование рендеринга изображений: optimizeSpeed ​​ помогает. Однако это кажется привередливым в Chrome / Windows. Если я установлю его на слишком большом количестве элементов (я сначала пробовал, мои контейнеры и все холсты), это не сработает. Но если я применю его только к холсту , я получу 98% пути.

Теперь моя проблема заключается в том, что я впервые рисую в увеличенном масштабе, он работает отлично, все другие последующие действия рисования нечеткие, пока они выполняются, а затем возвращаются к правильному ближайшему соседу (мое приложение рисует на пустом холсте сначала наносит рисунок на реальный холст). Есть что-то странное в скретч-холсте, где Chrome настаивает на использовании билинейности. Думаю, немного покопавшись, я смогу это решить.

ОБНОВЛЕНИЕ 2: Похоже, что рендеринг изображений в Chrome / Windows просто не реализован должным образом и немного глючит. Теперь я могу подтвердить, что значения optimizeSpeed ​​ и optimizeQuality не поддерживаются в Chrome / Windows. Если вы установите для них рендеринг изображений, Chrome проигнорирует этот набор. Chrome / Windows распознает -webkit-optimize-Contrast , однако не использует его постоянно. Chrome будет переключаться между алгоритмом билинейного масштабирования и алгоритмом ближайшего соседа почти случайным образом. Мне не удавалось постоянно заставлять Chrome использовать ближайшего соседа.

Я пробовал сборку Chromium 17 в Windows, и она ведет себя точно так же.

Firefox (8.0.1) выглядит довольно многообещающе, поскольку, похоже, неплохо соблюдает -moz-crisp-Edge . Изначально я ориентировался на Chrome как на «идеальный браузер» для этого приложения, я мог бы просто переключиться на Firefox.

В конце концов, похоже, что надлежащая поддержка рендеринга изображений находится в стадии разработки для Chrome, но еще не совсем готова. Сам WebKit утверждает, что полностью поддерживает все значения рендеринга изображений,но я предполагаю, что сборка WebKit, которую использует Chrome, не совсем обновилась до этого нового исправления.