Как Adobe с похолоданием боролся

[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 выглядит так:

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

Comments

[thedeemon.livejournal.com]

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

[nivanych.livejournal.com]

У флеша минусы начинаются с реализации плугина.
И хрен с ним, с этим ускорением от видяшки, другого хватает.

[thedeemon.livejournal.com]

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

[nivanych.livejournal.com]

> получился Silverlight. Он лучше?

А должен был?

> во-первых долго ждать,
Пока не очень надо, я жду ;-)

> во-вторых не факт, что будет работать лучше,

Хотябы проблем с совместимостью с операционными системами не будет. А то залодбало очень.

> а в-третьих разных браузеров и их версий
> всегда такой зоопарк, что вопросы совместимости замучают.

Ну, не настолько, как с тем же JavaScript 5-7 лет назад.
Сейчас уже получше, хотя и неидеально.
Есть вон Acid-тест ;-)
А вот мне, как пользователю, точно будет лучше, ибо флеш задолбал.

[thedeemon.livejournal.com]

>флеш задолбал

А чем именно? И не задолбет ли тем же то, что придет ему на смену?

[nivanych.livejournal.com]

Тот же SVG+JavaScript значительно менее задалбывает (меня, как пользователя).
Хотябы под 64-битными операционками работает без извратов.

[thedeemon.livejournal.com]

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

[nivanych.livejournal.com]

> пока там нет анимации

Как, совсем нет? Чорт, а я-то надеялся.
Может, ну хоть каак-то можно, а?
Зачем тогда вместе с SVG делают JavaScript, если анимацию делать нельзя...
Это явный просчёт в дизайне.

А отключается оно сейчас так же, как и флеш.

[thedeemon.livejournal.com]

>вместе с SVG делают JavaScript

А, ну да. Хотя как-то оно хлипко и низкоуровнево выглядит.

[nivanych.livejournal.com]

SMIL вполне так высокоуровневый, на нём уже кое-какую мелкую анимацию можно делать.
JavaScript'ом, ну не сказать, что особо низкоуровнево. Обыкновенно.
Так же, как и с HTML - есть объекты, есть события типаа OnMouse*.
Всё обычно.

[wizzard]

Рантайм лучше. Легче достать сорцы контролов. Остальное где-то так же.