Dmitry Popov

Пытаюсь тут собрать в vs2010 в 64 бита код, который успешно собирался в vs2005. Не собирается, не находит некоторые SSE интринсики - те, что используют тип __m64 (пришедший из MMX'a еще). Заглядываю в MSDN, а там просто так пишут: "The __m64 data type is not supported on x64 processors". Как же оно у меня тогда работало столько лет? А просто там проект интеловским компилятором компилился, он прекрасно эти типы и интринсики понимает, и отлично они себе работают на x64. Просто в MSVC кто-то решил их не поддерживать, а чтобы не задавали лишних вопросов написали, что это процессоры виноваты. Молодцы, чо.

Есть у них такая штука - 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 выглядит так:

    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 андроида. Бойтесь.