Всем привет!

Продолжаем цикл статей по разработке браузерного движка.

В данной статье я расскажу как создать самый быстрый HTML-парсер c DOM. Мы рассмотрим HTML спецификацию и чем она плоха относительно производительности и потребления ресурсов при разборе HTML.

С данной темой я докладывался на прошедшем HighLoad++. Конференцию не каждый может посетить, плюс в статье больше деталей.

Я предполагаю, что читатель обладает базовыми знаниями об HTML: теги, ноды, элементы, пространство имён.

В данной статье я хочу рассказать о небольшом и забавном проекте выходного дня по передаче файлов через анимированные QR коды. Проект написан на Go, с использованием Gomobile и Gopherjs – последний для веб-приложения для автоматического замера скорости передачи данных. Если вам интересна идея передачи данных через визуальные коды, разработка веб-приложений не на JS или настоящая кроссплатформенность Go — велкам под кат.

Что за игра-то? И кто “мы”?

1. Настройка экспорта Tiled2Unity
2. Настройка столкновений в Tiled Map Editor
3. Настройка параметров, которые поддерживает Tiled2Unity
4. Настройка пользовательских параметров в Tiled Map Editor

• Пользовательские параметры для слоев (объектов)
• Пользовательские параметры для объектов

1. Настройка экспорта

Привет, Хабр! Эта статья про плагин Rainbow CSV, который я написал для 5 текстовых редакторов:

VS Code, Vim, Sublime Text 3, Atom, Gedit

Думаю, что многие читатели этой статьи периодически сталкиваются с CSV (comma-separated), ТSV (tab-separated) и подобными файлами. Если попробовать открыть их в текстовом редакторе (а как иначе узнать что там внутри?), то откроется совершенно невзрачная картина как с левой стороны изображения. Глядя на это сложно сказать даже сколько колонок в таблице. С правой стороны картинки тот же файл с включенным RainbowCSV, читаемость значительно повысилась за счет синтаксической подсветки.

Что же должно быть в идеальном браузере?

Однажды я готовился к Ludum Dare и сделал простую игру, где использовал пиксельные шейдеры (других в движок Phaser не завезли).

color = pixelShader(x, y, ...other attributes)

Потестировав, кинул ссылку другу, и получил от него вот такой скриншот с вопросом "а это нормально?"

Нет, это было ненормально. Посмотрев внимательно код шейдера, я обнаружил ошибку в вычислениях:

if (t < M) {
    realColor = mix(color1,color2, pow(1. - t / R1, 0.5));
}

Т.к. константа R1 была меньше чем M, то в некоторых случаях в первом аргументе pow получалось число меньше нуля. Квадратный корень из отрицательного числа — штука загадочная, по крайней мере для стандарта GLSL. Мою видеокарту ничего не смутило, и она как-то выпуталась из этого положения (похоже, вернув из pow 0), а вот у друга она оказалась более разборчивой.

И тут я задумался: а могу ли я избежать таких проблем в будущем? От ошибок никто не застрахован, особенно таких, которые не воспроизводятся локально. Юнит-тесты на GLSL не напишешь. В то же время преобразования внутри шейдера довольно простые — умножения, деления, синусы, косинусы… Неужели нельзя отследить значения каждой переменной и убедиться, что ни при каких условиях не происходит выхода за допустимые границы значений?

Так я решил попробовать сделать статический анализ для GLSL. Что из этого получилось — можно прочитать под катом.

Сразу предупрежу: какого-то законченного продукта получить не удалось, только учебный прототип.

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