Аппаратное ускорение в браузерах


Одной из характеристик, по который браузеры сравнивались в прошлом обзоре, была скорость работы с графикой. Тогда это был всего лишь один показатель среди прочих, сегодня же ему будет уделено основное внимание, и вот почему. Контент веб-страниц постепенно становится сложнее и насыщеннее. С одной стороны, этому способствует развитие и продвижение HTML5, который напрямую поддерживает видео (<video>) и графику (<canvas>), а с другой — постепенное наступление облачных вычислений.

Хорошим примером является Chrome OS — работать в ней можно только с веб-приложениями, которые в идеале должны заменить все привычные нам программы. При этом должна быть обеспечена и возможность их локальной работы, для чего большая часть функциональности реализуется непосредственно в браузере (в противном случае ее можно было бы переложить на серверную сторону, что сняло бы часть проблем). Среди таких приложений если не сегодня, то завтра, очевидно, появятся и достаточно сложные игры (казуальные уже прочно укрепились в вебе), и фоторедакторы, и другие графические программы. Естественно, чтобы завоевать признание пользователей, они должны работать сравнимо с обычным ПО, в том числе и в вопросах производительности — обратное поставит под сомнение саму идею облачных вычислений, что, похоже, сегодня уже никого не устраивает. Именно для этой цели совершенствуются JavaScript-машины и, что особенно важно в контексте данной статьи, обеспечивается аппаратное ускорение вывода графики.

К тому же, браузер становится системообразующим компонентом, и не только в Chrome OS: его роль, к примеру, расширяется и в более традиционной Windows. Так, новый интерфейс Metro в Windows 8 визуализируется именно ядром Internet Explorer 10, и потому аппаратное ускорение в этом браузере играет особенно важную роль. При этом Metro-вариант Internet Explorer 10 не поддерживает никаких плагинов, включая Adobe Flash и Microsoft Silverlight, и соответственно, использующие графику и анимацию приложения для него должны создаваться исключительно средствами HTML5.

Постепенно снижающееся значение Adobe Flash-плеера — еще одна современная тенденция. До недавнего времени стандарт де-факто для анимационных интерактивных веб-приложений, сегодня он постепенно вытесняется из этой сферы, хотя, по оценкам самой Adobe, по крайней мере 70% онлайновых игр реализуется именно на Flash. Однако и Apple, и теперь Microsoft подают однозначные сигналы. Google, вроде бы, более лояльна, раз включила поддержку Flash в Chrome OS, однако именно Google (а даже не сам пользователь) контролирует обновление плеера, и компания в любой момент может пойти на попятную, т. к. очевидным приоритетом все же является HTML5. Тем не менее Adobe продолжает развитие своих технологий, и Flash Player 11 также обещает повысить эффективность вывода графики. Поэтому, хотя в контексте статьи основной интерес представляют именно браузеры, они будут, где это возможно, сравниваться с Flash. Тем более, что было бы полезно не только сопоставить между собой сами браузеры, но и понять, насколько серьезное оборудование уже в ближайшем будущем потребуется для комфортной работы с вебом.

Итак, под аппаратным ускорением понимается переложение части операций с центрального процессора на GPU, который, в отличие от x86 CPU, адаптирован для специфических вычислений — кстати, не только для обработки графики, но и, скажем, для криптографии. Впрочем, лучше всего эффект от использования GPU известен на примере компьютерных 3D-игр: сегодня уже невозможно представить, чтобы в них использовался программный рендеринг. Веб-приложениям, конечно, еще долго выходить на подобный уровень, но уже сейчас аппаратное ускорение в браузерах может касаться сразу нескольких аспектов:

  • воспроизведения видео;
  • рендеринга страниц, использующих <canvas>, CSS3 и пр.;
  • 3D-графики, создаваемой с помощью WebGL.

Браузеры: текущее состояние

Если обращать внимание на номера версий, то за время, прошедшее с момента прошлого теста, два из пяти ведущих браузеров продемонстрировали завидный прогресс. На самом деле, такое частое обновление версий отражает, скорее, особенности процесса разработки, чем уровень реальных усовершенствований, однако изменения есть, и они заметны. Особенно у Chrome, который существенно расширил свою функциональность — к примеру, стал поддерживать исполнение машинного кода (Native Client). В интересующем нас контексте в браузере Google было реализовано графическое ускорение <canvas> и 3D CSS, ряд экспериментальных функций перекочевали в базовые, так что теперь этот браузер — в одном ряду с Firefox и Internet Explorer. Разработчики Firefox также уделяли внимание совершенствованию (в основном, экстенсивному) производительности. Ну а оптимизацией JavaScript-машин озабочены все — правда, Microsoft это делает уже в контексте будущего Internet Explorer 10. Поскольку JavaScript играет заметную роль в работе с графикой, предварительно имеет смысл обновить результаты прошлых тестов (на том же оборудовании):

Табл. Производительность браузеров в JavaScript

БраузерSunSpider 0.9.1, мс
(меньше — лучше)
V8 Benchmark (v6)
(больше — лучше)
Kraken v1.1, мс
(меньше — лучше)
Futuremark Peacekeeper
(больше — лучше)
Chrome 14.0.835.186508458083354857
Firefox 6.0.24922208115842671
IE 9.024201425250052620
Opera 11.515362065260644522
Safari 5.15861638345683584

Прогресс Chrome особенно заметен: в частности, теперь именно он лидирует во Futuremark Peacekeeper, слегка опередив Opera. Этот тест стои́т несколько особняком от прочих, так как учитывает и работу с графикой в <canvas>, и рендеринг «типичных» элементов веб-страниц. Если признать, что он отражает текущее состояние веба, то понятно, почему Opera воспринимается как «быстрый браузер» — жаль только, что его разработчики не слишком реагируют на современные тенденции.

Оборудование

Тесты проводились в следующей конфигурации:

  • CPU Pentium D 3 ГГц;
  • 3 ГБ памяти;
  • референсные видеокарты AMD Radeon HD 6450, 6670, 6790;
  • монитор с разрешением 1680×1050;
  • ОС Windows 7 Ultimate SP1 x32;
  • Catalyst Software Suite 11.8.

Выбор видеокарт сделан с целью покрыть нижнюю часть ценового диапазона, поскольку ясно, что топовые модели для веба понадобятся еще нескоро. Кроме того, идея состояла в том, чтобы попытаться оценить масштабируемость графической производительности браузеров, а в рамках одного семейства GPU это должно быть особенно наглядно.

Видео

Воспроизведение видео непосредственно средствами браузера стало возможным благодаря появлению в HTML5 тега <video>. В нем можно описывать различные доступные форматы, а уж браузер выберет тот, который ему больше подходит. На самом же деле реальных претендентов на широкое распространение в вебе всего два: H.264/MPEG-4 AVC и VP8/WebM. Первый поддерживается исторически, в том числе в Adobe Flash, и сегодня его главными сторонниками являются Microsoft и Apple. Второй продвигается усилиями Google, которая в свое время приобрела разработчика этого формата, а кроме того, поскольку VP8 не требует лицензионных отчислений (хотя пока они и за H.264 не взимаются), на его стороне также Mozilla и Opera. Впрочем, Microsoft предлагает плагины H.264 для Chrome и для Firefox на Windows 7, а Google — WebM-плагин для Internet Explorer 9 и для Safari на Mac OS X. Проверить поддержку этих форматов можно, к примеру, на специальной странице сайта Microsoft.

Очевидно, что в данном случае соревнуются не столько браузеры, сколько кодеки. Сравнение их с точки зрения качества изображения — отдельный вопрос. Хотя некоторое преимущество H.264 зафиксировано в Wikipedia, при прочих равных большинство пользователей вряд ли увидят разницу в картинке. С производительностью проще — за свою более длинную историю H.264 сумел приобрести дивиденды в виде оптимизации декодирования с помощью GPU фактически всех распространенных марок; сегодня этот бонус автоматически достается большинству пользователей. VP8 пока таким похвастать не может, его декодирование все еще в значительной степени возлагается на CPU, со всеми вытекающими последствиями. Соответственно, главный критерий нашей оценки — именно загрузка CPU.

Для теста воспроизведения видео использовался ролик Wonders of the Solar System — Trailer, доступный в различных разрешениях и форматах. С недавних пор YouTube стал не только поддерживать раздачу видео в HTML5, но и активно кодировать его в WebM (традиционно для этого использовались форматы Flash Video и MPEG-4). Режим этот, впрочем, пока тестовый, с рядом ограничений — в частности, ролики со встроенной рекламой по-прежнему воспроизводятся только через Flash-плеер. Включать режим нужно на особой странице, где заодно будет видна и информация о текущей поддержке форматов. Искать WebM-видео на YouTube можно с помощью расширенных настроек поиска, либо добавляя к URL страницы с результатами поиска параметр &webm=1. Хотя при наличии роликов в обоих форматах все браузеры неизменно выбирают «родной» для них, и повлиять на это поведение невозможно. Естественно, при тестировании канал был достаточно широк, чтобы не накладывать никаких дополнительных ограничений.

Табл. Средняя загрузка CPU при воспроизведении видео (оконный/полноэкранный режимы, %). Видеокарта Radeon HD 6790.

БраузерФормат360p720p1080p
Chrome 14.0.835.186WebM19,0/20,543,7/48,669,3/69,9
Firefox 6.0.2WebM26,0/19,844,6/38,5н/д
IE 9.02 (HTML 5)MPEG-419,2/13,919,8/16,522,1/18,4
IE 9.02 (Flash 11.0.1.129 RC)MPEG-49,5/9,518,6/9,929,9/9,9
Opera 11.51WebM29,6/65,470,7/83,5н/д
Safari 5.1 (QuickTime 7.7)MPEG-415,2/15,449,5/53,887,5/89,7

Табл. Средняя загрузка CPU при воспроизведении видео (оконный/полноэкранный режимы, %). Видеокарта Radeon HD 6450.

БраузерФормат360p720p1080p
Chrome 14.0.835.186WebM22,2/21,543,7/48,769,5/70,0
Firefox 6.0.2WebM23,5/21,344,5/41,5н/д
IE 9.02 (HTML 5)MPEG-420,7/14,122,3/18,723,9/19,9
IE 9.02 (Flash 11.0.1.129 RC)MPEG-410,5/10,020,6/10,131,3/9,9
Opera 11.51WebM31,9/67,074,0/84,1н/д
Safari 5.1 (QuickTime 7.7)MPEG-415,8/16,051,3/55,589,2/90,1

Цифры, в общем-то, говорят сами за себя и подтверждают вышесказанное. Поддержке HTML5-видео еще есть куда развиваться, так как лучшие результаты по-прежнему демонстрирует Flash-плеер, хотя можно сделать вывод, что декодер Adobe лучше оптимизирован именно для небольших разрешений, тогда как Microsoft больше внимания уделила HD. Firefox и Opera даже не предлагают воспроизводить HD 1080p, хотя Firefox выглядит лучше Chrome, и оба, судя по всему, начали оптимизировать свои WebM-декодеры (Google объявляла об этом еще в Chrome 10). У Opera на 720p и Safari на 1080p загрузка центрального процессора периодически зашкаливала, и соответственно, они пропускали кадры. Вероятно, Safari/QuickTime лучше функционирует в Mac OS X, а декодер Apple для Windows, очевидно, не оптимизирован. Масштабирования аппаратного ускорения в зависимости от используемой видеокарты практически не наблюдается, поэтому третья модель видеокарты даже не тестировалась.

HTML

Условно отображение веб-страниц можно разбить на три основных этапа:

  • рендеринг отдельных элементов;
  • компоновка страницы;
  • вывод на экран.

Все три могут полностью или частично обслуживаться GPU. На первом, к примеру, обрабатываются элементы <canvas> и SVG, на втором применяются преобразования 3D CSS и т. д. В свое время Microsoft первой объявила о реализации «полного» аппаратного ускорения вывода веб-страниц в Internet Explorer 9. Учитывая, что ее браузер работает только в Windows Vista/7, это, видимо, было сравнительно просто: Direct2D и DirectWrite для рендеринга, Direct3D для компоновки и вывод стандартными средствами ОС, т. е. также через DirectX. На самом деле остальные «ускоренные» браузеры обеспечивают примерно всё то же самое, с той лишь разницей, что вынуждены использовать средства и API, доступные на каждой конкретной платформе. К примеру, в Windows XP нет Direct2D, чем Microsoft и аргументировала отсутствие для нее Internet Explorer 9. Остальные разработчики решили превратить это в свое конкурентное преимущество, т. к. половина пользователей и до сих пор не перешла на более новые версии Windows. Соответственно, архитектура аппаратного ускорения в Chrome и Firefox сложнее, чем в Internet Explorer 9:

Табл. Реализация аппаратного ускорения в Firefox на различных платформах.

ОперацияLinuxWindows XPWindows Vista/7Mac OS X
Рендеринг контентаXRenderнетDirect2DQuartz (CPU)
Компоновка страницыOpenGLDirect3DDirect3DOpenGL

Таким образом, Firefox в Windows Vista/7 обеспечивает не менее полное ускорение. Chrome может использовать Direct2D для рендеринга отдельных элементов, в частности <canvas>, но, к примеру, не для текста. Хотя, учитывая темпы обновления браузера Google, все может поменяться уже к моменту публикации статьи. Safari поддерживает аппаратное ускорение только в Mac OS X (справедливости ради, отметим, что Chrome и Firefox, в свою очередь, пока особо не блещут на платформе Apple), а Opera, кажется, вообще не уделяет внимания данному аспекту.

В реальности поддержка аппаратного ускорения также зависит от используемой видеокарты и драйверов (которые в любом случае стоит обновить). Проверить состояние дел можно несколькими способами. В Internet Explorer 9 и Firefox имеются соответствующие параметры в окнах настроек. В Firefox можно получить и более подробную информацию в разделе Graphics страницы about:support:

Раздел Graphics страницы about:support:
Рис. 1. Раздел Graphics страницы about:support

В Chrome похожая информация отображается на странице about:gpu-internals:

Chrome, страница about:gpu-internals:
Рис. 2. Chrome, страница about:gpu-internals:

Если что-то здесь будет вызывать ваши сомнения, попробуйте заглянуть в about:flags и включить опции, имеющие отношение к работе с графикой и GPU (имейте в виду, что соответствующие функции относятся к экспериментальным и могут работать нестабильно). В текущей версии Chrome 14 доступна только GPU Accelerated Canvas 2D, в предыдущих были и другие настройки, которые постепенно перекочевали в разряд штатных возможностей.

Chrome страница about:flags
Рис. 3. Chrome страница about:flags

Итак, перейдем к тестам. Для начала несколько тестов, созданных разработчиками браузеров. Кстати, как видно, они вовсе не обязательно отдают предпочтение «своим» браузерам.

Табл. Результаты ряда тестов не зависят от используемой видеокарты

БраузерMozilla Hardware Acceleration Stress Test, fpsMicrosoft FishIE Tank, fps (20/500 рыбок)Microsoft Psychedelic Browsing (больше — лучше)
Chrome 14.0.835.1866060/346048
Firefox 6.0.26060/447541
IE 9.026060/401815
Opera 11.511320/23
Safari 5.1616/22

Первые два из этих тестов проводились и в прошлый раз, динамика развития Chrome хорошо заметна. Здесь и далее ограничение в 60 fps искусственное, связанное с тем, что именно такова наиболее распространенная частота обновления экрана мониторов — а следовательно, превышение ее может вызывать разве что академический интерес, поскольку пользователь дополнительных кадров просто не увидит. Приведенные результаты получены с видеокартой HD 6790 и оставались такими же (в пределах статистической погрешности) при использовании других видеокарт, за одним исключением: Firefox в Psychedelic Browsing показал 6440 и 2217 баллов для HD 6670 и HD 6450 соответственно (при этом не воспроизводился звук). Вероятно, это связано с какими-то особенностями реализации отдельных функций. Для Chrome в Psychedelic Browsing решающее значение имела упомянутая выше опция GPU Accelerated Canvas 2D — с ее отключением результат опускался до значения 4. Вот наглядная демонстрация преимуществ аппаратного ускорения, отсутствие которого невозможно компенсировать оптимизацией других механизмов браузера.

Следующий тест также по сути своей относится к предыдущей группе, но в нем уже заметно некоторое масштабирование в зависимости от видеокарты.

Табл. Microsoft FishBowl, fps (10/250 рыбок)

БраузерHD 6790HD 6670HD 6450
Chrome 14.0.835.18660/3560/3560/34
Firefox 6.0.260/1960/338/3
IE 9.0260/6060/6060/22
Opera 11.512/12/12/1
Safari 5.12/02/02/0

В Firefox и Opera, как и раньше, вода красная.

Два следующих теста независимых разработчиков имитируют игровой контекст, причем первый разработан специалистами Facebook. Естественно, ни о какой 3D-графике здесь речь не идет, используются обычные «плоские» спрайты.

Табл. Независимые «игровые» тесты

БраузерJSGameBench (больше — лучше)Asteroids, баллы/fps
Chrome 14.0.835.1867961123/24
Firefox 6.0.2923434/10
IE 9.027001080/23
Opera 11.5143755/16
Safari 5.11141046/22

Здесь также масштабирование наблюдалось только у FireFox — в JSGameBench его показатели были 910 и 777 на HD 6670 и HD 6450 соответственно. Результаты в Asteroids выглядят очень интересно — хотя в этом тесте и применяется <canvas>, аппаратное ускорение не имеет решающего значения. Вероятно, здесь сказываются ограничения в каких-то более традиционных частях движка, неплохо реализованных в Opera и Safari. Для сравнения, Chrome с отключенным 2D-ускорением <canvas> показал 1043/22.

Как уже говорилось, все идет к тому, что Adobe Flash будет постепенно вытесняться из веба. Соответственно, возникает вопрос: насколько оправдана эта тенденция, учитывая предысторию, распространенность и достаточную отлаженность технологии Adobe? Следующий тест, конечно, не может претендовать на полноту, но тем не менее демонстрирует, что по производительности конкурировать с Flash непросто.

Табл. Сравнение различных механизмов анимации, fps

БраузерHTMLCanvasSVGFlash
Chrome 14.0.835.18621301844
Firefox 6.0.2938244
IE 9.0216342550
Opera 11.5129281250
Safari 5.123315150

Internet Explorer и Opera в HTML-тесте рисуют частички квадратными. Результат Chrome указан с отключенным 2D-ускорением <canvas>: с использованием этой настройки частота кадров опускалась до 12-13 fps. Видно также, что в наиболее простых случаях отсутствие аппаратной акселерации можно компенсировать программной оптимизацией; не наблюдалось и масштабирования производительности.

Впрочем, в следующем тесте картина для Flash уже не столь однозначна: реализация растровой графики средствами HTML5 оказывается значительно более быстрой:

Табл. GUIMark 2, fps

БраузерVector, HTML5Vector, FlashBitmap, HTML5Bitmap, Flash
Chrome 14.0.835.1869183714
Firefox 6.0.211174814
IE 9.0210204716
Opera 11.511619915
Safari 5.12191215

Здесь хорошо заметно, что для HTML5 принципиальную роль играет аппаратное ускорение, хотя Opera отлично справилась с векторным тестом. Результаты Chrome с отключенным 2D-ускорением <canvas> были значительно ниже. Однако нагрузка на GPU явно не слишком высока, и результаты совпадают на всех видеокартах.

Наконец, последний HTML5-тест — один из немногих, построенных на основе реального веб-приложения (архив-магазин записей радиостанции). Он комплексный, задействует различные механизмы, в том числе <video> и <canvas>, в процессе его исполнения заметно, как сильно «плавает» fps в зависимости от ситуации/задачи.

Табл. WebVizBench (баллы/fps)

БраузерБаллы/fps
Chrome 14.0.835.1862800/5
Firefox 6.0.23050/3
IE 9.023970/14
Opera 11.512740/3,5
Safari 5.12650/2

Хороший пример того, насколько «тяжелыми» для браузеров могут быть HTML5-приложения. Результаты не зависели он используемой видеокарты, за исключением Internet Explorer, показавшего 3600/11 на HD 6450. Впрочем, надо иметь в виду, что данный сайт/тест разрабатывался именно с прицелом на браузер Microsoft.

WebGL

В данном контексте не вполне корректно говорить об аппаратном ускорении, поскольку WebGL представляет собой JavaScript API для отображения 3D-графики в <canvas>. Но он основан на OpenGL и потому в большинстве случаев будет действительно исполняться на GPU. На сегодняшний день WebGL поддерживают Chrome и Firefox, а также Safari на платформе Mac OS X. В стабильной версии Opera поддержки нет, хотя она присутствовала в специальных тестовых сборках. Microsoft выступает против WebGL, аргументируя свою позицию соображениями безопасности: к качеству видеодрайверов имеются определенные претензии, а WebGL позволяет веб-приложениям напрямую взаимодействовать с ними, что может быть использовано для взлома системы. Впрочем, свято место пусто не бывает, и для Internet Explorer разрабатывается WebGL-плагин, хотя приложения для него, похоже, нужно корректировать (во всяком случае, пока ни один тест у нас корректно не запустился).

Табл. WebGL-реализация FishIE (2000/10000 рыбок, fps)

БраузерHD 6790HD 6670HD 6450
Chrome 14.0.835.18660/2860/2754/4
Firefox 6.0.260/2058/1841/4

Трудно сравнивать между собой реализации совершенно различных механизмов, но, видимо, благодаря тому, что WebGL находится «ближе» к железу, он способен существенно поднять производительность графики (обратите внимание на количество рыбок и сравните с HTML5-тестом). В силу этого, наверное, начинает проявляться и масштабирование.

Табл. Полноэкранные WebGL-варианты JSGameBench

БраузерHD 6790HD 6670HD 6450
Chrome 14.0.835.18639602080/1810380/440
Firefox 6.0.232301910410

Результаты Chrome отличаются в WebGL Demo и WebGL Demo 2 (приведены через косую черту). Здесь масштабирование также хорошо заметно, хотя на следующие тесты смена видеокарты влияния уже не оказывала.

Табл. Производительность в WebGL также не всегда масштабируется

БраузерKhronos Particles, fpsGoogle Aquarium (100/1000 рыб), fpsThoughts in Computation Particles, fps
Chrome 14.0.835.1866060/3728
Firefox 6.0.25940/1836

Резюме

Итак, насколько важно аппаратное ускорение в браузерах и должно ли оно волновать пользователя? Текущее состояние веба таково, что новые возможности HTML5 пока не слишком распространены. В пользу этого свидетельствует и неспешное развитие Opera и Safari. Однако ситуация будет меняться. В отношении перспектив HTML5 Google и Microsoft практически единодушны, а одно это уже говорит о многом.

Аппаратное ускорение реально необходимо для воспроизведения сравнительно качественного видео из веба. Судя по всему, именно с его отсутствием или недостаточной эффективностью связаны жалобы пользователей нет- и «хромбуков». Особо мощный GPU в данном случае не нужен, гораздо важнее качественная оптимизация декодера, которой пока очень не хватает для WebM.

C отображением веб-страниц ситуация менее однозначна. Неслучайно большинство тестов являются, по сути, демонстрационными приложениями: веб достаточно консервативен, создатели сайтов обычно стараются поддерживать все распространенные браузеры, а HTML5 пока даже не принят W3C. Однако новые возможности слишком заманчивы, и тройка ведущих браузеров делает их доступными для большинства пользователей. Соответственно, массового появления насыщенных сложным контентом сайтов можно ожидать уже в ближайшее время. В большинстве HTML-тестов аппаратное ускорение позволяет кардинально улучшить производительность, хотя реальная нагрузка на GPU, видимо, не слишком высока, раз не наблюдается масштабирования результатов при смене видеокарты на более мощную. Скажем, непонятно, как добиться большей частоты кадров в тесте WebVizBench.

Производительность WebGL масштабируется заметно лучше — судя по всему, данный API позволяет довольно эффективно задействовать GPU. Следовательно, появятся и по-настоящему тяжелые веб-приложения, работа которых будет существенно зависеть от видеокарты. Это, кстати, могут быть не только игры, хотя им уделяется внимание в первую очередь — вот, к примеру, Quake 2. Не менее перспективно выглядит и визуализация научных и инженерных расчетов. Если WebGL действительно сможет завоевать популярность, то значение GPU для веба существенно вырастет.

Еще один общий момент, на который стоит обратить внимание: аппаратное ускорение не только повышает производительность, но и снижает энергопотребление. Задачи, для которых не хватает даже 100% ресурсов CPU (к примеру, декодирование HD-видео), GPU нередко решает с минимальной нагрузкой, порядка нескольких процентов. Это, конечно, особенно важно для мобильных систем.

Ситуация же с самими браузерами достаточно ясна. Аппаратное ускорение дает последним версиям Chrome, Firefox и Internet Explorer ощутимое преимущество. На платформе Windows производительность этих браузеров существенно подровнялась, хотя у Chrome часть возможностей еще находится в экспериментальном состоянии. Дополнительными плюсами в пользу Chrome и Firefox являются их кроссплатформенность и поддержка WebGL, хотя не следует ожидать одинаковых результатов на всех платформах. Safari, по понятным причинам, в первую очередь развивается на Mac OS X, а вот позиция Opera откровенно разочаровывает, особенно если учесть популярность этого браузера в СНГ.

Дополнительно

Нашли ошибку на сайте? Выделите текст и нажмите Shift+Enter

Код для блога бета

Выделите HTML-код в поле, скопируйте его в буфер и вставьте в свой блог.