В последнее время мне везет натыкаться на интересные статьи для перевода. На этот раз – статья на HTML5Rocks о производительности HTML5 canvas. Автор пишет о некоей стене, в которую упираются разработчики при создании приложений. Какое-то время назад в нее уперся и я при портировании старой-доброй игры на canvas.

К сожалению, графики в оригинале вставлены через iframe. Я мог бы сделать снимки и разместить их изображения, но сам автор позиционирует графики актуальными и такими, которые будут обновляться, потому я просто разместил на них ссылки. Приятного чтения!

1. Вступление
2. Тестирование производительности
3. Предварительно отрисовывайте в виртуальный canvas
4. Группируйте вызовы
5. Избегайте ненужных изменений состояния
6. Отрисовывайте только разницу, а не весь холст
7. Используйте многослойных canvas для сложных сцен
8. Избегайте shadowBlur
9. Различные способы очистить экран
10. Избегайте нецелых координат
11. Оптимизируйте анимации с помощью 'requestAnimationFrame'
12. Большинство мобильных реализаций canvas – медленные
13. Заключение
14. Ссылки

Вступление

HTML5 canvas, который начинался, как эксперимент компании Apple, – наиболее широко распространенный стандарт для 2D режима непосредственной графики в интернет. Многие разработчики использую его в широком круге мультимедиа проектов, визуализаций и игр. Как бы то ни было, с ростом сложности приложений, разработчики нечаянно натыкаются на стену производительности.

Я хотел бы поделиться прототипом игры, созданным всего за несколько часов. Надеюсь, что он вдохновит нескольких из вас! В индустрии однопользовательских браузерных игр, кажется, очень не хватает воображения и умения рассказывать истории, хотя, возможно, я просто не заметил таких игр ;), но мне не хватает таких игр, как Grim Fandango.

Ниже приведен скриншот из демонстрации, состоящей из нескольких узлов DOM, представляющих составные части главного героя, птиц и сцену. Большинство анимаций осуществляется CSS-переходами/анимациями, некоторые из которых являются динамическими и используют библиотеку move.js.

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

Программное обеспечение проникает во все щели человеческого общества. Мы узнаем погоду через интернет, а не через обычный градусник за окном. Мы едем по новому адресу с навигатором, а не ищем квадрат G7 на странице 59. Мы включаем RunKeeper, когда катаемся на велосипеде, чтобы узнать среднюю скорость и похвастаться в твиттере. Мы используем софт каждый день. Наверное, бОльшую часть жизни мы уже проводим в обнимку с любимыми гаджетами и программным обеспечением, а не с любимым человеком.

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

Доброго времени суток, хабравчане! В этой статье я подробно расскажу вам о трансформации и вращении в javascripte. Матрица трансформаций, на первый взгляд, штука непонятная и многие ею пользуются даже не осознавая, что она делает на самом деле, используя готовые значения из интернета. На MDC об этом рассказано скудненько, а информацию в английской Википедии тяжело назвать общедоступной. Постараемся разобраться в этом вместе.

День добрый. В этом топике я расскажу, как сделать ping-pong при помощи LibCanvas. Я значительно упростил её, оставив только самую важную часть, так как цель топика не создать игру ping-pong, а объяснить основы LibCanvas.

Итак, в топике пошаговая инструкция, как создать ping-pong при помощи LibCanvas (без оптимизаций).

Всем привет!

Хочу поделиться с хабрасообществом своим опытом написания многопользовательской браузерной стратегии с нуля до рабочего проекта. С точки зрения непосредственно программирования, архитектуры и возникших проблем. Это мой первый опыт создания игры и возможно вы заметите множество недочетов или промахов, или посоветуете чего дельного. Но не суть важно — главное я довел дело до рабочего проекта и наверняка многим будет интересно узнать подробности.



Что представляет собой игра? Видимо наиболее коротким описанием будет «клон Цивилизации» =). Но это не значит что у меня не хватило фантазии придумать что-то свое. Просто сделать «Цивилизацию» было моей мечтой. Вряд ли бы я получил столько удовлетворения от написания другой игры. Ну а фанаты Цивилизации наоборот считают, что моя игра совсем не похожа на Цивилизацию, разве что только с виду. Может это и к лучшему.

Игра называется The Fate of Nation http://fatenation.com

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

Для создания игры я использовал php и MySQL на сервере, html и javascript на клиенте. Flash не используется. Из html5 есть только видео на сайте и несколько областей с канвасом в самой игре — включая поверхность карты и мини-карту. Объем кода клиентской части в несколько раз превышает серверную часть, поэтому в основном буду рассказывать о клиентской разработке, но начнем с сервера.

Я хочу описать простой минималистский подход к разработке сложных JavaScript приложений. Из внешних библиотек будут использоваться только jQuery и мой js-шаблонизатор, причём из jQuery используются только $.ready(), $.ajax() и $.proxy() — т.е. суть не в библиотеках (их тривиально заменить на предпочитаемые вами), а в самом подходе.

В основе подхода лежат две идеи:

1. JavaScript виджеты — небольшие модули, каждый из которых «владеет» определённой частью веб-странички (т.е. всё управление этой частью странички происходит исключительно через методы этого модуля, а не через прямую модификацию DOM — инкапсуляция). Виджет отвечает исключительно за функциональность, но не за внешний вид; поэтому прямая модификация части DOM, которым «владеет» виджет, снаружи виджета допускается — но только для чисто дизайнерских задач (для архитектуры и общей сложности приложения нет принципиальной разницы между коррекцией внешнего вида через CSS или jQuery).
2. Глобальный диспетчер событий. Взаимодействие между виджетами осуществляется путём посылки сообщений глобальному диспетчеру (слабая связанность, паттерн Mediator/Посредник), а уже он принимает решение что с этим сообщением делать — создать/удалить виджеты, дёрнуть методы других виджетов, выполнить дизайнерский код, etc. В отличие от динамического подхода к обработке событий (когда обработчики конкретного события добавляются/удаляются в процессе работы) статический диспетчер сильно упрощает понимание и отладку кода. Безусловно, есть задачи, для которых нужны именно динамические обработчики событий, но в большинстве случаев это избыточное усложнение, поэтому всё, что можно, делается статическими обработчиками.

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

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

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

В то время как Ajax стал мейнстримом, пользовательские интерфейсы по-прежнему не могут похвастаться мгновенной отзывчивостью к действиям пользователя. Причина в том, что многие разработчики привыкли мыслить в терминологии «запрос/ответ» и думают, что UI должен работать параллельно с фронтэндом, дожидаясь ответа от сервера на каждый запрос. Но почему бы не обновлять интерфейс раньше, чем пришёл ответ?

Проблема довольно острая, потому что быстродействие является критически важной характеристикой UI. Например, по оценке Amazon, задержка загрузки страницы всего лишь в 0,1 секунды приводит к снижению оборота магазина на 1%. По оценке Google, задержка в 0,5 секунды уменьшает количество поисковых запросов на 20%.

Ruby/JavaScript-разработчик Алекс Маккоу (Alex MacCaw) из компании Twitter предлагает логичное решение проблемы: распространить принципы Ajax не только на фронтэнд, но и на пользовательский интерфейс. Он разработал соответствующий фремйворк для того, что называется AUI (асинхронный интерфейс пользователя).

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

TankWorld

3D шутер на танках. На некоторых уровнях можно найти вертолет и нести смерть супостатам с воздуха.

Dklab Realplexor — это Comet-сервер, позволяющий держать одновремено сотни тысяч долгоживущих открытых HTTP-соединений с браузерами пользователей. JavaScript-код, запущенный в браузере, подписывается на один или несколько каналов Realplexor-а и вешает обработчик на поступление данных. Сервер может в любой момент записать сообщение в один из таких каналов, и оно будет моментально передано всем подписчикам (хоть одному, хоть тысяче), в режиме реального времени и с минимальной нагрузкой для сервера.

^{Хотя идейным вдохновителем Realplexor-а был предыдущий проект, dklab_multiplexor, код Realplexor-а не имеет с ним практически ничего общего. Поэтому я и решил сменить название. Несопоставимы также возможности продуктов (см. ниже), да и размер кода увеличился в 7 раз.}

Realtime-направление сейчас довольно активно развивается на Западе, и в нем особенно выделяется продукт Tornado — событийно-ориентированный веб-сервер на языке Python. Правда, Tornado — это не столько Comet-сервер, сколько инструмент, с помощью которого можно запрограммировать «в том числе» и Comet-сервер. Ключевые слова: Comet, Push Server, Long polling, JavaScript, XMLHttpRequest.

Главные преимущества Realplexor-а:

• простота использования: наличие API для JavaScript, API для PHP (в будущем — и для других языков);
• простота конфигурирования;
• широкий функционал (либо отстутствующий, либо недоступный напрямую в аналогах).

Лучше один раз увидеть...

Я сделал отдельную онлайн-песочницу, чтобы продемонстрировать функционал нового Realplexor-а и то, для чего вообще нужны Comet-серверы (кстати, это физически тот же самый демон Realplexor-а, что использует мой новый стартап РуТвит). Песочница реализует что-то типа многоканального чата: зайдя, вы получите как будто бы 2 независимых «браузера», запущенных на разных компьютерах.

• Верхний «браузер» отображает каналы — в них моментально появляются новые сообщения, как только кто-то их туда отправляет на стороне сервера. Конечно же, эту страницу могут просматривать одновременно сотни тысяч пользователей, и они все будут видеть одно и то же (реализовано с использованием Realplexor JavaScript API). Можно «на лету» добавлять новые каналы (подписка) или скрывать уже имеющиеся (отписка).
• Нижний браузер содержит формы, позволяющие добавлять сообщение в произвольный канал, указав его имя. Форма AJAX-ом отправляется на сервер, и уже там PHP-скрипт записывает в Realplexor полученный текст через PHP API. (И да, так можно чатиться.)

По умолчанию на странице открыто 3 канала с именами Alpha, Beta и RuTvit. Но, конечно, вы можете закрыть эти каналы и открыть новые. Вот, например, страница с единственным открытым каналом по имени Habrahabr: http://rutvit.ru/realplexor/demo?ids=Habrahabr.



Песочница демонстрирует следующие функции Realplexor-а:

Дорогой Хабр!



У нас для тебя небольшой подарок. Мы тут работали-работали и вот чего сделали.
Сняли и опубликовали почти тысячу лекций по IT и математике.

UPD2 Помогите, пожалуйста, оперативно решить вопрос насчёт организации торрентов на php.

Я не люблю CSS. Он простой и понятный. Это движущая сила Интернета, но он слишком ограниченный и им трудно управлять. Пришло время привести этот язык в порядок и сделать его более полезным, используя динамический CSS при помощи LESS.
Объясню свою позицию на примере. Почему бы вместо использования #FF9F94 для получения темно-персикового цвета просто не хранить значение этого цвета в переменной для её последующего использования? Что бы перекрасить сайт достаточно будет изменить значение переменной всего в одном месте и всё.
Другими словами: это будет очень изящно, если мы будем использовать немного программирования и логики в CSS, что бы сделать его более мощным инструментом. Хорошо, что это всё возможно с использованием LESS.

PhantomJS это все плюшки WebKit из консоли с управлением на JS и поддержкой различных стандартов и технологий: DOM, CSS, JSON, Canvas и SVG.

Внутри несколько примеров использования

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

Считается, что есть два типа людей. Одни любят изучать многое и поверхностно, другие выбирают пару дисциплин и изучают их очень глубоко. Первых обычно называют лисами, вторых — ежами.

Для меня обучение очень похоже на геологоразведку. Представьте себе новый континент. Вы не знаете о нем ничего. Да, вы видите горы, леса, реки, но не имеете особого понятия что там внутри. Вы не знаете, что там за горизонтом, есть ли тут моря, насколько холодно на севере и какая температура на юге.

Карта

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

JavaScript — очень динамический язык, в нём заложена возможность менять язык под себя и создавать удобные инструменты для дальнейшей работы. «Реализация классического наследования» — как раз один из таких инструментов. В данный момент я не представляю себе, как я программировал бы на JS без «классов».

Для меня «Классы» — это, скорее, подход к проектированию и реализации поставленной задачи. В нашем новом проекте такой подход используется по полной программе (и, я думаю, что он оправдывает себя на все 100%).

Хочу представить вам функцию-конструктор классов createClass.
Чем хорош этот конструктор:
1. Сам код выглядит более читабельным и понятным
2. Поддержка множественного наследования
3. Поддержка абстрактных методов
4. Наследование статических методов и свойств класса
5. Умный метод instanceOf (проверяет по всей цепочке классов)