Как Adobe с похолоданием боролся
Oct. 15th, 2010 11:21 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thedeemonЕсть у них такая штука - Flex: пишешь на ActionScript3 (что-то среднее между JavaScript и C#) и MXML (аналог XAML) прыложение, а оно выполняется либо в браузере посредством Flash player'a, либо отдельно посредством AIR runtime. А еще у них есть штука под названием Pixel Bender - очередной язык для pixel shader'ов (ибо GLSL, HLSL, Cg и т.п. конечно недостаточно, нужен свой), работающий в фотошопе, After Effects, ну а теперь еще и во флэше. И вот в четвертый Flex добавили эффекты на базе этих шейдеров, чтобы переходы между разными картинками или состояниями интерфейса анимировать. Например, Wipe - где одна картинка замещается другой постепенно: когда прошло X% времени эффекта, X% площади картинки занимает новая, а остальную площадь - еще старая. Попробовал я такой эффект применить на картинке 600х400 и обнаружил, что он загрузил на 65-70% мой двухгигагерцевый двухъядерник (Core 2 Duo). Изменение частоты кадров проекта и приложения никак не повлияло: при любом заданном фреймрейте эффект оставался плавным и продолжал грузить процессор. Стал разбираться, почитал исходники (благо Flex опенсорсный) и блоги разработчиков и выяснил вот что:
1. Частота кадров эффектов жестко зашита в дебрях фреймворка и равна 100 кадрам/с.
2. Во флэше поддержка шейдеров pixel bender'a исключительно программная - никакого GPU. Ибо честная их поддержка на видеокартах сильно увеличит размер самого flash player'a, на что они пойти не готовы.
3. Зато есть JIT и распараллеливание по ядрам CPU. Сколько ядер ни дай - все загрузит ненужной работой.
4. Шейдер для Wipe выглядит так:
Другими словами, вместо того, чтобы на каждом кадре просто скопировать небольшую изменившуюся полоску картинки (x% площади, где x - доля прошедшего за один кадр времени), тут для каждой точки изображения выполняется 2-3 сравнения вещественных чисел, плюс копирование данных. Как вам такое решение?
А, и да, при каждом создании такого эффекта плеер съедает пару мегов памяти и не освобождает, пока не утечет 50 мегов.
Судя по тому, что в исходниках Flex'a упоминается одно и то же имя, и тот же человек вел видеорассказы про flex на офф.сайте, он сам это все и понаписал. До этого он работал в Sun над клиентом java (ага), а теперь в гугле работает над SDK андроида. Бойтесь.
1. Частота кадров эффектов жестко зашита в дебрях фреймворка и равна 100 кадрам/с.
2. Во флэше поддержка шейдеров pixel bender'a исключительно программная - никакого GPU. Ибо честная их поддержка на видеокартах сильно увеличит размер самого flash player'a, на что они пойти не готовы.
3. Зато есть JIT и распараллеливание по ядрам CPU. Сколько ядер ни дай - все загрузит ненужной работой.
4. Шейдер для Wipe выглядит так:
void
evaluatePixel()
{
float2 coord = outCoord();
// Use src0 in a branch we won't reach just to defeat the
// optimizer from removing the input parameter
if ((width * progress) < coord.x)
dst = sampleNearest(from, coord);
else if (progress < 100.0)
dst = sampleNearest(to, coord);
else
dst = sampleNearest(src0, coord);
// workaround for Flash filter bug that replicates last column/row
if (coord.x >= width || coord.y >= height)
dst.a = 0.0;
}Другими словами, вместо того, чтобы на каждом кадре просто скопировать небольшую изменившуюся полоску картинки (x% площади, где x - доля прошедшего за один кадр времени), тут для каждой точки изображения выполняется 2-3 сравнения вещественных чисел, плюс копирование данных. Как вам такое решение?
А, и да, при каждом создании такого эффекта плеер съедает пару мегов памяти и не освобождает, пока не утечет 50 мегов.
Судя по тому, что в исходниках Flex'a упоминается одно и то же имя, и тот же человек вел видеорассказы про flex на офф.сайте, он сам это все и понаписал. До этого он работал в Sun над клиентом java (ага), а теперь в гугле работает над SDK андроида. Бойтесь.
