Привет, друзья!

Я бы хотел показать вам результаты беглого сравнения трех наиболее популярных библиотек для 2D рендера, работающих на Stage3D:
Starling, ND2D, Genome2D.

Я скачал последние доступные билды и исходники этих библиотек и написал простое AIR приложение, в котором отображается некоторое количество изображений. Все они вращаются, двигаются, скейлятся и меняют альфу каждый кадр
Изображения размещаются по всей видимой области в несколько итераций (каждый кадр добавляется заданное количество изображений, пока их общее количество не достигнет заданного предела).
Для всех изображений используется одна и та же текстура — квадрат 25 на 25 с небольшим количеством альфы.
Я прогнал это приложение на своем стационарном PC и на двух мобильных устройствах — iPad1 с iOS 5.0.1 и GalaxyTab 10.1 с Android 3.1.

Итак, вот что я получил:

Starling изGitHub’а Commit:9aa93a8195c47252253fd4d2b671115e19d16b6f, 24.03.2012:

iPad 1:
1350 изображений на 30 FPS
RAM: 6.4 МБ

GalaxyTab 10.1 (OC 1.4ГГц):
1350 изображений на 30 FPS
RAM: 6.2 МБ

PC (i7 4.8 ГГц, Radeon 6790):
10000 изображений на 30 FPS
RAM: 19.7 МБ
RAM на 1000 изображений: 9.1 МБ

Starling — отличный опенсорсный фреймворк. Он имитирует классический DisplayList, имеет большое сообщество (во многом благодаря Adobe) и очень подробную API документацию. По этому изучать и вносить изменения в эту библиотеку достаточно просто.

ND2D из GitHub’а Commit:453531f7aee46b00a112c6f0d5d8b46d62075287, 05.03.2012:

Эта библиотека позволяет отрисовывать большое количество спрайтов в одинаковой текстурой двумя разными «способами» — добавляя спрайты в Sprite2DCloud или в Sprite2DBatch. Я протестировал оба.

Sprite2DCloud:

iPad 1:
~1150 изображений на 30 FPS
RAM: 6.4 МБ

GalaxyTab 10.1 (OC 1.4ГГц):
~1150 изображений на 30 FPS
RAM: 6.2 МБ

PC (i7 4.8 ГГц, Radeon 6790):
16000 изображений на 30 FPS с падением до 16 FPS во время добавления изображений (добавлялось по 100 штук в кадр), этого падения не должно быть заметно если добавлять все спрайты сразу.
RAM: 37 МБ
RAM на 1000 изображений: 9.5 МБ

Sprite2DBatch:

iPad 1:
~1150 изображений на 30 FPS
RAM: 6.6 МБ

GalaxyTab 10.1 (OC 1.4ГГц):
~1150 изображений на 30 FPS
RAM: 6.1 МБ

PC (i7 4.8 ГГц, Radeon 6790):
10800 изображений на 30 FPS
RAM: 23.2 МБ
RAM на 1000 изображений: 9.1 МБ

ND2D это еще один прекрасный опенсорсный фреймворк для отрисовки 2D с использованием Stage3D. У него также имеется большое сообщество (хоть и меньше, чем у Starling), однако API документация страдает — она заполнена очень поверхностно (однако, зачастую и этого достаточно) и при этом фреймворк сравним по производительности со Starling.
Данную библиотеку также просто использовать, т.к. своей архитектурой визуальных объектов она тоже напоминает классический DisplayList, который мы привыкли видеть во Flash, к тому же для библиотеки доступны примеры использования.

Genome2D Nightly 0.9.0.1093:

Эта библиотека отчетливо выделяется. Достаточно посмотреть на результаты бенчмарков!

iPad 1:
1900 изображений на 30 FPS
RAM: 6.5 МБ

GalaxyTab 10.1 (OC 1.4ГГц):
3800 изображений на 30 FPS
RAM: 10 МБ

PC (i7 4.8 ГГц, Radeon 6790):
~40000 изображений на 30 FPS
RAM: 68.7 МБ
RAM на 1000 изображений: 9.1 МБ

Это просто хардкорный фреймворк! Библиотека работает с потрясающей скоростью, однако для нее нет вообще никакой API документации, у нее скромное сообщество и нет актуальных примеров для последних Nightly билдов (на данный момент последний nightly билд ушел далеко вперед по сравнению с последним релизным).
Новичку использование данного вреймворка может показаться чересчур сложным.

Итак, что у нас есть для создания 2D приложений на Stage3D:
Starling — самый приятный. Однако, в некоторых тестах проигрывает ND2D в производительности.
ND2D — компромиссный вариант — в некоторых случаях он быстрее Starling’а, но отсутствие (на данный момент) адекватной API документации немного портит впечатление (so far).
Genome2D — в некоторых случаях (как в моем, например) может показывать небывалую производительность и оставлять конкурентов далеко позади, однако использовать его я бы порекомендовал лишь хардкорным разработчикам с навыками «ниндзжениринга») Я надеюсь, этот фреймворк станет дружелюбнее к разработчику в будущих релизах.

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

Так же, хотелось бы отметить, что iPad1 и разогнанный до 1.4 ГГц GalaxyTab 10.1 во многих случаях держались наравне. Я подозреваю, что дело в разрешении и каким-то образом компенсирующих друг друга других HW и SW отличиях.
Так что если вы сейчас задумались о портировании своей (не требовательной к ресурсам) игры с комфортом и без лишних сложностей, то я бы смело рекомендовал попробовать Starling. Если же вам требуется максимум производительности (и приключений) — посмотрите в сторону Genome2D. А если что-то между — то я бы посоветовал ознакомиться с ND2D.

В качестве бонуса привожу ссылку на архив со всеми бенчмарками для Android (и AIR 3.2 p6 Runtimes для Android):
http://codestage.ru/files/flood/android/benchmark.zip

Если вы считаете, что я где-то ошибся в тестах — пишите — я буду рад исправить свою ошибку!

*Обновление 1*

Недавно я обновил расширение для Starling — starling-imagebatch, автором которого является Philippe, чтобы оно заработало с последней версией Starling’а. Заодно проверил его в деле.

Вот результаты:

iPad 1:
2000 изображений на 30 FPS
RAM: 6.4 МБ

GalaxyTab 10.1 (OC 1.4ГГц):
2000 изображений на 30 FPS
RAM: 5.1 МБ

PC (i7 4.8 ГГц, Radeon 6790):
>16000 изображений на ровных 60 FPS (больше изображений добавить не получилось из-за ограничения размеров буфера)
RAM: 14.9 МБ
RAM на 1000 изображений: 8.4 МБ

Баг с распуханием памяти)

Пока я ковырялся с ImageBatch, случайно наткнулся на очень неприятный баг, из-за которого потребление памяти начало ощутимо скакать.
Я пока так и не понял откуда у него ноги растут, но наткнуться похоже на него не очень сложно, если часто пользуешься свернутыми условями (хорошо, что у меня такой привычки нет).

Вот первый кусок кода:

var k:Number = (premultipliedAlpha ? item.alpha : 1) / 255;

А вот второй:

var k:Number = premultipliedAlpha ? item.alpha : 1;
k /= 255;

По сути никакой разницы, верно?
Только вот при очень многократном выполнении первого куска происходит распухание памяти со скоростью где-то 5 мб/сек и примерно какждые 3-5 секунды оно чистится — получается такая гармошка на графике потребления памяти)
А если первый кусок заменить на второй — всё работает как часы без каких-либо проблем с памятью.