Всего несколько часов назад корпорация Microsoft выпустила четвёртую и последнюю предварительную версию Platform Preview своего веб-браузера Internet Explorer 9. Internet Explorer 9 Platform Preview 4 включает в себя массу новых демонстраций и тестов технологии HTML5. Даже несмотря на то, что релиз полноценной бета-версии нового браузера ожидается уже в следующем месяце, софтверный гигант выпустил четвёртый Platform Preview, тем самым сдержав своё давнее обещание о том, что будет выпускать предварительные версии Internet Explorer 9 Platform Preview каждые 8 недель, или около того.
Основной целью для специалистов из Редмонда была и остаётся совместимость IE9 с новейшими стандартами, в частности – HTML5, и представители софтверной корпорации заявляют, что веб-страницы написанные с соблюдением всех современных стандартов будут работать правильно в новом браузере от Microsoft.
Как это можно было наблюдать со времени выхода первой версии Internet Explorer 9 Platform Preview, Microsoft существенно увеличила производительность нового браузера, как по сравнению со своими предшественниками, так и по сравнению с другими браузерами, поддерживающими стандарт HTML5, а всё благодаря тесной интеграции IE9 с аппаратной частью компьютера.
Помимо внедрения новых технологий, в IE9 была значительно улучшена совместимость со всеми существующими сейчас стандартами. Так сейчас, например, Internet Explorer 9 Platform Preview 4 проходит тест Acid3 с результатом 95 баллов из 100.
Эта пятёрка «проваленных» тестов относится к спецификациям SVG, которые в данное время находятся на стадии эволюционирования – это SVG шрифты, и анимация SVG SMIL.
Комиссия по технологии SVG сейчас рассматривает вопрос о том, чтобы сделать SVG шрифты опциональными, как в случае со шрифтами WOFF, которые финальная версия Internet Explorer 9 будет полностью поддерживать, так как они сейчас уверенно наращивают темп, и возможно станут общепризнанным стандартом в ближайшее время. В ситуации, когда будет осуществляться широкая поддержка технологии WOFF, SVG шрифты становятся просто ненужными. Проект Mozilla сейчас придерживается точно такого же мнения.
Увеличить рисунок
Ситуация с анимацией SVG SMIL является аналогичной. Сейчас анимационные технологии SMIL и CSS3, по сути, дублируют одна другую, и комиссия по технологии SVG считает, что будет лучше, если специалисты из Редмонда не будут реализовывать этот стандарт, так как этот шаг может увековечить технологию, которая в скором времени уже устареет.
Новейшая версия Internet Explorer 9 Platform Preview 4 включает в себя также и архитектурные изменения. Ранее движок JavaScript в Internet Explorer был автономным компонентом.
С появлением IE9 Platform Preview 4 движок JavaScript был интегрирован в ядро браузера.
В Microsoft заявляют, что такой шаг позволит добиться значительного повышения производительности при выполнении запросов JavaScript, в сравнении с автономностью движка.
С релизом Internet Explorer 9 корпорация Microsoft привела движок своего браузера в совместимость со всеми стандартами, и теперь, в некоторых сферах он значительно превосходит технологии главных конкурентов.
Предварительная версия (Platform Preview) позволила разработчикам получить доступ к новым технологиям будущего веб-браузера: разработчики смогли оценить быстродействие, поддержку технологии SVG, а также поддержку интегрированного видео; 2,5 миллиона загрузок демонстрируют значительный интерес общественности к процессу разработки будущего веб-браузера.
Теперь главной задачей Microsoft является скорый выпуск финальной версии Internet Explorer 9, так как ничто не стоит на месте, и то, что сейчас является новейшей технологией или стандартом завтра уже устареет.
Надеемся, что вскоре мы сможем увидеть публичную бета-версию, и следующую за ней финальную версию браузера IE9, а пока можно посмотреть демонстрацию новых технологий, загрузив Internet Explorer 9 Platform Preview 4.
Тестирование предварительного просмотра платформы Internet Explorer (IE9) — обзор хорошего, плохого и основного разочарования
На MIX10 вчера, Microsoft объявила о IE9 и рассказала о своих новых возможностях . И, о чудо, они выпустили Internet Explorer Platform Preview для всех желающих скачать и поиграть!
Я попытался прочитать об этом и поиграть с предварительным просмотром как можно больше, чтобы получить представление о том, чего ожидать от IE 9, и вот мое мнение:
Хорошо
Я думал, что сначала просмотрю вещи, которые я нахожу хорошими или, по крайней мере, многообещающими.
Производительность
До сих пор одной из самых интересных функций в IE9 является аппаратное ускорение рендеринга, которое до сих пор дает очень хорошие результаты. IE9 также имеет новый движок JavaScript, Chakra, который значительно повысил производительность JavaScript, по сравнению с конкурирующими веб-браузерами, и показал хороший результат в тесте SunSpider.
Изображение взято из HTML5, Аппаратное ускорение: первый предварительный просмотр платформы IE9 для разработчиков
Я очень рад видеть это, и я надеюсь, что это значительно улучшит скорость в IE9, и, в свою очередь, в других веб-браузерах — все для выгоды конечных пользователей.
Поддержка селекторов CSS3
Впечатляет, что IE9 имеет почти полную поддержку селектора CSS3 (многие другие веб-браузеры уже делают), пройдя 576 из 578 тестов в тесте селекторов CSS3 .
Он также поддерживает цвета rgba и border-radius, поэтому примерно через десять лет нам не понадобятся изображения, чтобы иметь закругленные углы в сети…
Поддержка реальных событий DOM Level 2
Примерно через десять лет после своих конкурентов Microsoft наконец-то реализовала правильную поддержку событий в IE). Это означает, что код, подобный этому, действительно будет работать так, как ожидается:
document.addEventListener(«click», function () { alert(«Hello!»);}, false);
Это то, что я думал, что IE8 не должен был быть выпущен без .
Поддержка элемента .
Не доступно в предварительной версии, которая сейчас общедоступен, но показали на MIX, была поддержка видео элемента, который является хорошей новостью!
Стилизация элементов HTML5
Как я упоминал в своем посте «Введение в HTML5» , в предыдущих версиях Internet Explorer вам требовался HTML5 Shiv, т. Е. JavaScript, чтобы запускать его для применения стилей CSS к новым элементам, таким как article, header, aside и т. Д. Это не больше не требуется, и работает как положено в IE9.
Поддержка SVG
Опять же, ДОЛГО после конкурентов (бла, бла, бла), IE9 наконец-то имеет реализацию SVG. Остается проверить, насколько это хорошо, какие детали покрыты и т. Д., Но двигаться в правильном направлении.
XHTML. Да, настоящий XHTML.
Опять же, спустя почти десятилетие после веб-браузеров, IE9 наконец-то поддерживает тип MIME application / xhtml + xml! Это означает, что для тех, кому нужно использовать настоящий XML / XHTML, теперь это станет опцией.
Смею говорить о других
Одна вещь, которая меня порадовала, это то, что они осмелились упомянуть конкурирующий веб-браузер как на своих диаграммах, так и с логотипами в своих демонстрациях. Раньше казалось, что нечто подобное было запрещено, поэтому этот новый бриз открытости делает меня счастливым.
Плохо
Нет поддержки элемента
Одна из самых интересных технологий для создания захватывающего контента в Интернете — это элемент canvas. К сожалению, до сих пор нет поддержки canvas в IE9 и вообще нет упоминаний о нем. Однако, прочитав сообщение в блоге Работа с сообществом HTML5 , Microsoft заявляет:
… Вместе мы работаем над прототипами HTML, чтобы использовать их как «доказательство концепций», чтобы гарантировать, что функция хорошо разработана…
Если это вообще что-то значит, я понятия не имею, но будем надеяться, что это показатель поддержки холста. До тех пор его упущение является разочарованием.
Поддержка Acid3
В настоящее время IE9 набирает 55 баллов из 100, тогда как большинство других веб-браузеров набирают 100/100 баллов или находятся очень близко. Есть намного больше вещей, чем оценка Acid3, но это все еще подсказка о том, на каком уровне IE9 играет.
Изображение взято из HTML5, Аппаратное ускорение: первый предварительный просмотр платформы IE9 для разработчиков
Отсутствие поддержки захватывающего CSS
Хотя вышеупомянутая поддержка CSS3 хороша, к сожалению, в IE9 нет поддержки box-shadow, transform, CSS-градиентов, CSS-анимаций и тому подобного. Кроме того, что интересно, он, похоже, не отображает какие-либо из своих фирменных стилей CSS-фильтров — но это всего лишь предварительный просмотр для разработчиков и, вероятно, ничего не значит.
Нет поддержки для Windows XP
Интересно, что Microsoft решила не предлагать IE9 для Windows XP. Хотя я понимаю их мотив, когда люди обновляют ОС, не желая поддерживать старую версию операционной системы и т. Д.
, Это смелый (или раздражающий) шаг, когда на 65% рынка установлена Windows XP .
Это также боль для разработчиков, которые виртуализируют Windows (и да, их множество), которые хотят только легковесную ОС и не хотят покупать и устанавливать Windows Vista или Windows 7.
Модель расширения?
Сравнительный тест стабильных версий браузеров (апрель 2011)
Ваш любимый браузер привычен и комфортен. Но так ли он быстр и безопасен по сравнению с конкурентами? А как у него с поддержкой веб-стандартов? На эти вопросы дает ответ сегодняшнее сравнительное тестирование стабильных версий популярных браузеров.
Представляю сравнение браузеров глазами моего коллеги MVP, лидера форума Windows 7, где он известен как Morpheus. В его публикациях на OSZone множество людей находит ответы на свои вопросы.
За время, прошедшее с февральского тестирования, три из четырёх браузеров (Internet Explorer, Firefox и Chrome) достигли финальных версий, поэтому будет интересно их сравнить.
Поскольку IE редко обновляется (два года прошло с выпуска IE8), интересно протестировать, насколько браузер вырос с прошлой версии.
Поэтому в тесты включён IE8, а также по просьбам из зала в тесте будет участвовать новичок — Safari от Apple.
О методике тестирования и конкурсантах
Методика довольно проста: с официальных сайтов скачиваются и устанавливаются финальные версии браузеров, устанавливаются последние версии Java и Flash, в сети выбираются тесты, тестируем. Критерии подбора испытаний таковы:
- независимость от скорости Интернет-соединения
- рекомендации авторитетных источников
- отсутствие «аллергии» на них в сообществе (некоторые тесты из испытательного цикла исключены, т.к. была найдена информация об их «заточенности» под определённый браузер)
Все браузеры тестируются что называется «из коробки», т.е. они не настраиваются и не надстраиваются.
Может быть, такая методика и не выявит победителей со 100% точностью, но лидеров определённо покажет. Если вы знаете другие заслуживающие доверия тесты, обязательно упомяните о них в х, я постараюсь использовать и их.
Во всех тестах, чем больше значение — тем лучше результат.
Тестовая машина
Тестирование проводилось на компьютере с платформой Intel модельного ряда 2011 года. Более подробно описывать смысла нет, т.к. для всех браузеров она одинаковая.
Несколько основных тестов зависящих от видеокарты проведены как на встроенной графике в ЦП, так и на внешней ATI Radeon HD 4550 (обе с поддержкой Microsoft DirectX® 10.1). Поскольку не обнаружилось никаких отличий, заслуживающих упоминания отдельной строкой, всё тестирование проведено на встроенной Intel® HD Graphics.
На компьютере установлены:
- Windows 7 x64 с SP1
- Java SE Runtime Environment (JRE) 6 Update 24
- Adobe Flash Player 10.2.153.1
Конкурсанты
8 трюков для ускорения JavaScript
Здравствуйте!
Опыт в оптимизации браузерного JavaScript нынче на вес золота. Поэтому я перевел для вас статью с полезными трюками, помогающими повысить производительность приложений в браузере.
ag-Grid — библиотека для отображения больших объемов данных в браузере, внешне похожая на Excel и написанная на JS. Она хорошо работает даже в IE и на больших объемах данных. Сегодня мы расскажем о том, какие оптимизации мы используем, чтобы все работало быстро.
Мы расскажем о том, как выжать максимум из браузера, и наш опыт может оказаться полезным всем, кто хочет оптимизировать свои приложения. Это может также быть интересно пользователям ag-Grid для понимания того, как работает библиотека. Мы поддерживаем здоровую конкуренцию, так что мы рады внести свой вклад в знания сообщества.
Виртуализация строк
Виртуализация строк означает то, что мы отрисовываем только те строки, которые видны на экране. Например, есть таблица на 10 тысяч строк, но только 40 из них на самом деле отрисовываются(каждая строка представлена одним DIV). По мере прокрутки библиотека на лету создает новые элементы для появляющихся строк.
Если попытаться отрисовать сразу 10 тысяч строк, это скорее всего уронит браузер, учитывая одновременный рендеринг 10 тысяч DOM-элементов. Виртуализация строк позволяет отображать очень большое количество строк, отрисовывая только видимые.
Картинка ниже наглядно показывает, как работает виртуализация. Обратите внимание, что в DOM в один момент времени присутствуют только пять или шесть строк, которые в этот момент реально видны на экране.
Виртуализация колонок
Виртуализация колонок работает ровно так же, как виртуализация строк. Иными словами, отрисовываются только видимые колонки, и библиотека отрисовывает колонки при горизонтальной прокрутке.
Виртуализация колонок позволяет отображать большое количество колонок без деградации производительности.
Распространение событий
Проблема: регистрация обработчиков событий
Библиотека обрабатывает клики и нажатия клавиш для каждой ячейки, так что для каждой ячейки мы вынуждены регистрировать обработчики событий. Всего мы используем восемь событий: click, dblclick, mousedown, contextmenu, mouseover, mouseout, mouseenter and mouseleave.
Добавление обработчиков событий в DOM несколько влияет на производительность. Для таблицы в 20 видимых колонок и 50 видимых строк количество обработчиков равно 20 колонок * 50 строк * 8 событий = 8000 обработчиков событий. По мере прокрутки начинает работать виртуализация, и обработчики постоянно снимаются и регистрируются, создавая тормоза при прокрутке.
Решение: распространение событий
Шесть из восьми событий распространяемы, кроме mouseenter and mouseleave. Так что вместо добавления обработчиков на каждую ячейку мы добавляем обработчик для контейнера, содержащего все ячейки. Таким образом мы добавляем обработчик при инициализации таблицы, а не индивидуально для каждой ячейки.
Вопрос в том, как определить, для какой ячейки вызвано событие?
// parentContainer will contain all the cells var parentContainer = document.createElement('div'); // cells are regular DOM div objects var eCell = document.createElement('div'); // attach our own properties to the DOM object. // once we are not using DOM properties, there is no performance hit. eCell.__col = colId; eCell.__row = rowId; // add the cell to the container, no listeners parentContainer.appendChild(eCell); // listen for clicks on the parent container only parentContainer.addEventListener('click', myEventListener); function myEventListener(event) { // go through all elements of the event, starting from the element that caused the event // and continue up to the parent container. we should find the cell element along the way. var domElement = event.target; var col, row; while (domElement!=parentContainer) { // see if the dom element has col and row info if (domElement.__col && domElement.__row) { // if yes, we have found the cell, and know which row and col it is col = domElement.__col; row = domElement.__row; break; } domElement = domElement.parentElement;
}
}
Вероятно, вы заметили, что мы добавляем атрибуты __col и __row к элементам и думаете, безопасно ли это? Я надеюсь, что да, так как ag-Grid используется в приложении контроля авиатрафика над Австралией, насколько мне известно. Иными словами, библиотека работает так уже давно, и таким образом протестирована в боевой обстановке.
Это похоже на то, как работает React’s Synthetic Events. React использует делегирование событий и обрабатывает события в корне приложения, при этом отслеживая, какие ноды имеют обработчики. В React реализована собственная система событий, которая в итоге вызывает нужные обработчики.
Отбросьте DOM
Чутье программиста подсказывает вам, чтобы вы не забыли деконструировать все, что создали. Это значит, что вы должны удалить все созданные элементы DOM при очистке. В контексте вашего фреймворка это значит удалять компоненты, когда они больше не используются.
Этот прием работает так: если вы удаляете элемент из DOM (например ячейку), но вы знаете, что родительский элемент (например строка) тоже подлежат удалению, вам нет необходимости удалять ячейки по одной.
В ag-Grid по мере создания строк мы используем композицию, чтобы создать сложную структуру в DOM. Однако удаляя строки, мы не удаляем ячейки вручную, вместо этого мы удаляем строку одним вызовом.
Используйте innerHTML, где это возможно
Какой самый быстрый способ добавить кучу ячеек и строк в браузер? Стоит ли использовать JavaScript(document.createElement()) для создания каждого элемента, обновления атрибутов и сборки элементов воедино с помощью appendChild()? Или вам стоит работать с фрагментами документа? Или может лучше собрать все в большой кусок HTML и вставить в DOM с помощью innerHTML?
Мы проверили все это. Ответ: используйте innerHTML.
Так что мы выигрываем в скорости с innertHTML, собирая большой HTML и вставляя его в DOM с помощью element.insertAdjacentHTML(). Мы обнаружили, что insertAdjacentHTML() добавляет контент, в то время как innerHTML() заменяет его.
// build up the row's HTML in a string var htmlParts = []; htmlParts.push(''); cells.forEach( function(cell) { htmlParts.push(''); htmlParts.push(cell.getValue()); htmlParts.push(''); }); htmlParts.push(''); // append the string into the DOM, one DOM hit for the entire row var rowHtml = htmlParts.join('');
eContainer.insertAdjacentHTML(rowHtml);
Это хорошо работает, когда вы не используете отдельный рендеринг ячеек. В этом случае библиотека рендерит строку целиком и вставляет ее в DOM. Если используются дополнительные компоненты, библиотека вставляет их уже после рендеринга строки.
Рендеры ячеек — отдельный тип компонентов. Сама идея компонентов хороша для приложений, они как строительные блоки для больших приложений, когда мелкие элементы (компоненты) собираются воедино в большие элементы. Однако в ag-Grid мы делаем ставку на скорость, так что лучше избегать рендеров ячеек в пользу быстрого рендеринга строк с innerHTML.
Если вы используете ag-Grid, вам может быть интересно, как использование рендеров ячеек влияет на производительность. Во многом это зависит от платформы: в Chrome рендеринг небольшой и несложной таблицы не создаст проблем. Однако при выводе больших таблиц в IE вы можете ощутить заметное падение производительности при использовании рендеров ячеек.
Объединение событий прокрутки
Когда вы прокручиваете таблицу в ag-Grid, виртуализация влечет за собой удаление элементов DOM. Удаление занимает время, и если оно вызывается внутри обработчика события, это пагубно влияет на ощущения от прокрутки.
Чтобы избежать этого, библиотека объединяет несколько близких событий прокрутки с кадрами анимации. Это привычный трюк для достижения плавной прокрутки и он хорошо объясняется в статье Leaner, Meaner, Faster Animations with RequestAnimationFrame. Я не буду повторно объяснять его принцип тут. Достаточно сказать, что мы обнаружили, что этот трюк хорошо поднимает производительность.
Кадры анимации
Даже со всеми описанными трюками наши пользователи до сих пор просят нас «сделать побыстрее, это недостаточно хорошо работает в IE, прокрутка ужасна, она занимает кучу времени». Некоторые пользователи встречаются с лагами отрисовки строк в IE длиной в несколько секунд.
Так что следующий трюк — разбиение отрисовки строк по кадрам анимации. Когда пользователь прокручивает таблицу вертикально, чтобы посмотреть другие строки, вот что происходит внутри:
- 1 задача: прокрутка к закрепленной панели, если пользователь ее закрепляет
- n задач: вставить контейнеры со строками (в результате строки раскрашены в нужные цвета)
- n задач: вставить ячейки, используя innertHTML
- n задач: вставить ячейки, используя рендер ячеек
- n задач: вставить обработчики mouseenter and mouseleave на каждую строку для добавления hover-эффекта
- n задач: удалить старые строки
Так что если вы прокрутили таблицу, чтобы увидеть 10 новых строк, у вас появляется 50 с лишним задач. Каждая прокрутка, создание строки, создание ячеек — все это отдельные задачи.
Библиотека использует кадры анимации (или таймауты, если браузер не поддерживает кадры) для выполнения задач в определенном порядке. Порядок такой:
- Сперва прокрутка: максимальные усилия прилагаются к тому, чтобы держать закрепленные секции на своих местах.
- Затем вставка контейнеров строк: первое, что увидит пользователь — границы строк.
- Ячейки отрисовываются по порядку настолько быстро, насколько позволяет браузер.
- Потом удаляются старые строки, поскольку это никак визуально не отображается.
- Если происходит еще прокрутка, очередь задач перестраивается в пользу новых задач над старыми.
- Старые задачи отменяются, если их результат больше не понадобится после новой прокрутки.
Учитывая все вышесказанное, такое количество задач потребует много кадров. Чтобы избежать этого, библиотека не выполняет каждую задачу в отдельном кадре, особенно в связи с тем, что само создание, удаление и планирование кадров требует ресурсов.
Вместо этого библиотека запрашивает кадр и выполняет столько задач, сколько сможет, в течении 60 миллисекунд. Мы выбрали такой промежуток после тестов.
Если библиотека не успеет выполнить все задачи, она запросит новый кадр и будет выполнять оставшиеся задачи в нем, пока они не кончатся.
Быстрые браузеры вроде Chrome могут сделать все необходимое в одном кадре без видимой визуальной задержки. Медленным браузерам вроде IE может потребоваться 10 и более кадров для выполнения всех задач. Внешне это выглядит, как поступенчатая отрисовка, что гораздо лучше блокирования UI и отрисовки всего в один момент.
Вы возможно заметили, что мы используем кадры анимации для добавления mouseenter and mouseleave. Это отличается от остальных событий, где мы используем распространение событий, чтобы перехватывать их на верхнем уровне. mouseenter and mouseleave не поддаются такому трюку, так что мы просто добавляем их обработчики к строкам после их отрисовки. Пользователи от этого не страдают.
Библиотека использует аналогичный механизм для горизонтальной прокрутки. Сперва прокручивается заголовок, потом остальные колонки. Остальное работает точно так же.
Упорядочивание строк
Обычно DOM, созданный библиотекой, отображает строки в порядке создания. Это может создать рассинхронизацию между строками на экране, если они были отсортированы или отфильтрованы пользователем. Виртуализация строк добавляет и удаляет строки по мере прокрутки.
Программы для чтения экрана или другие инструменты обеспечения доступности требуют, чтобы порядок строк на экране соответствовал порядку в DOM. Поддержание постоянного порядка строк бьет по производительности, потому что в таком случае мы больше не можем вставлять строки большими пачками.
Однако компромисс возможен. Обычно библиотека не сортирует строки. Если пользователь хочет поддерживать порядок строк, он может использовать свойство ensureDomOrder=true. Таблица отображается немного медленнее, но тогда она совместима с программами для чтения с экрана.
Оригинал: ag-grid.com/ag-grid-8-performance-hacks-for-javascript
Top 15: лучшие движки с открытым исходным кодом javascript
Хотя вопрос, если «Javascript медленный?» это очень субъективный вопрос, потому что он работает в браузере клиента или полностью зависит от аппаратного и программного обеспечения, на котором работает код JavaScript. Но о чем это все? современные браузеры имеют возможности, которые мы никогда бы не представили 5 или 10 лет назад.
Используя JavaScript API WebGL, они могут полностью рендерить сложные 2D и 3D-графики, не полагаясь на сторонние плагины для браузера. Мы просто хотим подчеркнуть, что Javascript можно использовать для разработки веб-игр! не только 2D-игры, но и 3D-игры.
Начиная с чистого JavaScript, это лучший способ получить глубокие знания о разработке веб-игр.
Но зачем воссоздавать колесо, чтобы построить нашу игру с нуля (разработка элементов управления, манипулирование активами, забота об оптимизации и множество бесконечных проблем, решение которых может занять много времени самостоятельно), если мы можем ускорить этот процесс используя игровой движок, написанный на Javascript? В этой статье мы расскажем, по нашему мнению, о лучших игровых движках Javascript для разработки веб-игр.
15. Магистральный игровой движок
Github
Backbone Game Engine — это элементарный игровой движок HTML5 Canvas, созданный на основе Backbone. Специализируется на 2D-платформерах и оптимизировано для мобильных устройств. Backbone Game Engine был написан для запуска внутри CocoonJS Canvas +, поэтому вы можете превратить свою HTML5-игру в нативное приложение на iOS или Android.
- Построен на магистрали. События, модели, коллекции, наследование и RESTful постоянство. Зачем изобретать велосипед?
- HTML5 только холст. Нет jQuery, как можно меньше манипуляций с DOM.
- Мобильный оптимизирован. Создан для работы на мобильных устройствах с прозрачным сенсорным экраном и поддержкой просмотра. Все оптимизировано для максимальных кадров в секунду (FPS).
14. DarlingJS
Github
DarlingJS — это компонентный и основанный на сущностях игровой движок javascript с внедрением зависимостей и модульной архитектурой. Darling.js не стоит ни копейки. Код, лицензированный по упрощенной лицензии BSD. Вам нужно только отметить в источнике, что вы использовали Darling.js. И я буду очень рад, если вы дадите мне знать, что вы используете движок в своем проекте.
Внедрение зависимостей в Darling.js позволяет вам декларативно описать, как ваше приложение подключено. И любой компонент, который не соответствует вашим потребностям, может быть легко заменен.
Разделяет функциональность и данные на отдельные системы и компоненты, которые в основном не зависят друг от друга. Таким образом, композиция используется вместо наследования.
Также сгруппируйте компоненты и систему в модули, которые можно подключить к игровому приложению.
13. JawsJS
Github
Jaws — это 2D-игра, основанная на HTML5. Сначала он занимался только холстом, но теперь также поддерживает обычные спрайты на основе DOM через тот же API.
Jaws хорошо подходит для «классических» игр с боковой / верхней прокруткой (на основе плиток или нет), где у вас есть несколько спрайтов с анимированными листами спрайтов. Jaws поставляется с базовым обнаружением столкновений rect-vs-rect / circle-vs-circle, которое хорошо работает в большинстве случаев.
Если у вас есть тонны спрайтов (например, пуля, чёрт побери), вы, вероятно, захотите использовать физическую библиотеку, такую как Box2D, или пространственное хеширование, например, четырехугольные деревья, чтобы ускорить процесс. Использование челюстей в Canvas делает столкновения идеальными по пикселям и относительно легкими в освоении.
Если ваша игра сильно перегружена графическим интерфейсом, вы можете основывать свою игру на чистых HTML-элементах, а не на холст-спрайтах.
12. Enchant.js
Github
Простой JavaScript-фреймворк для создания игр и приложений со следующими функциями:
11. Квинт
Github
Quintus — это простой в освоении, увлекательный игровой движок JavaScript HTML5 для мобильных устройств, компьютеров и других приложений.
Движок Quintus — это игровой движок HTML5, разработанный для модульного и легковесного синтаксиса, дружественного к JavaScript.
Вместо попытки встроить стандартную структуру движка ООП-игры в движок JavaScript HTML5, Quintus берет некоторые подсказки от jQuery и предоставляет плагины, события и синтаксис селектора.
Вместо глубокой модели единственного наследования Quintus предоставляет гибкую модель компонентов в дополнение к традиционному наследованию, чтобы упростить повторное использование функциональности и обмен ею между играми и объектами.
10. Панда Двигатель
Github | Примеры
Panda Engine — это бесплатный игровой движок HTML5 для мобильных и настольных систем с рендерингом Canvas и WebGL, он использует Pixi.js для рендеринга с супер быстрой скоростью.
Обзор браузера Microsoft Internet Explorer 9
АрхивСофтерра
автор : Андрей Федив 25.04.2011
Даже противники Microsoft признают, что Internet Explorer 9 — это большой шаг вперёд по сравнению с прошлыми версиями этого браузера. А если сравнить его с Firefox, Chrome или Opera?
Девиз нового браузера Microsoft — «вся красота интернета». На первый взгляд, улучшенный интерфейс, существенно более быстрый движок, простота и множество новых функций оправдывают его.
Internet Explorer 9 — это огромный шаг вперёд по сравнению с предыдущими версиями этого браузера, и, чтобы совершить его, Microsoft потребовалось время.
Первые сведения об Internet Explorer 9 появились ещё на конференции PDC в ноябре 2009 года, предварительная версия IE9 Platform Preview 1 стала доступна для загрузки 16 марта 2010 года, однако работа над браузером была завершена лишь через год — весной 2011 года.
Несмотря на многочисленные усовершенствования, Internet Explorer 9 немедленно столкнулся со шквалом критики со стороны веб-разработчиков и евангелистов альтернативных браузеров.
Поводов для этого хватает, к тому же ситуацию осложняет то, что IE9 несовместим с Windows XP — системой, которая по-прежнему весьма распространена в мире.
В США Windows 7 только недавно впервые обогнала по популярности Windows XP, и до окончательной победы этой системе ещё очень далеко.
- Статистика на 10 апреля 2011 от StatCounter
Установка и первый запуск. Как всегда, после установки IE требуется перезагрузка системы. Это минус, поскольку все остальные браузеры для Windows перезагрузки не требуют. Впрочем, браузер запускается быстро, и это заметно даже на нетбуках.
Если запуск затягивается, то IE9 сам предложит отключить ненужные компоненты (подобным образом ведёт себя и Firefox). Это удобно, если пользователь использует «тяжёлые» надстройки или дополнения.
Порог срабатывания этого механизма можно выбрать самостоятельно.
- Улучшенная система настроек в действии
Минимализм. Первое, на что обращаешь внимание после установки браузера, — это его минимализм. Панель вкладок ютится справа от адресной строки, в результате места не остаётся ни для вкладок, ни для адреса, особенно в тех случаях, когда ширина окна не очень велика.
Учитывая популярность нетбуков, в которых разрешение экрана традиционно невысокое, это можно считать недостатком.
Ситуация с нехваткой места усугубляется тем, что в адресной строке находятся пиктограммы для поиска, обновления страницы, очистки введённого текста и, когда есть необходимость, иконка режима совместимости.
При этом, в отличие от Opera или Chrome, тут оформление окна браузера не зависит от его размера, то есть IE9 не экономит место при раскрытии окна на весь экран.
Правда, можно воспользоваться полноэкранным режимом, но это не всегда удобно.
Проблему можно частично решить, если вынести панель вкладок на отдельную строку (эта опция прячется в контекстном меню самой вкладки; там же можно обнаружить и популярную функцию «открыть закрытую ранее вкладку»).
Экспресс-панель. В IE9 появилась экспресс-панель для доступа к часто посещаемым сайтам. Её сложно назвать инновацией, поскольку подобная функция есть почти во всех современных браузерах.
Тут Internet Explorer, скорее, навёрстывает упущенное. Впрочем, не обошлось без любопытной особенности, отличающей экспресс-панель IE9 от аналогов: для индикации популярности сайтов в экспресс-панели используются цветовые полоски.
Значение цветов расшифровывает всплывающая подсказка.
Вкладки. Взаимодействие со вкладками, пожалуй, излишне упрощено (или, скорее, недостаточно функционально). Вкладки можно перемещать или «вытаскивать» в отдельное окно, но их нельзя закреплять (если не считать закрепления на панели задач), группировать, осуществлять предпросмотр в окне браузера или расширять их возможности при помощи дополнений.
Интеграция с системой. IE9 активно использует возможности, предоставляемые Windows 7. Сайты можно закрепить на панели задач рабочего стола — для этого достаточно просто перетянуть вкладку на панель задач. Открытые вкладки доступны для предпросмотра через панель приложений. Стоит, впрочем, заметить, что это удобно лишь до тех пор, пока их мало.
Есть и возможность запуска сайта как отдельного приложения. В IE она реализована следующим образом: страница загружается в отдельном окне с отдельной кнопкой в панели задач. При этом иконка страницы отображается в верхней части браузера.
Прочие изменения. Новый вид и функциональность получили также панель оповещений, которая переместилась из верхней части браузера в нижнюю, и диспетчер загрузок, ставший более информативным.
Диспетчер загрузок стал заметно функциональнее. Он открывается в отдельном окне и напоминает тот, что используется в Firefox.
Cюрпризом стало отсутствие в контекстном меню функции «Копировать адрес изображения» . Вместо этого предлагается только отправить ссылку на изображение по почте. Зачем понадобилось такое странное ограничение, — загадка.
Ускоряем JavaScript
Кажется, всего несколько дней назад мы рассказывали вам об истории flickr, и вот — статья, написанная главным разработчиком этой компании Кэлом Хендерсоном. Статья довольно специфичная — это вполне конкретные советы по решению вполне конкретных проблем, с которыми может столкнуться практически любой веб-разработчик.
Как правило, мы стараемся не публиковать материалы такого плана, однако и Веб 2.
0 — штука довольно новая, и проблемы, которые поднимает Хендерсон, далеко не для всех очевидны (что уж говорить о способах их преодоления), и литературы, освещающей эти вопросы, тоже не очень много, — к сожалению, большинство авторов компьютерных книжек делает упор на подробное описание синтаксиса, избегая рассуждать о тонкостях применения тех или иных техник.
Хендерсон на синтаксис не отвлекается. Не рассказывает он и о том, как делать приложения, активно использующие javascript и css. Его интересует другое — «как сделать эти приложения по-настоящему интерактивными и быстрыми». — В.Г.Так называемые приложения Веб 2.0 предполагают более интенсивное использование css и javascript, чем раньше.
Но для быстрой и качественной работы приложения мы должны оптимизировать размер и выдачу контента, который требуется для рендеринга страницы. На практике это означает, что мы должны сделать статический контент настолько маленьким и быстрым для загрузки, насколько это возможно, избегая немотивированной раздачи файлов, которые не претерпели изменений.
Эта задача несколько усложняется самой природой файлов css и javascript. В отличие от изображений, исходный код css и javascript скорее всего с течением времени будет меняться неоднократно.
И нам нужно, чтобы после каждого изменения клиенты могли загрузить обновленные версии файлов, не пытаясь использовать старые версии, сохраненные в их локальном кэше (а также во всех кэшах, которые встретятся по пути). В этой статье мы обсудим, как облегчить жизнь пользователю — при первой и последующих загрузках страницы, а также по мере того, как приложение развивается и обновляется.
Кроме того, мы должны максимально упростить жизнь разработчиков, так что обсудим заодно и способы автоматизации процессов оптимизации. Немного предварительной возни позволит нам совместить легкость разработки с удобством использования — и все без изменения привычных практик.
Раньше считалось, что максимальной производительности можно добиться, объединив многочисленные css- и javascript-файлы в более крупные блоки. Вместо десятка javascript-файлов по 5 Кбайт каждый мы делали один файл размером 50 Кбайт. Хотя общий размер кода при этом не менялся, мы сокращали накладные расходы на обработку http-запросов.Также важен аспект распараллеливания.
По умолчанию и ie и mozilla/firefox при использовании стабильного соединения загружают только два файла с одного домена (см. спецификацию http 1.1, секция 8.1.4). Это означает, что пока не загрузятся все скрипты, мы не загружаем картинки. Все это время пользователи видят страницу без изображений.Однако у этого подхода есть и недостатки.
Совмещая все наши ресурсы, мы заставляем пользователя загружать всё и сразу. Разделив содержимое между разными файлами, мы могли бы распределить тяжесть загрузки поверх нескольких страниц (или вообще избежать загрузки отдельных блоков — зависит от поведения пользователя).
Если же мы замедлим загрузку первой страницы, чтобы ускорить загрузку всех остальных, то можем столкнуться с тем, что второй страницы многие пользователи просто не дождутся.Исторически этот крупный недостаток такого подхода нечасто брался в расчет.
Но для системы, в которой постоянные изменения содержимого статических файлов — обычное дело, это важно, поскольку любое изменение в большом едином блоке требует, чтобы клиент перегрузил себе полный рабочий набор css или javascript.
Если приложение представляет собой монолитный исходник на javascript размером 100 Кбайт, значит, каждая мелочь приводит к принудительной загрузке лишних 100 Кбайт.В качестве альтернативного подхода постараемся придерживаться золотой середины. Разобъем наши css- и javascript-ресурсы на множество подфайлов, сохраняя в то же время количество этих файлов функционально невысоким. С одной стороны, нам удобно разрабатывать приложения, разбивая код на логические блоки. С другой стороны, для работы приложения важно, чтобы этих блоков было не слишком много (так что нам приходится объединять эти файлы). Компромисса можно добиться, сделав определенные добавления к системе сборки билдов (набор инструментов, превращающий «грязный» код разработки в рабочий, готовый для развертывания код).Для прикладного окружения, в котором среда разработки и среда исполнения четко разделены, подойдут простые техники управления кодом. Пусть в среде разработки код для пущей ясности разбит на множество логических блоков. Создадим в smarty (язык шаблонов для php) простую функцию загрузки javascript:
smarty:{insert_js files=»foo.js,bar.js,baz.js»php:function smarty_insert_js($args){foreach (explode(‘,’, $args[‘files’]) as $file»script>n»output:script>script>script>
Пока все просто. Но затем мы во время сборки билда объединяем нужные файлы. Представьте, что в нашем примере мы должны объединить foo.js и bar.js в foobar.js, раз уж они почти всегда подгружаются вместе. Учтем этот факт при настройке нашего приложения и модифицируем код с учетом этой информации:
smarty:{insert_js files=»foo.js,bar.js,baz.js»php:
# map of where we can find .js source files after the build process# has merged as necessary$globals[‘config’][‘js_source_map’] = array(‘foo.js’ => ‘foobar.js’,‘bar.js’ => ‘foobar.js’,‘baz.js’ => ‘baz.js’smarty_insert_js($args$globals[‘config’][‘is_dev_site’$files = explode(‘,’, $args[‘files’$files explode(‘,’, $args[‘files’]) as $file$files[$globals[‘config’][‘js_source_map’][$file$files = array_keys($files$files as $file»script>n»output:script>script>
Исходный код шаблонов не меняется, что позволяет нам сохранять эти файлы разделенными во время разработки. Кроме того, мы можем написать собственный процесс объединения на php и использовать тот же самый конфигурационный блок при самом объединении (а использование одного и того же конфигурационного файла избавляет нас от необходимости синхронизации). А если брать по максимуму, то можно проанализировать использование скриптов и стилей на страницах сайта, чтобы определить, какие именно файлы лучше объединять (хорошие кандидаты для такого объединения — это файлы, которые почти всегда подгружаются вместе).В случае с css можно начать с полезной модели, состоящей из двух стилей: основного стиля и стиля подраздела. Единый основной стиль используется во всем приложении, а разные стили подразделов контролируют разные функциональные области. В этом случае подавляющее большинство страниц подгружают только два стиля (один из которых кэшируется при первой загрузке — это, конечно, основной).Для небольших наборов css и javascript такой подход может замедлить обработку первого запроса (в сравнении с «монолитным» подходом), но если сохранять количество компонентов на относительно низком уровне, то возможно и ускорение работы, поскольку в расчете на одну страницу приходится загружать меньше данных.Когда речь заходит о сжатии, многие немедленно вспоминают mod_gzip. Однако с ним нужно соблюдать осторожность — mod_gzip, в общем-то, является злом или, по меньшей мере, причиной кошмарного расходования ресурсов. Основная идея сжатия проста. Браузеры, запрашивая ресурсы, указывают в заголовке, в каком виде они могут принять содержимое страницы. Это может выглядеть, например, так:
accept-encoding: gzip,deflate
Видя такой заголовок, сервер сжимает отсылаемое содержимое методами gzip или deflate с тем, чтобы клиент распаковал его на месте. Это загружает процессор как на клиенте, так и на сервере, однако уменьшает объем передаваемых данных. Это нормально. Однако вот как работает mod_gzip: он сжимает данные во временный файл на диске, а после отсылки данных удаляет этот файл.
На больших системах вы очень быстро столкнетесь с ограничениями скорости ввода/вывода. Этого можно избежать, используя вместо mod_gzip mod_deflate (только в apache 2), поскольку последний сжимает данные в оперативной памяти.
Пользователи первой версии apache могут создать ram-диск и хранить временные файлы mod_gzip там — это не так быстро, как работа напрямую с оперативкой, но намного шустрее, чем писать все на жесткий диск.
Но даже без этого мы можем полностью избежать вышеописанных проблем, используя предварительное сжатие нужных статических ресурсов и последующую отправку их клиенту с помощью mod_gzip. Если добавить предварительное сжатие в сборку билда, то сам процесс пройдет для нас совершенно незаметно.
Файлов, требующих упаковки, обычно не так уж много — мы не сжимаем изображения (поскольку это вряд ли приведет хоть к какой-то экономии — изображения и так уже достаточно сжаты), так что нам остается упаковать javascript, css и прочий статический контент. Но мы должны указать mod_gzip, где искать файлы для предварительной компрессии:
mod_gzip_can_negotiate yesmod_gzip_static_suffix .gzaddencoding gzip .gz
В последних версиях mod_gzip (от 1.3.26.1a и выше) для автоматической предварительной упаковки файлов в конфигурационных опциях достаточно добавить одну строчку. Нужно лишь удостовериться, что в apache установлены корректные разрешения на создание и перезапись упакованных файлов.
mod_gzip_update_static yes
Загрузка...
